Contingência offline da NFC-e

A contingência offline (tipo de emissão 9, tpEmis=9) permite concluir a venda e entregar o DANFE NFC-e ao consumidor quando a SEFAZ não responde. A nota é emitida sem a autorização imediata e transmitida à SEFAZ depois, assim que o serviço volta.

Na NFE.io essa contingência é automática: a plataforma decide quando usá-la, nota a nota, sem nenhuma ação do seu sistema. O que precisa ser feito antes é habilitar a contingência para a inscrição estadual (IE) que emite a NFC-e.

Produto	Nota Fiscal de Consumidor Eletrônica (NFC-e, modelo 65)
Modalidade	Contingência offline, tpEmis=9 (MOC 7.0, Anexo IV)
Como é acionada	Pela plataforma: quando a SEFAZ não responde no prazo, e preventivamente quando a SEFAZ da UF está falhando
Habilitação	Por inscrição estadual, feita pela NFE.io a pedido do cliente
Vale para	Emissão assíncrona (POST .../consumerinvoices) e síncrona (POST .../consumerinvoices/sync)

A NF-e usa outra contingência

Esta página trata só da NFC-e. A NF-e (modelo 55) usa o EPEC, controlado pela estratégia de contingência da IE: veja Estratégia de Contingência.

1. Quando a plataforma emite em contingência

A plataforma usa a contingência offline em dois modos. Os dois só valem para notas de IE habilitada (seção 3).

1.1 Modo reativo: a SEFAZ não respondeu

1. A plataforma envia a nota normalmente (tpEmis=1).
2. A SEFAZ não responde dentro do prazo ou está indisponível.
3. A plataforma gera a nota de novo em contingência:
   • tpEmis=9, com nova chave de acesso (a chave muda porque o tipo de emissão faz parte dela);
   • mesmo número e mesma série;
   • dhCont com a data e hora do momento e xJust igual a "Intermitência na comunicação com a SEFAZ.";
   • XML assinado de novo, com o QR Code da contingência.
4. A nota passa ao status IssuedContingency. O DANFE NFC-e já pode ser entregue ao consumidor.

A chave da tentativa normal fica guardada como chave abandonada. Ela é usada se a SEFAZ tiver autorizado a tentativa normal apesar da falta de resposta (seção 5.2).

Numeração diferente do procedimento do Anexo IV

O Anexo IV veda reutilizar, em contingência, o número de uma NFC-e transmitida em emissão normal e recomenda avançar um número, cancelando ou inutilizando depois a nota pendente. A plataforma mantém o mesmo número e trata a duplicidade de outro jeito: se a tentativa normal tiver sido autorizada, a transmissão da contingência é recusada por duplicidade e a nota volta à chave original (seção 5.2). Assim fica autorizada uma única nota para a venda, mas o procedimento é diferente do descrito no manual. Se a sua UF exigir o procedimento do Anexo IV, fale com o suporte antes de pedir a habilitação.

1.2 Modo proativo: a SEFAZ da UF está falhando

Para não fazer cada consumidor esperar por uma SEFAZ que já está fora, a plataforma mantém um disjuntor por UF:

• Abre depois de 5 falhas seguidas (tempo esgotado ou indisponibilidade) de NFC-e na mesma UF, considerando o tráfego de NFC-e de todas as IEs daquela UF processado pela plataforma, e não só a sua.
• Com o disjuntor aberto, as notas de IEs habilitadas vão direto para tpEmis=9, sem tentar a autorização normal. O dhCont é a data e hora em que o disjuntor abriu.
• Fecha na primeira autorização normal bem-sucedida ou na primeira retransmissão de contingência autorizada naquela UF. Por segurança, o estado do disjuntor expira 24 horas depois da última falha.
• Se o controle do disjuntor estiver inacessível, a plataforma considera o disjuntor fechado e tenta a autorização normal.

1.3 Quando a contingência não é usada

• IE não habilitada: a nota segue o fluxo normal. Na emissão assíncrona, a plataforma consulta a nota pela chave ou tenta de novo. Na emissão síncrona com a SEFAZ indisponível, a nota é recusada (Error) e o pedido pode ser reenviado (seção 6).
• Rejeição da SEFAZ (por exemplo, erro de cadastro ou de cálculo): rejeição não é indisponibilidade. A nota termina em Error, com o código e o motivo da SEFAZ.
• Falha ao gerar a nota em contingência (certificado, QR Code ou gravação do XML): a nota em contingência é descartada.
  • Modo reativo: a nota segue as regras da IE não habilitada (acima).
  • Modo proativo: não houve tentativa normal. Na emissão síncrona a nota é recusada (HTTP 200 com Error); na assíncrona, a emissão é tentada de novo, em contingência enquanto o disjuntor seguir aberto.

