Rejeições da SEFAZ na NF-e: 19 códigos e como corrigir

Tabela de rejeições: código, descrição oficial e correção

A tabela reúne 19 rejeições ligadas a certificado, assinatura, numeração, datas, schema, cadastro, totais e classificação fiscal. A descrição está copiada literalmente da Tabela de Códigos de Rejeição do Anexo I. A causa e a correção se limitam ao que diz a regra de validação indicada. A fonte oficial não publica ranking de frequência.

Textos conforme o MOC 7.0 – Anexo I, versão 7.00 (novembro de 2020), publicado no Portal Nacional da NF-e e consultado em 23/09/2026. Notas Técnicas posteriores podem alterar regras. “Facul.” no Anexo I indica regra aplicada a critério da UF. Os trechos entre colchetes (como [nItem: 999]) são modelos do manual para dados que a SEFAZ acrescenta à mensagem, como o número do item.

Duplicidade de numeração: 204 e 539

As rejeições 204 e 539 aparecem quando a SEFAZ já tem em sua base uma NF-e com o mesmo modelo, UF, emitente, série e número. Na 204 a nota existente não está cancelada nem denegada; na 539 a numeração coincide, mas a Chave de Acesso é diferente, por exemplo por outro Código Numérico. Antes de reenviar, consulte a situação da nota já registrada.

• 204 “Rejeição: Duplicidade de NF-e [nRec:999999999999999]”: regra 2B08-20, obrigatória. A Observação 2 da regra diz que, a critério da UF, quando o DigestValue for igual ao da NF-e autorizada, a SEFAZ poderá retornar o protocolo de autorização.
• 539 “Rejeição: Duplicidade de NF-e com diferença na Chave de Acesso [chNFe: 99999999999999999999999999999999999999999999][nRec:999999999999999]”: regra 2B08-10, facultativa (aplicada a critério da UF). A mensagem devolve a chave já cadastrada, o que permite localizar a nota original.
• Na prática, reenviar após um timeout pode levar a essas rejeições. Consulte primeiro e só gere nova numeração se o documento for realmente outro.

Certificado digital e assinatura: 213, 280, 281 e 297

Estas rejeições vêm das validações de certificado e de assinatura digital, feitas antes das regras de negócio. A 280 e a 281 tratam do certificado usado na conexão (transmissor); a 213 compara o CNPJ-base do certificado de assinatura com o do emitente; a 297 indica que a assinatura não confere com o valor calculado. A correção é sempre no certificado ou no XML assinado.

• 280 “Rejeição: Certificado Transmissor inválido” e 281 “Rejeição: Certificado Transmissor Data Validade”: regras A01 e A02. O Anexo I informa que as validações A01 a A05 são realizadas pelo protocolo TLS.
• 213 “Rejeição: CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital”: regra F03. Se o certificado de assinatura tem CNPJ, o CNPJ-base dele deve ser o mesmo do emitente, exceto quando o certificado for da SEFAZ da UF.
• 297 “Rejeição: Assinatura difere do calculado”: regra F02. O SignatureValue difere do valor calculado; o XML enviado precisa ser exatamente o que foi assinado.

Data e hora de emissão: 228 e 703

Duas regras do grupo B conferem a data-hora de emissão contra o momento em que a SEFAZ recebe a nota. A 703 recusa emissão com horário posterior ao recebimento, aceitando tolerância de até 5 minutos por sincronismo de relógio. A 228 recusa NF-e cuja emissão ocorreu há mais de 30 dias, ou outro limite definido pela SEFAZ. Relógio sincronizado resolve a primeira; data correta, a segunda.

• 703 “Rejeição: Data-Hora de Emissão posterior ao horário de recebimento”: regra B09-10, modelos 55 e 65.
• 228 “Rejeição: Data de Emissão muito atrasada”: regra B09-20, modelo 55, emissão normal ou SVC-AN/SVC-RS. A regra permite que a UF aplique a rejeição a qualquer tipo de emissão.

Valores e totais: 610, 564 e 629

