--- title: "Contingência offline da NFC-e" description: "Como a NFE.io emite a NFC-e em contingência offline (tpEmis 9): quando a contingência é acionada, como habilitar e desabilitar, o que muda na resposta da API, nos webhooks e no DANFE NFC-e, a transmissão posterior à SEFAZ e as responsabilidades do emitente." source_url: https://nfe.io/docs/documentacao/nota-fiscal-consumidor/integracao-api/contingencia-offline-nfce/ product: documentacao last_updated: 2026-10-09 tags: ["nfce", "contingencia", "contingencia-offline", "tpemis-9", "sefaz"] --- # 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`) | :::info 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](../../nota-fiscal-produto-eletronica/integracao-api/estrategia-de-contingencia.md). ::: ## 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). :::warning 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 ```mermaid flowchart TD P["Pedido de emissão da NFC-e
(assíncrono ou /sync)"] --> HB{"IE habilitada para
contingência offline?"} HB -- não --> N0["Autorização normal (tpEmis=1)"] HB -- sim --> DJ{"Disjuntor da UF
está aberto?"} DJ -- sim --> OFF2["Emite direto em tpEmis=9
dhCont = abertura do disjuntor"] DJ -- não --> N1["Autorização normal (tpEmis=1)"] N1 --> R1{"Resposta da SEFAZ"} R1 -- "autorizada" --> OK["Issued
issued_successfully"] R1 -- "rejeitada" --> ER["Error
issued_error (cStat e motivo)"] R1 -- "sem resposta no prazo
ou indisponível" --> CNT["+1 falha no disjuntor da UF"] CNT --> OFF1["Gera de novo em tpEmis=9
mesmo número, nova chave
dhCont = agora"] OFF1 --> IC["IssuedContingency
DANFE com 'EMITIDA EM CONTINGÊNCIA'"] OFF2 --> IC IC --> WH["Assíncrona: webhook issued_contingency
Síncrona: HTTP 200 com status IssuedContingency"] WH --> TR["Transmissão posterior (2.2)"] N0 --> R0{"Resposta da SEFAZ"} R0 -- "autorizada" --> OK R0 -- "rejeitada" --> ER R0 -- "sem resposta ou indisponível" --> NN["Fluxo normal, sem contingência
(consulta pela chave ou nova tentativa)"] ``` ### 2.2 Transmissão posterior ```mermaid flowchart TD S["1ª tentativa logo após a emissão,
depois a cada 10 minutos"] --> A["Envia o XML da contingência,
já assinado, à SEFAZ"] A --> R{"Resposta"} R -- "autorizada" --> M["Issued
issued_successfully
fecha o disjuntor da UF"] R -- "duplicidade com a chave abandonada
(a tentativa normal foi autorizada)" --> RC["Prevalece a nota original (tpEmis=1):
consulta pela chave e conclui"] RC --> M2["Issued
issued_successfully"] R -- "sem resposta ou indisponível" --> S R -- "rejeitada" --> ER["Error
issued_error"] S -. "100 envios sem resposta
(cerca de 16 h)" .-> FL["Error
issued_failed"] ``` ### 2.3 Situações da nota ```mermaid stateDiagram-v2 [*] --> Processing: pedido aceito Processing --> Issued: autorizada (tpEmis=1) Processing --> IssuedContingency: IE habilitada e SEFAZ sem resposta
ou disjuntor da UF aberto Processing --> Error: rejeitada IssuedContingency --> Issued: transmissão autorizada
ou reconciliada com a original IssuedContingency --> Error: rejeitada na transmissão
ou tentativas esgotadas Issued --> Cancelled: cancelamento ``` ## 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. :::note 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](../../webhooks/catalogo-saida/catalogo-saida-nfce.md) 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. :::caution 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". :::caution 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 | Mais detalhes em [Processamento, resiliência e contingência](../../nota-fiscal-produto-eletronica/arquitetura-e-processamento/03-processamento-resiliencia-e-contingencia.md#53-emissão-síncrona). ## 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](../../nota-fiscal-produto-eletronica/arquitetura-e-processamento/03-processamento-resiliencia-e-contingencia.md), seção 11.3. - [Fluxos de processamento](../../nota-fiscal-produto-eletronica/arquitetura-e-processamento/02-fluxos-de-processamento.md), seções 3.3 e 3.4.