2. Desenho do fluxo

2.1 Emissão

2.2 Transmissão posterior

2.3 Situações da nota

3. Como habilitar e desabilitar

A contingência offline é habilitada por inscrição estadual: uma empresa com várias IEs pode ter só algumas habilitadas. Não há rota da API para isso. A habilitação é uma configuração da plataforma, feita pela NFE.io.

3.1 Pré-requisitos

1. A UF permite a contingência offline para o emitente. O uso dessa modalidade é decisão de cada UF, que pode não autorizá-la para todos ou para determinados contribuintes (MOC 7.0, Anexo IV, item 2). Confirme com a SEFAZ da sua UF.
2. IE do tipo NFC-e com CSC cadastrado (identificador e código). O QR Code da contingência é gerado com o CSC.
3. Estratégia de troca de autorizador da IE igual a Manual (campo processingDetails.switchAuthorizerStrategy). É a única aceita na NFC-e. Ela é pré-requisito da emissão, e não liga a contingência offline sozinha.
4. Seu sistema preparado para o status IssuedContingency, o webhook issued_contingency e a impressão do DANFE em contingência (seção 4).

3.2 Como pedir

Abra um chamado com o suporte da NFE.io informando:

• o companyId da empresa;
• o id de cada inscrição estadual (stateTaxId) que deve usar a contingência offline.

A equipe da NFE.io inclui as IEs na configuração da plataforma e confirma pelo chamado quando a contingência estiver ativa. A habilitação é por inscrição estadual (stateTaxId), sem configuração separada por ambiente.

3.3 Como desabilitar

Pelo mesmo caminho: abra um chamado informando as IEs que devem deixar de usar a contingência. Depois da desabilitação, novas notas dessas IEs não entram mais em contingência. As notas que já estiverem em IssuedContingency continuam sendo transmitidas até a autorização, porque já são documentos fiscais emitidos e precisam ser regularizados.

Campos contingencyOn e contingencyJustification

O pedido de emissão da NFC-e aceita os campos contingencyOn (dhCont) e contingencyJustification (xJust), mas eles não têm efeito: a plataforma não os usa para acionar a contingência nem para preencher o XML. A entrada em contingência, a data e a justificativa são sempre definidas pela plataforma.

4. O que muda para o seu sistema

4.1 Na resposta da API e no webhook

Situação	Emissão assíncrona	Emissão síncrona (/sync)
Nota emitida em contingência	Webhook consumer_invoice com a ação issued_contingency	HTTP 200 com status = IssuedContingency
Contingência autorizada depois	Webhook issued_successfully	Webhook issued_successfully
Rejeitada na transmissão posterior	Webhook issued_error	Webhook issued_error
Tentativas esgotadas	Webhook issued_failed	Webhook issued_failed

Sobre o webhook issued_contingency:

• é enviado só na emissão assíncrona. Na síncrona, o sinal é a própria resposta HTTP;
• a entrega ao seu endpoint segue a política de entrega dos demais eventos, mas o evento é registrado uma única vez, sem nova tentativa: se esse registro falhar, o webhook não é gerado;
• por isso, não dependa só dele. O status da nota e o webhook issued_successfully da autorização posterior são os sinais definitivos.

Na consulta da nota (GET .../consumerinvoices/{id}), a nota em contingência traz:

• status: IssuedContingency até a autorização, depois Issued;
• contingencyDetails:
  • startedOn: data e hora da entrada em contingência (dhCont);
  • reason: justificativa (xJust);
  • abandonedAccessKey: chave da tentativa normal descartada, presente só no modo reativo;
  • authorizer: vem como Normal na contingência offline (o campo identifica o autorizador da contingência da NF-e e não se aplica aqui). Use status para saber se a nota está em contingência.

Guarde o id da nota, e não a chave de acesso, como identificador no seu sistema: a chave muda na entrada em contingência e pode voltar à chave original na reconciliação (seção 5.2).

