A NFCom não aceita carta de correção — e a nota rejeitada nem fica guardada

Quem vem da NF-e tem um reflexo: errou um dado que não muda valor, emite uma carta de correção e segue. Na NFCom esse reflexo não tem para onde ir — a norma veda expressamente a carta de correção.

E o outro lado da mesma cláusula é igualmente pouco conhecido: a nota rejeitada não fica guardada na administração tributária. Não há histórico oficial do que você tentou emitir e não passou.

Neste artigo

A frase que fecha a porta

Depois que a administração tributária concede a autorização de uso, a norma diz:

“Após a concessão da autorização de uso, a NFCom não poderá ser alterada, sendo vedada a emissão de carta de correção para sanar erros da NFCom.”

São duas proibições em uma linha. A primeira é geral — a nota não muda. A segunda é específica e fecha o atalho que existe em outros documentos: não há carta de correção, nem para erro pequeno, nem para dado que não afeta imposto.

O que sobra são os caminhos que a própria norma desenhou, todos eles com nota nova: a substituição, a nota de ajuste ou o acerto na nota do mês seguinte — e o cancelamento, que quebra tudo o que aponta para a nota.

Nenhum deles é um bilhete anexado ao documento original. Todos produzem um documento novo, com número novo e efeito próprio. É a diferença prática entre corrigir e reemitir.

Tabela comparando os dois estados: a nota autorizada fica disponível para consulta e não pode mais ser alterada porque a carta de correção é vedada; a nota rejeitada não é arquivada para consulta e admite reenvio do mesmo arquivo em apenas três das seis hipóteses.
As duas pontas da cláusula nona: o que a administração tributária guarda quando a nota é autorizada e quando é rejeitada.

O arquivo rejeitado não é arquivado

Agora o outro lado. Quando a nota não passa, o parágrafo seguinte determina que, em caso de rejeição, o arquivo não será arquivado na administração tributária para consulta.

Isso tem uma consequência operacional direta e frequentemente ignorada: não existe, na SEFAZ, um histórico das suas tentativas rejeitadas. O que passou está lá para consulta; o que não passou não está em lugar nenhum, exceto no seu sistema.

Para quem opera faturamento em lote — que é o caso do provedor, com uma nota por assinante — isso muda o desenho do emissor. Se ele não guardar o XML rejeitado e a mensagem devolvida, a informação some. Não há para onde recorrer depois para reconstituir por que 40 assinantes ficaram sem nota no dia 5.

Os seis motivos de rejeição da norma

A cláusula lista as hipóteses em que a administração tributária cientifica o emitente da rejeição do arquivo:

  1. irregularidade fiscal do emitente;
  2. falha na recepção ou no processamento do arquivo;
  3. falha no reconhecimento da autoria ou da integridade do arquivo digital;
  4. emitente não credenciado para emissão da NFCom;
  5. duplicidade de número da NFCom;
  6. outras falhas no preenchimento ou no leiaute do arquivo.

Vale notar a proporção: cinco motivos nomeados e um item final que é um saco — “outras falhas no preenchimento ou no leiaute”. É nesse último que mora a esmagadora maioria das rejeições do dia a dia, porque é ali que cabem as centenas de regras de validação do manual, item a item.

Os motivos de número 1 e 4 são de cadastro e já os tratamos pelos códigos que o sistema devolve — 203 para emissor não habilitado e 205 para situação irregular perante o Fisco. O que interessa aqui é o que a norma permite fazer depois de cada um.

Tabela com os seis motivos de rejeição da cláusula nona: irregularidade fiscal, falha na recepção ou processamento e falha na autoria ou integridade admitem reenviar o mesmo arquivo; emitente não credenciado, duplicidade de número e outras falhas de preenchimento ou leiaute não constam da permissão.
Os seis motivos de rejeição previstos na norma e quais deles admitem nova transmissão do mesmo arquivo.

Os três que admitem nova transmissão — e a assimetria que salta aos olhos

A norma não trata as seis hipóteses do mesmo jeito. Ela permite ao interessado nova transmissão do arquivo da NFCom apenas nas hipóteses “a”, “b” e “c”:

  • irregularidade fiscal do emitente;
  • falha na recepção ou no processamento;
  • falha no reconhecimento da autoria ou da integridade.

Repare no que essas três têm em comum: em nenhuma delas o conteúdo do arquivo é o problema. A nota está correta; o que estava errado era a situação da empresa, a infraestrutura ou a assinatura. Resolvido o impedimento, o mesmo arquivo pode ser enviado de novo.

Nas outras três, o arquivo em si precisa mudar: não adianta reenviar o mesmo XML se o número está duplicado, se o emitente não está credenciado ou se o leiaute está errado. É leitura literal do texto — a permissão de nova transmissão é dada às três primeiras alíneas, e a norma não diz o que fazer nas demais porque, nelas, o que se envia depois já é outro arquivo.

E há uma assimetria que vale enxergar. As hipóteses “a” (irregularidade fiscal) e “d” (não credenciado) são ambas de cadastro — nas duas, a nota está certa e a empresa é que está impedida. Ainda assim, só a primeira aparece na lista de retransmissão. Não vamos inventar a razão; registramos que o texto trata as duas de forma diferente e que, na prática, a única que a norma garante que você reenvia depois de resolver é a irregularidade fiscal.

