Toda vez que você transmite uma NF-e ou NFC-e, a SEFAZ responde com um código de status — o cStat. Quando o retorno é 100, a nota foi autorizada. Quando cai na faixa 2xx, você levou uma rejeição: a nota não foi armazenada e precisa ser corrigida e reenviada. Antes de mais nada, vale entender a diferença entre nota autorizada, rejeitada e denegada — cada situação exige uma ação diferente.
Rejeição não é bug, é dado errado
A boa notícia: a esmagadora maioria das rejeições não tem nada a ver com a sua integração. São problemas de cadastro (destinatário, IE, CFOP), de cálculo (total da nota que não bate com a soma dos itens) ou de formatação do XML (um caractere inválido, um campo com espaço sobrando). Ou seja: quase tudo dá pra pegar antes de bater na SEFAZ.
Os códigos de rejeição mais comuns
Tabela de rejeições frequentes
| cStat | Significado | Como resolver |
204 | Duplicidade de NF-e | Já existe uma nota autorizada com a mesma chave. Consulte a chave na SEFAZ; se já foi autorizada, use-a. Não reenvie com o mesmo número/série. |
217 | NF-e não consta na base da SEFAZ | Você tentou cancelar/consultar uma nota que a SEFAZ não tem. Confirme se a autorização realmente ocorreu antes de acionar eventos. |
225 | Falha no schema XML | Campo com caractere inválido, acento problemático ou espaço no início/fim. Limpe e valide o XML contra o schema oficial antes de transmitir. |
236 | Chave de acesso inválida (DV ou campo) | O dígito verificador ou algum campo que compõe a chave (UF, AAMM, CNPJ, modelo, série, número, cNF) está incorreto. Regere a chave. |
471 | CST/CSOSN incompatível com o regime | Empresa do Simples usando CST em vez de CSOSN (ou o contrário). Ajuste a tributação conforme o regime do emitente. |
531 | Total da nota difere da soma dos itens | O vNF informado não fecha com a soma de produtos + frete + despesas − descontos. Recalcule os totais. |
539 | Duplicidade de chave com diferença de dados | Mesma chave já usada, porém com conteúdo diferente. Gere um novo número de nota; não reaproveite a numeração. |
594 / 610 | Valores de ICMS/total inconsistentes | Base de cálculo ou valor de imposto do item não fecha com a soma da nota. Revise ICMS, ICMS-ST e os totalizadores. |
Cadastro do destinatário
Rejeições de IE inválida e de indicador de destinatário são campeãs. A Inscrição Estadual precisa estar ativa e compatível com a UF; se o cliente é consumidor final sem IE, marque-o como não contribuinte em vez de deixar o campo em branco. Consultar o cadastro do contribuinte na SEFAZ antes de emitir evita boa parte desses erros.
Tributação e CFOP
Muita rejeição de 471 nasce de um CST/CSOSN que não combina com o regime, ou de um CFOP escolhido errado pra operação. Se a empresa é do Simples Nacional, use CSOSN. Se é do regime normal, use CST. Misturar os dois é rejeição na certa.
Certificado digital
Um certificado A1 ou A3 vencido, ou o CNPJ do certificado diferente do emitente, derruba a transmissão antes mesmo da validação da nota. Monitore a validade e renove com antecedência.
No SoftPay, o pré-flight roda antes de qualquer transmissão: ele valida schema, totais, CST/CSOSN, CFOP e cadastro do destinatário, e bloqueia a nota inconsistente antes de ela chegar na SEFAZ — reduzindo drasticamente a taxa de rejeição. Veja os planos.
O reenvio: cuidado com a duplicidade
Ao corrigir e reenviar, o erro mais comum é gerar a duplicidade (204/539). Se a nota anterior já foi autorizada, você não deve reemitir com o mesmo número — deve cancelar a nota e emitir uma nova, ou usar a que já está autorizada. A idempotência na API ajuda aqui: reenviar a mesma requisição não gera duas notas.
Como emitir com menos rejeição
O caminho é validar cedo. Quem emite nota fiscal por API com uma camada de pré-validação pega o problema no seu servidor, com uma mensagem clara, em vez de descobrir só depois do retorno da SEFAZ. Menos rejeição significa menos retrabalho e menos cliente esperando o documento.