4.2 No DANFE NFC-e

O DANFE NFC-e (GET .../consumerinvoices/{id}/pdf) de uma nota em contingência traz:

• "EMITIDA EM CONTINGÊNCIA", mensagem obrigatória pelo Anexo IV, e "Pendente de autorização da SEFAZ";
• a data e hora de entrada em contingência e a justificativa (o Anexo IV não exige a impressão desses dois campos);
• o QR Code da contingência, com os dados que essa modalidade exige (dia da emissão, valor total e digest value).

O PDF gerado pela plataforma é a via do consumidor (traz "Via Consumidor"). Na emissão em contingência, o Anexo IV também pede que o estabelecimento mantenha à disposição do fisco, até a autorização:

• uma segunda via do DANFE NFC-e, identificada como "Via do Estabelecimento", impressa junto com o Detalhe da Venda; ou
• a guarda eletrônica do arquivo XML da nota, em local seguro, com a possibilidade de imprimir o DANFE quando o fisco solicitar.

A plataforma não gera a "Via do Estabelecimento". Use a alternativa da guarda eletrônica, baixando o XML da nota (GET .../consumerinvoices/{id}/xml). A UF pode dispensar essa obrigação.

Consulta pelo consumidor

Até a autorização, a nota não aparece na consulta pública da SEFAZ nem na leitura do QR Code. O Anexo IV alerta para esse risco de reclamação do consumidor.

5. Transmissão posterior

5.1 Ciclo

• A primeira transmissão acontece logo depois da emissão, e as seguintes a cada 10 minutos, sempre com o XML da contingência já assinado (a nota não é gerada de novo).
• O prazo legal para transmitir é o fim do primeiro dia útil seguinte à emissão (MOC 7.0, Anexo IV, item 2). O ciclo de 10 minutos regulariza a nota assim que a SEFAZ volta, bem antes desse prazo.
• Depois de 100 envios sem resposta (cerca de 16 horas de SEFAZ fora do ar), a nota termina com issued_failed. Nesse caso, acione o suporte da NFE.io para retomar a transmissão dentro do prazo legal.

5.2 Duplicidade: a tentativa normal tinha sido autorizada

No modo reativo, a SEFAZ pode ter autorizado a tentativa normal mesmo sem ter respondido a tempo. Como a nota em contingência usa o mesmo número e a mesma série, a SEFAZ recusa a contingência por duplicidade e informa a chave da nota já autorizada.

Quando essa chave é a chave abandonada, a plataforma reconcilia:

• a nota volta a ter a chave original (tpEmis=1);
• a autorização é obtida pela consulta da chave;
• a nota termina como Issued, com issued_successfully.

Fica autorizada uma única nota para a venda. Não é preciso cancelar nem inutilizar nada.

5.3 Rejeição na transmissão

Se a SEFAZ rejeitar a nota em contingência (por exemplo, um dado do cadastro que ela só valida na autorização), a nota termina em Error com issued_error, o código e o motivo da rejeição.

A venda já aconteceu e o consumidor já recebeu o DANFE. Para esse caso o Anexo IV orienta: "gerar novamente o arquivo com a mesma numeração e série, sanando a irregularidade e transmitir novamente".

A regeneração não é feita por um novo pedido de emissão

Um novo POST cria outra nota, com nova data de emissão e emissão normal. Ele não regera a nota em contingência com a mesma numeração. Quando uma nota em contingência for rejeitada, acione o suporte da NFE.io informando o id da nota e o motivo da rejeição.

6. Emissão síncrona (/sync)

O /sync usa um orçamento de tempo que reserva parte da requisição para, se preciso, emitir em contingência:

• Orçamento no worker: 10 segundos.
• Prazo da autorização na SEFAZ: o menor valor entre 8 segundos e (10 segundos − tempo já decorrido no worker − 2 segundos de reserva), com mínimo de 1 segundo.
• Reserva de 2 segundos: é descontada do prazo da SEFAZ para sobrar tempo de gerar e assinar a nota em contingência.

Os 10 segundos são um orçamento, não um limite rígido. As etapas de preparo (assinatura, gravação do XML), o cálculo de impostos e a criação da nota na API não são interrompidos por ele. Configure no seu sistema um tempo limite de espera bem maior que 10 segundos.

