cStat em infProt: resultado da NF-e e status do lote
<cStat>nfeProc › protNFe › infProt › cStatRevisão editorial em 14 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
cStat, dentro de protNFe/infProt, é o código do resultado de processamento da nota. A ocorrência é do protocolo individual, diferente do status HTTP e do retorno externo de um lote. Saber em qual camada o código aparece é essencial para interpretar o resultado de um documento.
Caminho desta página: /nfeProc/protNFe/infProt/cStat. O prefixo nfeProc identifica a nota processada; este status pertence ao protocolo protNFe/infProt, que acompanha a NF-e e não é um campo do conteúdo de infNFe.
O protocolo individual e os status 100 e 150
O MOC relaciona 100 à autorização de uso e 150 à autorização de uso fora do prazo. A NT 2025.001 v1.03 corrigida trata o código 150 no contexto das regras de data de emissão, mas sua presença continua sendo resultado de autorização. Não interprete 150 como erro apenas por ser diferente de 100.
Para associar o resultado à nota certa, confira infProt/chNFe, ambiente, protocolo e data do recebimento, além do XML da NF-e correspondente. Não forje nProt nem monte um XML processado apenas alterando cStat. O arquivo deve preservar o protocolo autêntico retornado pela autoridade. MOC, tabela cStat, p. 143 e NT 2025.001 v1.03, p. 6.
Exemplo do código sem inventar protocolo
Fragmento sintético somente do campo:
<cStat xmlns="http://www.portalfiscal.inf.br/nfe">100</cStat>
Esse fragmento não é um protocolo completo e não prova que uma nota real foi autorizada. O tipo TStat do pacote PL 010f v1.04 admite três ou quatro algarismos; o comprimento máximo de quatro permite códigos ampliados. Não trunque um retorno de quatro para três posições em um parser antigo, nem converta o código pela suposta categoria do HTTP.
Passar no XSD demonstra somente forma lexical. O significado vem do serviço, contexto e retorno oficial. O exemplo não contém chave, número de protocolo ou assinatura inventados.
Por que 104 ou HTTP 200 não concluem a emissão
104 significa lote processado; 105 significa lote em processamento; 103 identifica lote recebido. Esses status descrevem outro estágio e não substituem o cStat de cada protNFe/infProt. Um lote processado pode conter um resultado individual de rejeição.
HTTP 200 indica que a resposta foi transportada com sucesso no HTTP, sem afirmar que uma NF-e recebeu autorização fiscal. Status de eventos, como cancelamento, também possuem serviços e mensagens próprios. O parser deve preservar a camada de onde cada resultado veio e correlacionar notas individualmente. MOC, tabela de processamento, p. 143.
Duplicidade 204 e conclusão local incompleta
204 descreve duplicidade; não prova, sozinho, que o XML atualmente armazenado seja o autorizado ou que o protocolo esteja recuperado. A NT 2018.005 v1.52 documenta a possibilidade, a critério da UF, de retornar o protocolo na duplicidade quando DigestValue corresponde à nota autorizada. A comparação do conteúdo é significativa; não se pode unir qualquer XML a um protocolo de outra nota.
Se um aplicativo mostra pendência mas há protocolo autêntico 100 ou 150 correspondente, investigue recuperação do XML, arquivos e vínculo do estado local. Autorização do provedor e conclusão local são evidências distintas. Um retorno incerto ou duplicidade não autoriza reenviar ou gerar nova numeração automaticamente. NT 2018.005 v1.52, p. 23–24.
Roteiro de conferência antes de qualquer ação
Identifique ambiente, emitente, modelo, chave e operação original. Leia o retorno completo, localize o protocolo individual e compare chNFe com o XML exato. Se o fluxo ainda está em processamento, use as consultas correspondentes ao estado conhecido. Se há rejeição, investigue a regra real descrita em xMotivo, sem tratar a codificação estrutural como autorização.
Para documentos autorizados, confira persistência do protocolo, XML e situação consultada. Registre a diferença entre falha de comunicação, falha do aplicativo e rejeição fiscal. Esses passos de diagnóstico não autorizam transmissão, cancelamento, correção ou reparo de dados sem as precondições e autorizações cabíveis. A página ensina interpretação técnica, sem escolher o tratamento tributário.
A estrutura que contém este campo é explicada em infProt.
Fontes oficiais
- Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe/infProt/cStat em leiauteNFe; TStat em tiposBasico, padrão de 3 a 4 algarismos
- Tipos básicos NF-e/NFC-e — PL_010f_v1.04: TStat, linhas 79–88: padrão
[0-9]{3,4}, código de mensagem com três ou quatro algarismos. - NT 2025.001 — QR-Code e simplificação operacional — 1.03 corrigida, setembro/2025: Simplificação operacional e autorização fora do prazo, p. 6; regra B09-20/150 e exceções, p. 9.
- MOC 7.0 — Anexo I — 7.00, novembro/2020: Tabela de códigos de resultado de processamento, p. 143.
- NT 2018.005 — responsável técnico — 1.52, julho/2025: Seção 4.5 e regra 2B08-20/204: retorno de protocolo em duplicidade condicionado ao DigestValue, p. 23–24.
Referência técnica para integração
- XPath completo
/nfeProc/protNFe/infProt/cStat- 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
- TStat · string
- 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.
- maxLength
4- pattern
[0-9]{3,4}- whiteSpace
preserve