Rejeição 714: contingência inválida na 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 714, regra B22-34, trata de NFC-e 65 encaminhada à SEFAZ com opção de contingência inválida. A condição lista tpEmis=2, 4 e 5, com ressalva expressa: EPEC, tipo 4, pode ser aceito a critério da UF. A aplicação é facultativa. A existência do valor no domínio compartilhado não comprova permissão para NFC-e. MOC 7.0, Anexo I, p. 76-77.
Quais modalidades a regra distingue?
No domínio, 2 identifica contingência com formulário de segurança FS-IA; 5, FS-DA; 4, EPEC, Evento Prévio de Emissão em Contingência. A regra B22-34 relaciona esses valores ao modelo 65. Isso é diferente da existência estrutural dos códigos no schema utilizado também pela NF-e 55.
A ressalva de EPEC4 exige confirmação oficial da UF e do contexto da emissão. Não se deduz essa autorização de uma opção disponível no software, de um evento preparado localmente ou de experiência em outro estado. Modalidade escolhida e procedimento realmente executado devem corresponder.
Offline 9 e SVC6/7 resolvem automaticamente?
Não. A 712/B22-20 confere se a UF aceita offline 9. A 783/B22-70 estabelece que NFC-e não é autorizada pela SVC, de modo que trocar 2 por 6/7 não é um atalho. A 570 também verifica tipos SVC enviados ao serviço normal.
A NT 2026.002 amplia o domínio offline 9 para NF-e 55 com Tipo 2, mas não converte FS-IA ou FS-DA em contingências de NFC-e. Tampouco a aceitação estadual de EPEC dispensa seus procedimentos próprios. NT 2026.002 v1.11, p. 3, 7 e 8.
Exemplos de herança da NF-e e EPEC estadual
Exemplo sintético: a NFC-e 65 recebe tpEmis=5 por reutilização da configuração de contingência da NF-e 55. O modelo e o indicador do XML demonstram a combinação rejeitada. Investigue por que a configuração atravessou os fluxos e qual modalidade efetivamente ocorreu; não substitua o valor por 9 sem essa confirmação.
Em outro cenário, tpEmis=4 corresponde a um procedimento EPEC real. A conclusão depende de a UF aceitar esse uso para NFC-e. Se houver permissão documentada e mesmo assim retornar 714, confronte ambiente, endereço, XML e condição implementada. Se faltar permissão, não presuma a exceção.
Como comprovar a correção?
Rastreie a origem de tpEmis e confronte os registros da emissão, os documentos auxiliares e os procedimentos de contingência executados. Corrija divergências demonstradas da configuração/serialização. Uma escolha fiscal/procedimental ainda pendente precisa ser confirmada com os responsáveis e com a SEFAZ, levando essas evidências.
Preserve histórico e identidade da nota. Se existe tentativa sem resultado conclusivo, consulte antes de novo envio. Não modifique XML autorizado ou reclassifique retroativamente uma emissão normal como contingência. Após ação cabível, confira o retorno individual e não apenas o HTTP.
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.