Rejeição 712: UF não aceita a contingência offline da NFC-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 712, regra B22-20, ocorre na NFC-e 65 quando tpEmis=9 indica contingência offline e a UF não aceita essa modalidade. A regra é facultativa porque depende da permissão estadual. O código não informa, por si só, qual modalidade deve substituir o offline nem autoriza declarar emissão normal para um documento emitido em contingência. MOC 7.0, Anexo I, p. 76-77.
Que precondições precisam ser confirmadas?
Confira mod=65, tpEmis=9, UF do emitente, ambiente e serviço usado na tentativa. Depois verifique a regra oficial da UF para contingência offline no contexto e na data da emissão. A configuração disponível no software ou a experiência de outra empresa em outro estado não comprovam aceitação estadual.
O MOC distingue a modalidade offline 9 de EPEC4, esta a critério da UF. Cada uma tem pressupostos e procedimentos próprios. A indicação 9 no XML não prova que a contingência foi realmente caracterizada ou que os demais requisitos foram cumpridos.
Como diferenciar 712, 714 e 704?
A 712 é a restrição estadual para offline 9. A 714/B22-34 verifica modalidades de contingência inválidas na NFC-e, com a ressalva de EPEC4 a critério da UF. A 704 verifica atraso de recepção nos documentos abrangidos e também tem exceções estaduais.
Uma UF que aceita offline não necessariamente aceita transmissão fora de qualquer prazo. Tampouco a ausência de atraso transforma uma modalidade não permitida em válida. A NT 2026.002 amplia o domínio 9 para NF-e 55 com Tipo 2, mas a B22-20 identificada nesta página trata NFC-e 65. NT 2026.002 v1.11, p. 3, 7 e 8.
Exemplos de parametrização e política estadual
Exemplo sintético: uma implantação copia tpEmis=9 de outra UF e passa a gerar todas as NFC-e como offline. O retorno 712 exige comparar a permissão da UF atual e a modalidade real. Se as emissões eram online, o problema pode ser uma configuração indevida; isso precisa ser demonstrado pelos registros da tentativa.
Em outro caso, houve indisponibilidade real e emissão offline, mas a UF não admite esse procedimento no contexto considerado. Não se corrige reclassificando retroativamente como emissão normal. Reúna documentação, horário, retorno e orientação estadual para definir o tratamento cabível com os responsáveis.
O que comprova uma solução?
A análise deve mostrar a política oficial da UF, a modalidade real e a origem do indicador no XML. Corrija somente a divergência comprovada; quando falta a confirmação estadual, essa é a informação necessária, não uma tentativa com outro valor.
Preserve documentos e histórico de contingência. Consulte o resultado remoto de tentativa incerta antes de novo envio. Após qualquer correção cabível, valide a coerência da modalidade e confira o retorno individual. HTTP 200 e XML válido não demonstram que a UF aceitou o documento fiscal.
Os exemplos são cenários sintéticos de diagnóstico. Os valores são apresentados em texto para comparação; não constituem um XML fiscal pronto para transmitir. A conferência operacional exige o XML original e o retorno da mesma tentativa.