infProt no XML: como ler a resposta da SEFAZ por nota

infProt, em /nfeProc/protNFe/infProt, reúne a resposta da SEFAZ para uma NF-e ou NFC-e individual. Ele identifica a chave, o ambiente, o processamento e o status devolvido. A existência do grupo, ou de um arquivo chamado nfeProc, não significa por si só que a nota foi autorizada.

O que ler e em qual ordem

O tipo TProtNFe exige um infProt. Dentro dele, a sequência básica do XSD é:

Os primeiros quatro campos e cStat/xMotivo são obrigatórios nessa estrutura; nProt e digVal são opcionais no XSD. A opcionalidade não autoriza inventá-los quando ausentes.

Protocolo, recibo e eventos

O recibo de um envio assíncrono permite acompanhar o processamento do lote. Ele não é nProt da nota. Um lote processado, por exemplo com cStat=104 no retorno externo, pode conter respostas individuais com resultados diferentes. O resultado de cada nota deve ser lido no infProt correspondente.

No retorno individual, cStat=100 informa autorização de uso; cStat=150, autorização fora de prazo; cStat=120, autorização com alerta, inicialmente para NFC-e conforme a NT 2026.002. Rejeição e outros resultados precisam ser classificados pelo código efetivo, não pela presença de nProt ou pelo HTTP 200. Uma autorização histórica também não elimina um cancelamento posterior: para situação atual, consulte a chave no ambiente correto e examine os eventos oficiais.

Assinatura e mensagens adicionais

O atributo infProt/@Id é opcional no schema e, quando a SEFAZ assina a resposta, o leiaute o relaciona ao literal ID seguido do número do protocolo. A assinatura sob protNFe, quando presente, autentica a resposta; a assinatura sob NFe tem outro objeto. Verificar XSD não verifica nenhuma delas.

Após xMotivo, o PL_010f_v1.04 admite uma sequência opcional de até cinco pares cMsg/xMsg. A NT 2026.002 v1.11, pp. 5–6, atualiza PR13 para 0..5 ocorrências e PR15 para texto de 1 a 255 caracteres, em acordo com esses limites do schema. A indicação antiga de uma sequência e texto até 200 caracteres na NT 2025.002 não deve ser apresentada como indefinição atual.

Cada par liga código e mensagem suplementar. Preserve todas as ocorrências e interprete-as com cStat/xMotivo: uma rejeição pode vir acompanhada de alertas já identificados, enquanto uma autorização com alerta tem resultado principal próprio. Não trunque textos nem fabrique código que falte no original.

Exemplos de reconciliação

Cenário sintético A: um lote está processado, mas a resposta individual de uma nota indica rejeição. A integração que conclui todas as notas a partir do lote produz uma conclusão incorreta. Correlacione cada chNFe a seu cStat/xMotivo e só depois atualize a interpretação individual.

Cenário sintético B: a chave parece correta, mas tpAmb=2 e a integração esperava produção. O arquivo não comprova autorização em produção. Separe os ambientes e busque a resposta correta, sem editar tpAmb.

Não há XML completo no exemplo: um infProt operacional exige chave, eventual protocolo e digest originais. A tabela descreve a estrutura sem inventar identificadores fiscais.

Roteiro de diagnóstico

Preserve nota e resposta originais. Confira chave e ambiente; leia o código individual; compare nProt e digest quando disponíveis; registre o instante com fuso e verAplic; leia mensagens pareadas. Em divergência, diferencie perda no armazenamento, interpretação errada e resultado fiscal incerto. Não monte protocolo a partir de dados de outra nota e não reenvie um documento apenas porque a cópia local está incompleta.

Como interpretar autorização com alerta e seu cronograma

A NT 2026.002 v1.11 cria cStat=120, “Autorizado o uso da NF-e, com alerta”, inicialmente somente para NFC-e. Se a autorização ocorrer fora de prazo e contiver alerta, a NT também prevê o código 120. Portanto, uma classificação que reconhece somente 100 e 150 como autorização fica incompleta nesse contexto.

Uma regra de efeito Alerta registra a ocorrência e permite continuar o processamento; são retornados somente os cinco primeiros alertas encontrados. Se outra regra de efeito Rejeição interromper o processamento, a resposta terá o código da rejeição e poderá trazer alertas identificados até esse momento. Um cMsg isolado não determina qual resultado ocorreu.

Na autorização com alerta, a nota foi armazenada e não precisa ser corrigida e retransmitida para solucionar a origem do alerta. Leia a inconsistência, confirme os dados que a explicam e trate sua origem cabível, preservando o documento autorizado. Isso não dispensa consulta da situação atual quando necessária.

O cronograma específico da estrutura de autorização com alertas registra teste em 01/09/2026 e produção em 05/10/2026. O adiamento para 14/12/2026 na versão 1.11 alcança I08-180, BA02-35 e VC02-40; não adia a estrutura de alertas. Essas datas documentam o recorte e não comprovam, sozinhas, a implantação de cada autorizadora.

Leituras relacionadas

• chNFe — /nfeProc/protNFe/infProt/chNFe
• xMotivo — /nfeProc/protNFe/infProt/xMotivo

Fontes oficiais

• Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe, linhas 6686–6770.
• Tipos básicos NF-e/NFC-e — PL_010f_v1.04: TChNFe, TProt, TStat, TAmb, TVerAplic, TMotivo e TDateTimeUTC.
• NT 2025.002 RTC — 1.52: seção 5.1, p. 11; PR03–PR90, p. 13.
• MOC 7.0 Anexo I — 7.00: A03-10 p. 74; B02-10, B02-20, B03-10 e B06-10 p. 75.
• NT 2026.002 — autorização com alerta e DANFE Simplificado Tipo 2 — 1.11, setembro de 2026: cronograma p. 3; autorização/alertas pp. 4–5; protocolo pp. 5–6.