Rejeição 897: cNF em formato inválido na NF-e
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A Rejeição 897, regra B03-10 do serviço de autorização, verifica a formação do cNF, código numérico que integra a chave de acesso. Na documentação atual conferida, a regra se aplica à NF-e modelo 55. O modelo 65 está rasurado na tabela do MOC e na NT 2019.001 v1.70; o histórico da NT registra sua retirada na versão 1.40.
Quais são os dois testes da regra?
O primeiro proíbe esta lista expressa de códigos de oito algarismos:
00000000, 11111111, 22222222, 33333333, 44444444, 55555555, 66666666, 77777777, 88888888, 99999999, 12345678, 23456789, 34567890, 45678901, 56789012, 67890123, 78901234, 89012345, 90123456 e 01234567.
O segundo proíbe cNF igual a nNF, número da nota. Não basta evitar a lista: a comparação com nNF é outra condição. cNF é código numérico da chave; nNF é numeração fiscal. Não os confunda nem mude a numeração fiscal para fazer o teste passar.
Por que XSD pode aceitar e a SEFAZ rejeitar
O schema verifica o domínio estrutural do campo; uma sequência de oito algarismos pode caber nesse domínio e ainda estar na lista proibida pela regra de negócio. Da mesma forma, o XSD de cNF isolado não compara seu valor com nNF.
O fato de modelo 65 ter sido retirado desta regra não dispensa o formato estrutural da NFC-e nem suas demais regras. Também não significa que se deva selecionar modelo 65 para contornar uma rejeição: o modelo do documento depende da operação e das condições aplicáveis, não de uma estratégia para passar no teste.
Exemplos dos testes, sem chave fictícia
Cenário sintético A: cNF é 12345678 e nNF tem outro valor. O primeiro teste já encontra um código expressamente vedado; a desigualdade com nNF não o libera.
Cenário B: cNF e nNF representam o mesmo valor numérico, embora a serialização use comprimentos e zeros de preenchimento diferentes. Confira o valor de cada campo conforme seu domínio, preservando sua representação no XML. É o segundo teste que precisa ser investigado.
Cenário C: uma resposta identificada como 897 parece pertencer a NFC-e. Confirme modelo, XML enviado, serviço e retorno original. A extração textual 55/65 sem a rasura não basta para afirmar a aplicação atual ao modelo 65.
Não há XML completo nem código alternativo sugerido: o diagnóstico usa valores expressamente proibidos e comparações textuais, sem gerar uma chave de acesso operacional.
Onde corrigir e como verificar
No documento rejeitado, identifique como o gerador escolheu cNF. Compare a lista completa e nNF, e corrija o processo gerador conforme o perfil documentado, preservando os dados reais. Como cNF integra a chave, uma correção implica reconstrução coerente de Id, DV e assinatura antes de eventual nova tentativa autorizada; não edite só o campo em XML já assinado.
Se a nota já tiver autorização ou comunicação incerta, consulte a situação e preserve sua identidade antes de qualquer ação. Não gere nova numeração por tentativa. Depois da correção comprovada, valide a estrutura e a coerência da chave e interprete o retorno individual: resolver 897 não garante aprovação nas demais regras.
Leituras relacionadas
Fontes oficiais
- MOC 7.0 Anexo I — 7.00: A03-10 p. 74; B02-10, B02-20, B03-10 e B06-10 p. 75.
- NT 2019.001 — 1.70: histórico versão 1.40 p. 5 e B03-10 p. 15 (rasura do modelo 65).
- Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe, linhas 6686–6770.