Duplicidade: o caso em que insistir é o erro

A hipótese “e” ilustra bem por que a norma não estendeu a permissão de retransmissão a todas as seis. Quando o número já está na base, mandar de novo é repetir uma pergunta que já foi respondida — e o autorizador devolve, junto com a recusa, o protocolo e a data da nota que já existe.

Já detalhamos esse par de códigos e a diferença entre eles em texto próprio: a rejeição 204 e a 539 dizem que sua nota já está autorizada. O ponto que interessa aqui é apenas este: o número foi consumido, e a numeração avança. Nenhuma retransmissão desfaz isso.

O protocolo tem de dizer o porquê, de forma clara e precisa

A cientificação da rejeição não é um “não” seco. A norma exige que o protocolo devolvido contenha informações que justifiquem, de forma clara e precisa, o motivo pelo qual a autorização de uso não foi concedida.

É uma obrigação da administração tributária, e ela existe porque o emitente precisa do motivo para corrigir. O mesmo protocolo, quando a nota passa, traz a chave de acesso, o número da NFCom, a data e a hora do recebimento e o número do protocolo — podendo ser autenticado com certificação digital da própria administração.

Para o provedor, isso vira um critério de escolha de sistema: o emissor mostra a mensagem devolvida, ou traduz tudo para “erro ao emitir”? A norma garante que o motivo chegou; se ele não aparece na tela de quem opera, o problema é do software, não da SEFAZ.

A leitura: o registro do que deu errado é seu

Esta é a nossa leitura, e ela junta as duas metades da cláusula: a NFCom trata a autorização como fato consumado e a rejeição como não-fato — e nas duas pontas o registro sobra para quem emite.

Autorizada, a nota fica imutável: nenhuma carta de correção alcança o que já foi dito. Rejeitada, ela não existe para o Fisco: nenhuma consulta futura mostra o que você tentou. Entre os dois extremos não há uma zona cinzenta de “documento em correção” — algo que quem vem de outros documentos fiscais leva um tempo para internalizar.

Três consequências práticas:

  1. Guardar o rejeitado é obrigação de fato, não de norma. Como o arquivo não é arquivado na SEFAZ, o log do emissor é a única prova de que a tentativa existiu e do motivo alegado. Isso importa em qualquer conversa posterior sobre nota faltante em uma competência.
  2. Reenviar não é estratégia de correção. Só faz sentido nas três hipóteses em que o conteúdo estava certo. Nas demais, insistir com o mesmo arquivo consome tempo e devolve o mesmo código — e, no caso da duplicidade, ainda embaralha a numeração.
  3. Erro pequeno custa nota nova. Sem carta de correção, corrigir o nome do logradouro do assinante tem o mesmo custo processual de corrigir um valor: substituição, ajuste ou acerto no mês seguinte. Isso deveria empurrar o esforço para a qualidade do cadastro antes da emissão, que é onde ele é barato.

A pergunta útil ao fornecedor do emissor, portanto, não é “o sistema emite carta de correção?” — ele não pode. É: “quando uma nota é rejeitada, onde fica guardado o XML recusado e a mensagem que a SEFAZ devolveu?”

Onde conferir

As regras e os códigos são os vigentes na data desta apuração e podem mudar por ajuste ou nota técnica. O tratamento de cada hipótese de rejeição e a forma de regularização dependem também da legislação da sua unidade federada — confirme nela antes de desenhar o procedimento interno.

Fontes: Ajuste SINIEF nº 7, de 7 de abril de 2022, do Conselho Nacional de Política Fazendária — CONFAZ, em texto consolidado (cláusula nona: cientificação do emitente quanto à concessão da autorização de uso ou à rejeição do arquivo, com as seis hipóteses de rejeição — irregularidade fiscal do emitente, falha na recepção ou no processamento do arquivo, falha no reconhecimento da autoria ou da integridade do arquivo digital, emitente não credenciado, duplicidade de número e outras falhas no preenchimento ou no leiaute; § 1º, segundo o qual, após a concessão da autorização de uso, a NFCom não poderá ser alterada, sendo vedada a emissão de carta de correção para sanar erros; § 2º, pelo qual o arquivo rejeitado não será arquivado na administração tributária para consulta, sendo permitida nova transmissão do arquivo nas hipóteses das alíneas “a”, “b” e “c”; § 3º, sobre o protocolo disponibilizado ao emitente ou a terceiro por ele autorizado, com chave de acesso, número da NFCom, data e hora do recebimento e número do protocolo, podendo ser autenticado com certificação digital da administração tributária; e § 4º, que exige do protocolo, nos casos de rejeição, informações que justifiquem de forma clara e precisa o motivo pelo qual a autorização não foi concedida); e Manual de Orientação do Contribuinte da NFCom — Anexo I, Leiaute e Regras de Validação, versão 1.00a, no portal DF-e da SVRS (item 2.1, Regras de Validação Básicas do Serviço, com os grupos D — Validação do Certificado de Assinatura — e E — Validação da Assinatura Digital; regras G39 e G40, que consultam a base pela chave UF, CNPJ do emitente, modelo, série e número e devolvem os códigos 539 e 204 acompanhados do protocolo e da data de autorização da nota já existente; e regras G16 e G19, com os códigos 203 para emissor não habilitado e 205 para emitente em situação irregular perante o Fisco).

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *