Quando o sistema reenvia uma NFCom que já foi autorizada, a SEFAZ responde com rejeição. Mas há duas rejeições diferentes para isso — 204 e 539 — e a diferença entre elas aponta para causas opostas.

E há um ponto que muda a forma de tratar as duas: nos dois casos, a resposta traz o protocolo e a data de autorização da nota que já existe. Ou seja, a rejeição está te entregando a prova de que o documento está válido.

Neste artigo

• Código 204 — duplicidade simples
• Código 539 — duplicidade com chave diferente
• A diferença que importa
• Os erros da própria chave: 227, 421 e 253
• A leitura: rejeição de duplicidade não é falha
• Onde conferir

Código 204 — duplicidade simples

A regra G40 faz uma consulta na base da SEFAZ usando a combinação UF, CNPJ do emitente, modelo, série e número. Se já existe uma nota com esses dados, a resposta é rejeição por duplicidade de NFCom — e ela retorna o protocolo e a data de autorização do documento já existente.

É o cenário mais comum: o mesmo documento foi transmitido duas vezes. Queda de conexão no meio do envio, timeout tratado como erro, reprocessamento de fila — o arquivo foi mandado de novo com os mesmos dados.

Código 539 — duplicidade com chave diferente

A regra G39 parte da mesma consulta, mas trata de um caso mais específico: existe nota com aquela combinação, porém o código numérico da chave difere. A rejeição é por duplicidade com diferença na chave de acesso, e a resposta retorna a chave de acesso já autorizada, o protocolo e a data.

Traduzindo: o sistema montou uma chave nova para um documento que já existe. A parte fixa da chave — UF, CNPJ, modelo, série, número — bateu; o código numérico aleatório, não.

A diferença que importa

As duas rejeições dizem “esta nota já existe”, mas apontam para problemas distintos:

• 204 — o mesmo arquivo foi enviado duas vezes. O problema está no controle de envio: a fila reprocessou, ou o retorno da primeira tentativa não foi registrado.
• 539 — o arquivo foi gerado de novo em vez de reenviado. O problema está na geração: o sistema não guardou a chave da primeira emissão e criou outra ao repetir.

A segunda é mais grave, porque indica que o emissor não trata a chave como identidade persistente do documento. Se ele regenera a chave a cada tentativa, qualquer reenvio vira uma nota “nova” do ponto de vista dele — e só a SEFAZ percebe que não é.

Os erros da própria chave: 227, 421 e 253

Antes mesmo de chegar à consulta de duplicidade, a chave passa por três validações estruturais:

• 227 — erro na composição do campo de identificação: falta a literal “NFCom”, ou a chave difere da concatenação dos campos correspondentes.
• 421 — ano da chave inferior a 2022 é inválido. É a data que delimita a existência do documento.
• 253 — dígito verificador inválido na chave resultante da concatenação.

Esses três apontam para montagem incorreta da chave — e, como a chave é composta a partir dos próprios campos da nota, o erro costuma estar num campo, não na chave em si. Vale conferir também as validações do emitente, que rejeitam CNPJ inválido, inscrição estadual não informada e inscrição inválida — o mesmo rigor de cadastro que aparece nas validações de item.

A leitura: rejeição de duplicidade não é falha

Esta é a nossa leitura, e ela muda o tratamento no sistema: uma rejeição por duplicidade é a confirmação de que a nota está autorizada.

A SEFAZ não está recusando o documento — está dizendo que ele já foi aceito antes, e devolvendo o protocolo que comprova isso. O comportamento correto do emissor, ao receber 204 ou 539, é gravar o protocolo retornado e marcar a nota como autorizada, não repetir o envio.

Sistema que trata toda rejeição como erro genérico faz o contrário: reenvia, recebe a mesma rejeição, e pode acabar gerando novas chaves — transformando um problema de controle num problema de geração.

É o mesmo padrão que já apareceu em outras rejeições da NFCom: quando a SEFAZ diz que algo já aconteceu, ela devolve a prova junto. Ler o retorno resolve mais rápido que investigar no próprio banco.

E vale lembrar do parente disso em contingência: ali existe um retorno que também parece erro e é autorização. A regra geral é a mesma — nem todo código diferente do ideal significa que a nota não valeu.

Onde conferir

Os códigos são da versão 1.00a do manual e podem mudar por nota técnica. Antes de programar o tratamento dos retornos no seu emissor, confirme a versão vigente e as particularidades da sua unidade federada.

Fontes: 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 (regras G09, G10, G11, G12, G13, G14, G39 e G40, com os códigos 227, 421, 253, 207, 229, 209, 539 e 204, e o retorno de chave, protocolo e data de autorização); e Perguntas e Respostas sobre a NFCom — GES Comunicações, Receita Estadual do Rio Grande do Sul, sobre a autorização em tempo real e a validação prévia de cada nota.