Situação	HTTP	status
Autorizada no prazo	200	Issued
SEFAZ sem resposta ou indisponível, IE habilitada	200	IssuedContingency
Rejeitada pela SEFAZ	200	Error, com o cStat e o motivo
SEFAZ indisponível, IE não habilitada	200	Error: o pedido pode ser reenviado; se o número da nota recusada não for reaproveitado no reenvio, ele deve ser inutilizado
Payload ou cadastro inválido	400	Não criada
Cálculo de impostos rejeitado	422 (código 42201)	Error
Nota ainda em processamento ao fim do prazo	503	Processing: o resultado chega por webhook
Serviço de cálculo de impostos indisponível	503	Não criada: o pedido pode ser reenviado

7. Regras complementares

• Cancelamento: só depois que a nota em contingência for autorizada (status Issued).
• Inutilização: não inutilize o número de uma NFC-e emitida em contingência. Ela é um documento fiscal já entregue ao consumidor e precisa ser autorizada (seção 5). A plataforma não bloqueia essa inutilização quando a nota termina em Error, então a responsabilidade é do emitente. Para os números que devem mesmo ser inutilizados, use POST /v2/companies/{companyId}/consumerinvoices/disablements: a resposta traz o protocolo da SEFAZ, e o XML do comprovante (procInutNFe) fica disponível em GET .../consumerinvoices/disablements/xml, informando a mesma faixa.
• Carta de Correção: não existe para a NFC-e.
• EPEC: não é usado na NFC-e. A única contingência da NFC-e na plataforma é a offline.

8. Parâmetros da plataforma

Parâmetro	Valor	Quem define
Habilitação da contingência offline	Por inscrição estadual	NFE.io, a pedido do cliente
Falhas seguidas que abrem o disjuntor da UF	5	NFE.io
Expiração do estado do disjuntor	24 horas após a última falha	NFE.io
Intervalo da transmissão posterior	10 minutos	NFE.io
Envios até issued_failed	100	NFE.io
Orçamento de tempo da emissão síncrona no worker	10 s	NFE.io
Prazo da autorização síncrona	até 8 s	NFE.io
Reserva para a contingência (síncrona)	2 s	NFE.io

9. Responsabilidades do emitente

1. Confirmar com a SEFAZ da UF que a contingência offline é permitida para o estabelecimento.
2. Pedir a habilitação das IEs à NFE.io e manter o CSC e a estratégia Manual da IE em dia.
3. Tratar o status IssuedContingency e os webhooks issued_contingency, issued_successfully, issued_error e issued_failed.
4. Entregar ao consumidor o DANFE NFC-e com a indicação de contingência e manter à disposição do fisco a "Via do Estabelecimento" com o Detalhe da Venda ou o XML da nota (seção 4.2).
5. Acionar o suporte da NFE.io para regularizar, dentro do prazo legal, as notas em contingência que terminarem com rejeição (seção 5.3).
6. Usar o id da nota, e não a chave de acesso, como referência no seu sistema.

10. Perguntas frequentes

Existe uma API para habilitar a contingência offline? Não. A habilitação é feita pela NFE.io, por inscrição estadual, a pedido do cliente (seção 3).

Meu sistema precisa pedir a contingência quando a SEFAZ cair? Não. A plataforma decide nota a nota e emite em contingência sozinha quando a IE está habilitada.

Posso escolher a data e a justificativa da contingência? Não. Os campos contingencyOn e contingencyJustification do pedido não têm efeito. A plataforma preenche o dhCont e o xJust.

A nota em contingência é válida? Sim. É um documento fiscal emitido, que acompanha a venda e precisa ser transmitido à SEFAZ no prazo legal. A plataforma faz essa transmissão.

Posso cancelar uma nota em contingência? Só depois de autorizada. Enquanto estiver em IssuedContingency, o cancelamento é recusado.

A chave de acesso muda? Sim. A nota em contingência tem chave própria, porque o tipo de emissão faz parte da chave. Se a tentativa normal tiver sido autorizada, a nota volta à chave original (seção 5.2).

11. Referências

• MOC 7.0, Anexo IV: Padrões Técnicos de Contingência Off-line NFC-e (Portal Nacional da NF-e).
• Ajuste SINIEF 19/16: NFC-e.
• Processamento, resiliência e contingência, seção 11.3.
• Fluxos de processamento, seções 3.3 e 3.4.