Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Suplemento, assinatura e protocolo

protNFe em nfeProc: protocolo, vínculo com a nota e status

<protNFe>nfeProc › protNFe

Revisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

protNFe guarda o protocolo de resultado do processamento da NF-e/NFC-e. Dentro de nfeProc, ele acompanha a nota assinada NFe; não é parte do infNFe que o emitente assinou.

Caminho desta página: /nfeProc/protNFe. O elemento protNFe pertence ao namespace fiscal http://www.portalfiscal.inf.br/nfe; o atributo versao não possui namespace próprio.

Qual estrutura acompanha a nota processada?

O tipo TNfeProc exige uma NFe e um protNFe. O protocolo exige versao e um infProt; pode conter uma Signature própria, depois de infProt. Essa assinatura é opcional no XSD e sua adoção depende da UF, conforme PR90 do MOC. Ela não é uma cópia da assinatura da nota.

infProt contém, em ordem, ambiente tpAmb, versão do processador verAplic, chave chNFe, data/hora dhRecbto, opcionais nProt e digVal, código cStat e descrição xMotivo. O tipo atual também admite até cinco pares cMsg/xMsg. Esses pares são mensagens adicionais e não substituem o resultado principal.

Declaração XSD do contexto.

O que precisa corresponder para associar o protocolo à NF-e?

Compare infProt/chNFe com a identidade da nota e confirme o mesmo ambiente em tpAmb. Quando digVal está presente, confira sua relação com o digest da NF-e original; ele não é SignatureValue nem a assinatura opcional do protocolo. dhRecbto é a data/hora do processamento/recebimento definida para a resposta, não a data de emissão que o usuário pode ajustar.

O arquivo deve ser montado a partir da resposta real do autorizador e da nota correspondente. Ter dois blocos XML lexicalmente válidos não prova que pertencem ao mesmo processamento. Preserve a origem de ambos.

XMLDSig: processamento e elementos.

O nome protocolo garante autorização?

Não. protNFe é um tipo de resultado e o status deve ser lido em infProt/cStat, com xMotivo e os demais dados aplicáveis. A presença de nProt, de assinatura ou de HTTP 200, isoladamente, não substitui essa análise. Até um retorno de lote processado pode conter resultado individual rejeitado.

Na resposta individual de autorização, 100 indica autorização de uso; 150, autorização fora de prazo; e 120, autorização com alerta, implementada inicialmente somente para a NFC-e modelo 65, conforme a NT 2026.002 v1.11. Esse recorte não permite generalizar o novo resultado a toda NF-e modelo 55. O código 120 também pode ser retornado quando a nota foi autorizada fora de prazo e contém alertas. A estrutura de autorização com alerta tem produção prevista em 05/10/2026 no cronograma dessa NT; o status efetivamente recebido continua sendo a evidência do caso.

Os alertas ficam nos pares cMsg/xMsg, até os cinco primeiros identificados, enquanto cStat/xMotivo informam o resultado principal. Uma rejeição também pode devolver os alertas identificados antes de interromper o processamento; portanto, existir cMsg não determina se houve autorização. Se o resultado é 120, não se deve corrigir e retransmitir a mesma nota para eliminar o alerta: ela já foi autorizada. Analise a origem indicada pelo alerta para as providências cabíveis e as emissões seguintes, preservando o documento e seu protocolo.

NT 2026.002 v1.11: resultados, alertas e protocolo, pp. 3–6.

Cenário de diagnóstico: o sistema possui a NFe assinada e um protNFe, mas a chave da resposta pertence a outro documento. A ação correta é recuperar e correlacionar a resposta original, sem anexar o protocolo ao acaso. Em outro cenário, a autorização original está comprovada, mas é necessário saber a situação atual: consulte os registros/eventos oficiais da mesma chave e ambiente.

Não se apresenta XML completo de protocolo com chave, status ou número fictícios. A estrutura é explicada acima; o conteúdo operacional precisa vir do retorno verdadeiro. Não edite um protocolo recebido nem retransmita uma nota de resultado incerto para “obter” outro.

MOC: resposta e protocolo, pp. 76–77.

Fontes e contexto

Leiaute da NF-e e protocolo — PL_010f_v1.04 / leiauteNFe_v4.00.xsd; MOC — Visão Geral — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013; Autorização com alerta e estrutura do protocolo — NT 2026.002 v1.11; Portal Nacional — Notas Técnicas vigentes — captura 15/10/2026.

Referência técnica para integração

XPath completo
/nfeProc/protNFe
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
TProtNFe
Preenchimento no catálogo
Obrigatório

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.