As rejeições de totais aparecem quando um valor declarado não bate com a soma ou o produto que a regra define. A 629 compara, item a item, vProd com vUnCom × qCom; a 564 compara o total de produtos com a soma dos itens que compõem o total; a 610 confere o valor total da nota. As três regras são facultativas, isto é, aplicadas a critério de cada UF.

• 629 “Rejeição: Valor do Produto difere do produto Valor Unitário de Comercialização e Quantidade Comercial [nItem: 999]”: regra I11-10, só para NF-e normal (finNFe = 1). A nota (*4) do manual manda arredondar o produto em duas casas decimais, com tolerância de R$ 0,01 para mais ou para menos.
• 564 “Rejeição: Total do Produto / Serviço difere do somatório dos itens”: regra W07-10. Considere somente os itens com indTot = 1.
• 610 “Rejeição: Total da NF difere do somatório dos Valores compõe o valor Total da NF.”: regra W16-10. A composição do vNF é definida na própria regra e pode ter sido alterada por Notas Técnicas posteriores; confira a versão vigente no Portal antes de ajustar o cálculo.

Cadastro de emitente e destinatário: 230, 245 e 233

Estas rejeições saem da consulta que a SEFAZ faz ao cadastro de contribuintes. A 230 indica que a Inscrição Estadual do emitente não está cadastrada na UF; a 245, que o CNPJ do emitente não consta no cadastro consultado; a 233, que a IE do destinatário não está cadastrada na UF de destino. A correção começa conferindo o dado informado contra o cadastro, não o software emissor.

• 230 “Rejeição: IE do emitente não cadastrada”: regra 1C17-10, modelos 55 e 65.
• 245 “Rejeição: CNPJ Emitente não cadastrado”: regra 1C17-60, mensagem opcional (facultativa) usada quando a IE não está vinculada ao CNPJ/CPF.
• 233 “Rejeição: IE do destinatário não cadastrada”: regra 5E17-10, modelo 55.

Como isso aparece numa integração via API

Na API da FOX NF-e a emissão é assíncrona. A resposta 202 significa que o documento foi enfileirado, não que a SEFAZ o autorizou. Só o estado authorized, com o protocolo correspondente, confirma a autorização. O estado rejected indica recusa pela SEFAZ. Por isso uma rejeição chega depois, na consulta de status ou por webhook.

• Estados documentados: pending, processing, authorized, rejected e failed; sair de pending não é, por si só, autorização.
• Webhook nfe.rejected: “NF-e rejeitada pela SEFAZ”.
• Diante de status ambíguo (timeout, 5xx, conexão perdida), a documentação orienta consultar o status antes de reemitir, o que evita as rejeições 204 e 539 descritas acima.
• Consulta de códigos: GET /api/v1/nfe/rejeicoes e GET /api/v1/nfe/rejeicoes/{cstat}, com autenticação Bearer. Um cStat que não tenha 3 dígitos retorna 422 com {"error": "cstat_invalido"}.
• Erros de validação da própria API chegam como 422 com o mapa errors; erros de autenticação, como 401/403.

A disponibilidade depende de documento, UF, ambiente e operação; consulte a documentação. Detalhes de autenticação, webhooks e estados estão na documentação da API da FOX NF-e.

Perguntas frequentes sobre rejeições da NF-e

As respostas abaixo resumem pontos que costumam gerar dúvida ao tratar rejeições: o que o código significa, como ele difere de uma denegação, o caso da duplicidade 204, a variação entre UFs e o comportamento numa integração. Cada resposta se apoia nas fontes oficiais listadas no fim da página ou na documentação pública da API.

Para as mudanças do IBS e da CBS no documento fiscal, veja o cronograma oficial do IBS/CBS na nota fiscal.

Elaborado pela equipe fiscal da Central Fox Tecnologia LTDA com auxílio de IA a partir das fontes oficiais listadas; as citações foram conferidas automaticamente contra o texto da fonte. Conteúdo informativo; não substitui orientação contábil ou jurídica. Atualizado em 23/09/2026.