Contingência offline na DC-e: como tratar o tpEmis=2 sem deixar lacuna fiscal
Guia técnico para times que precisam garantir continuidade operacional quando o ambiente da SEFAZ falha, sem gerar passivo fiscal.
Resumo executivo
O que você vai entender neste post:
Por que a contingência da DC-e merece tr//atamento próprio, diferente da contingência da NF-e. O que é o tpEmis=2 e quando seu sistema deve acionar. Por que tpEmis (tipo de emissão) e tpEmit (tipo de emitente) são campos diferentes e como cada um se relaciona com os 5 perfis de emissor. Como funciona o QR-Code assinado com o parâmetro sign e por que ele é o ponto mais subestimado da implementação. Qual é o prazo de transmissão posterior e o que acontece quando ele não é cumprido. A nova regra B02-20 que entra em produção em 08/06/2026 e que sua squad precisa endereçar agora.
Por que contingência em DC-e é tema próprio
A DC-e (Declaração de Conteúdo eletrônica) foi instituída pelo Ajuste SINIEF 05/2021 e teve sua obrigatoriedade prorrogada para 6 de abril de 2026 pelo Ajuste SINIEF 22/2025. Diferente da NF-e tradicional, a DC-e atende cenários em que não há documento fiscal tradicional para acobertar o transporte. Por isso, o leiaute prevê 5 perfis distintos de emissor, identificados no XML pelo campo tpEmit (com “t” no final).
Conforme a NT 2024.001 v1.10, publicada em Março/2026, esses 5 perfis são:
tpEmit=0 (Fisco): emissão via aplicativo disponibilizado pela administração tributária. Cenário típico do cidadão pessoa física emitindo sua própria declaração para acobertar transporte de bens pessoais.
tpEmit=1 (Marketplace): plataforma emite DC-e como representante do vendedor (pessoa física ou jurídica não contribuinte). Cenário típico de venda C2C entre usuários.
tpEmit=2 (Emissor próprio): empresa jurídica não contribuinte de ICMS, com sistema próprio integrado ao ambiente autorizador. Cenário típico de distribuidoras, prestadores de serviço com transporte ocasional, instituições.
tpEmit=3 (Transportadora): operador de transporte emite em nome do cliente quando o remetente não consegue. Cenário típico em redespacho e logística distribuída.
tpEmit=4 (ECT): Empresa Brasileira de Correios e Telégrafos, com assinatura digital própria. Cenário com regras específicas, incluindo prazo de cancelamento estendido para até 15 dias.
Essa diversidade de emissor muda o desenho da contingência. Não dá para assumir que existe equipe fiscal de plantão para resolver problema de transmissão. Não dá para assumir que o usuário emitente tem cultura de conformidade fiscal. A contingência da DC-e precisa ser silenciosa, automática, e à prova de descuido.
É por isso que tratar contingência aqui como “mais uma flag” no XML é o caminho mais comum para gerar passivo fiscal silencioso. Sistemas marketplace registrando o tpEmis sem ter desenhado o fluxo de transmissão posterior. Transportadoras emitindo em contingência durante todo o turno porque “está dando erro”. Tudo isso vira problema.
O que é tpEmis=2 e quando acionar
O campo tpEmis, no XML da DC-e (campo B08 do leiaute), identifica a forma de emissão do documento. Conforme a NT 2024.001 v1.10, os valores válidos são apenas dois:
tpEmis=1: Emissão normal (não em contingência) tpEmis=2: Contingência off-line da DC-e
Importante: tpEmis (tipo de emissão) é campo diferente de tpEmit (tipo de emitente). O tpEmis indica como o documento foi emitido (normal ou em contingência). O tpEmit indica qual dos 5 perfis está emitindo. Os dois campos coexistem no grupo B (Identificação da DC-e) e precisam ser preenchidos coerentemente.
Atenção a um ponto que costuma confundir squads que migraram de NF-e ou NFC-e: na DC-e, o valor de contingência offline é 2, não 9. Versões anteriores da NT chegaram a alinhar com o padrão de NFC-e (tpEmis=9), mas a versão 1.10 corrigiu o leiaute para refletir o schema oficial. Quem implementou com tpEmis=9 em versões antigas precisa revisar.
Acionar tpEmis=2 é permitido quando há falha técnica que impeça a autorização imediata da DC-e pelo ambiente da SEFAZ. Em prosa simples: o seu sistema tentou autorizar, não conseguiu por motivo técnico (timeout, indisponibilidade, erro de comunicação), e o transporte precisa começar.
O que tpEmis=2 não é: não é fallback automático para qualquer erro, e não é o caminho para evitar implementar comunicação síncrona com a SEFAZ. Acionar tpEmis=2 sem critério é o que gera questionamento do Fisco. A regra prática: sua aplicação só deve acionar contingência depois de tentar comunicação normal por tempo razoável (timeout de 30 a 60 segundos), e depois de validar que o erro é de comunicação, não de validação local.
O QR-Code assinado: como funciona o parâmetro sign
Aqui está o ponto mais subestimado da implementação. Quando o sistema emite DC-e em tpEmis=2, ela ainda não foi autorizada pelo Fisco. O transporte começa, mas a fiscalização em trânsito precisa ter como verificar que a DC-e existe e tem validade transitória.
A resposta para isso é o QR-Code impresso no DACE (Documento Auxiliar da DC-e). Esse QR-Code, em contingência, inclui um parâmetro adicional chamado sign, que é a assinatura da chave de acesso feita com o certificado digital do emissor.
Quando a fiscalização consulta o QR-Code, a SEFAZ recebe a chave de acesso e o parâmetro sign. Valida a assinatura usando a chave pública do certificado digital. Se a assinatura é válida, a SEFAZ retorna informação clara: a DC-e foi emitida em contingência, ainda não foi transmitida, e tem prazo até o final do primeiro dia útil subsequente para constar na base.
Sem o parâmetro sign, ou com sign malformado, a fiscalização não consegue verificar autenticidade. O documento é tratado como não existente. O motorista é parado, a carga apreendida, a empresa autuada. É exatamente o cenário que a contingência deveria evitar.
Detalhe importante introduzido pela NT 2024.001 v1.10: o mascaramento de CPF no DACE passou a ser prática recomendada para conformidade com a LGPD. Padrão definido: NNN..-NN. Sistema que imprime CPF completo no DACE está exposto a questionamento sob a Lei Geral de Proteção de Dados.
Prazo de transmissão posterior
A DC-e emitida em contingência precisa ser transmitida ao ambiente da SEFAZ até o final do primeiro dia útil subsequente à emissão. Esse prazo está previsto no Ajuste SINIEF 05/2021 e nos atos COTEPE complementares.
Em prosa simples: se o sistema emitiu DC-e em contingência às 14h de uma terça-feira, a transmissão precisa ocorrer até as 23h59 da quarta-feira. Se a quarta for feriado, vai para quinta. Se a contingência durar mais que o prazo (caso a SEFAZ continue fora do ar), a regra é que a transmissão deve ser tentada imediatamente após o restabelecimento.
Sistemas que não instrumentam esse prazo geram passivo. A SEFAZ não notifica o emissor de que o prazo passou. Cada DC-e em contingência precisa ter, no sistema, um relógio próprio que dispara alerta quando o prazo se aproxima e dispara retry automático quando o ambiente está disponível.
A nova regra B02-20: o que muda em 8 de junho
A NT 2024.001 v1.20, publicada em Maio/2026, criou uma regra de validação que entra em produção no dia 8 de junho de 2026: a regra B02-20.
Em prosa simples: se o código da UF informado no grupo B (identificação da DC-e, campo B02 – cUF) for diferente da UF informada no endereço do emitente, a DC-e será rejeitada com a mensagem 228 (“Código da UF da DCe diferente da UF do emitente”).
Para sistemas que operam emissão em múltiplas UFs ou que tratam roteamento de webservices por estado, essa regra exige verificação prévia. Squads que assumem cUF como configuração global, sem cruzar com o endereço efetivo do emitente, podem começar a ver rejeições logo no início da próxima semana.
A janela para adaptação é curta: implantação em produção restrita foi em 01/06, em produção em 08/06.
Armadilhas comuns na implementação
Tratar contingência como fallback automático sem critério
Sistemas que acionam tpEmis=2 toda vez que a requisição síncrona retorna erro estão fazendo o Fisco questionar uso indevido de contingência. A regra é simples: tente comunicação normal por tempo razoável, classifique o erro (validação local? validação remota? comunicação? indisponibilidade?), e só acione contingência se o erro for de comunicação ou indisponibilidade real.
Esquecer da transmissão posterior
A transmissão posterior, dentro do prazo de um dia útil, é responsabilidade do emissor. Sistemas que não agendam retry automatizado, com persistência da DC-e em fila local até o sucesso, geram passivo. Quando a auditoria descobrir DC-e em contingência sem transmissão posterior, a multa e o questionamento sobre a regularidade da operação vão cair.
QR-Code sem assinatura adequada
Sistema que gera DACE em contingência sem o parâmetro sign no QR-Code está deixando o motorista exposto. Implementar a assinatura corretamente exige: certificado digital ICP-Brasil válido carregado em memória no momento da emissão, geração da assinatura da chave de acesso usando algoritmo correto (RSA com SHA-256), inserção do parâmetro sign no QR-Code no formato esperado pela SEFAZ.
Confundir tpEmis com tpEmit
Squads que implementam DC-e sem ler o leiaute oficial com cuidado tendem a confundir os dois campos. tpEmis tem 1 dígito e identifica forma de emissão (1 ou 2). tpEmit tem 1 dígito e identifica perfil emissor (0 a 4). Os dois campos são obrigatórios e ficam dentro do mesmo grupo no XML (B01 – ide). Confusão entre eles gera rejeição de schema e retrabalho.
Perguntas frequentes
- Quando a DC-e se torna obrigatória em todo o país? A obrigatoriedade nacional foi prorrogada para 6 de abril de 2026 pelo Ajuste SINIEF 22/2025, publicado em 22 de setembro de 2025.
- Quem está obrigado a emitir DC-e? A DC-e tem 5 perfis emissores: Fisco (tpEmit=0, usado por pessoas físicas via aplicativo do Fisco), Marketplace (tpEmit=1), Emissor próprio (tpEmit=2, empresas jurídicas não contribuintes com sistema próprio), Transportadora (tpEmit=3) e ECT (tpEmit=4).
- Qual a diferença entre tpEmis=1 e tpEmis=2? O tpEmis=1 indica emissão normal, com autorização síncrona pela SEFAZ antes do início do transporte. O tpEmis=2 indica contingência offline, em que o transporte começa antes da autorização, mediante geração local da chave de acesso e QR-Code assinado. São os dois únicos valores válidos do campo tpEmis na DC-e, conforme a NT 2024.001 v1.10.
- Por que outras fontes públicas dizem tpEmis=9? A versão 1.0 da NT 2024.001, publicada em setembro de 2024, alinhava o leiaute da DC-e com o padrão de tpEmis da NFC-e (que usa 9 para contingência offline). A versão 1.10, publicada em março de 2026, corrigiu o leiaute para tpEmis=2 conforme o schema oficial. Material publicado antes dessa correção pode estar desatualizado.
- Se a SEFAZ ficar fora do ar por mais de um dia útil, o que fazer? A regra prática é tentar transmissão imediatamente após o restabelecimento. A SEFAZ tende a flexibilizar prazo em casos comprovados de indisponibilidade prolongada, mas a documentação interna do emissor sobre as tentativas de transmissão é fundamental para defesa em caso de auditoria.
- Posso usar contingência para evitar problemas de validação local? Não. Contingência (tpEmis=2) é exclusiva para falhas de comunicação com o ambiente do Fisco. Problemas de validação local (XSD, campos obrigatórios, regras de negócio) devem ser corrigidos antes da emissão, não escondidos via contingência.
- O que muda no dia 8 de junho de 2026? A regra B02-20, criada pela NT 2024.001 v1.20, entra em produção: a UF informada no grupo B (cUF) precisa coincidir com a UF do endereço do emitente. Sistemas com configuração de cUF desacoplada do endereço efetivo passam a receber rejeição 228.
- Onde posso baixar um Guia que me ajuda a entender melhor o DC-e? Baixe aqui o seu Guia Prático que descomplica a Declaração de Conteúdo Eletrônica.
Referências
Migrate ao seu lado com a DC-e
A DC-e é um documento de nicho com volume crescente em marketplace, transportadora e plataformas de venda entre pessoas físicas. Sua complexidade não está em emitir em condição normal, está em todo o conjunto de casos de borda: contingência offline (tpEmis=2), transmissão posterior, retry, validação de QR-Code, mascaramento de CPF no DACE, e os 5 modelos de emissão com tpEmit próprio e regras de validação cruzadas.
A Migrate trata cada um desses casos como cidadão de primeira classe na arquitetura do InvoiCy. Se sua software house atende um dos cenários típicos de DC-e, vale uma conversa técnica para ver como integrar.