Rejeição 569: data de contingência muito antiga na nota

A rejeição 569 aponta uma entrada em contingência excessivamente antiga em relação à emissão da NF-e ou NFC-e. A investigação deve comparar dhCont com dhEmi e descobrir por que essas datas ficaram afastadas. Um parâmetro antigo, uma digitação errada ou uma fila mal administrada podem explicar o problema.

Não resolva trocando automaticamente a contingência para hoje ou retrocedendo a emissão. Os campos precisam representar os fatos. Se os registros estiverem corretos e a situação realmente ultrapassar o limite aceito, será necessário tratar a regularização com o responsável fiscal e o suporte do autorizador, preservando o histórico.

Qual é a referência de tempo

A B28-40 do MOC 7.0, Anexo I, página 78 relaciona o código 569 ao marco de 30 dias entre a data de entrada em contingência e a data de emissão. A aplicação está indicada como facultativa para os modelos 55 e 65 no serviço de autorização.

A redação da tabela apresenta a comparação com “data de emissão – 30 dias” e usa “menor ou igual”. Não a interprete como uma ordem para tornar a contingência ainda mais antiga. A mensagem identifica justamente antiguidade excessiva. Materiais práticos descrevem casos acima de 30 dias; em uma ocorrência no limite exato, confirme a avaliação do autorizador, com os horários e fusos completos, em vez de prometer aceitação de uma fronteira não testada.

Para o empresário, a distinção mais importante é esta: a comparação se refere à emissão da nota. Não é uma autorização para ficar 30 dias sem transmitir documentos, nem um prazo geral para circular mercadorias em contingência.

O que cada data representa

DhCont é o começo da ocorrência de contingência que deu origem ao documento. DhEmi é a emissão da nota. O momento de transmissão ou de recebimento pela SEFAZ é outro registro.

Uma nota antiga reenviada hoje não tem, necessariamente, problema nessa comparação. Se a entrada em contingência e a emissão estavam próximas, o simples passar do tempo não aumenta a diferença entre esses dois campos. O atraso do envio pode gerar outras consequências, mas não deve ser confundido automaticamente com o 569.

A TecnoSpeed destaca a leitura conjunta de dhCont e dhEmi e o caráter facultativo da regra. Evite substituir “30 dias” por “um mês” em cálculos: meses têm durações diferentes.

Exemplo: o sistema reaproveitou uma ocorrência antiga

Imagine uma distribuidora fictícia que teve uma falha em agosto. Em outubro, ocorre um novo incidente, mas o componente fiscal reaproveita a data de agosto ao gerar uma nota atual. A emissão é recente, enquanto dhCont aponta para um evento de mais de 40 dias antes.

O erro está no vínculo com a ocorrência antiga. Se os logs confirmam que a contingência atual começou em outubro, o campo deve ser corrigido para esse início verdadeiro. Não é uma renovação artificial da contingência; é a reparação de um dado que não correspondia ao incidente correto.

A Berga chama atenção para parâmetros que continuam ligados e datas reaproveitadas. Use essas hipóteses para conferir o sistema, sem concluir que toda rejeição prova desorganização ou que nenhuma indisponibilidade possa durar muito tempo.

Exemplo: o atraso é real

Em outro cenário, os registros confirmam que a contingência começou muito antes da emissão e os dados foram gravados corretamente. Aqui, não existe um erro de digitação a corrigir. Aproximar as datas apenas para passar na validação alteraria a história do documento.

A orientação da Oobj apresenta a relação entre os campos e exemplos de ajuste. Qualquer mudança de data só deve ser aplicada quando corrige um dado comprovadamente errado. Não trate a possibilidade técnica de editar um campo como autorização fiscal para reescrever a ocorrência.

Reúna os fatos, confira a modalidade, os documentos já emitidos e os prazos aplicáveis. O responsável fiscal deve determinar o procedimento de regularização cabível junto à UF. Não assuma que basta voltar ao tipo normal, cancelar algo ou gerar outro número.

Roteiro de conferência

1. Confirme o retorno 569 da nota individual, o modelo, a UF e o ambiente.

2. Consulte a situação da chave e reconcilie tentativas anteriores sem resposta. Preserve XML, protocolos e registros de contingência.

3. Compare dhCont e dhEmi completos, incluindo hora e deslocamento de fuso.

4. Verifique troca de mês ou ano, valores padrão, cache e reaproveitamento de configurações entre ocorrências.

5. Corrija somente os dados cuja divergência em relação aos fatos estiver demonstrada.

6. Gere e assine novamente pelo emissor, valide o documento e acompanhe a resposta do autorizador.

Se for necessário corrigir dhEmi, confira os reflexos na chave de acesso e em documentos relacionados, especialmente quando houver mudança de mês. Não edite a chave isoladamente. O sistema deve manter a consistência entre identificação, XML e assinatura, depois de verificada a situação das tentativas anteriores.

O que muda entre modalidades e versões

A observação do MOC que desconsidera a hora em versões inferiores à 3.0 é histórica. Nos leiautes atuais, não elimine os horários para reduzir artificialmente a diferença.

A presença de uma regra para 55/65 não permite qualquer modalidade nos dois modelos. Na NFC-e, off-line e EPEC, quando admitido pela UF, têm condições específicas; SVC não autoriza modelo 65. Na NF-e, formulários de segurança, EPEC e SVC também não são procedimentos intercambiáveis.

A NT 2026.002 v1.11, páginas 3, 7 e 8 contempla off-line para NF-e com DANFE Simplificado Tipo 2, sob condições próprias. Confira disponibilidade por UF e ambiente. Essa mudança não converte os 30 dias do 569 em prazo de transmissão. SCAN é histórico, e o valor 3 hoje está associado ao regime NFF.

Como evitar que a fila volte a parar

Controle a abertura e o encerramento de cada ocorrência. As próximas emissões e as notas pendentes precisam ser tratadas separadamente: voltar ao normal não deve apagar o histórico da fila que nasceu em contingência.

Monitore documentos sem resultado final, responsáveis pela regularização e prazos próprios de cada modalidade. Testes de homologação não autorizam vendas em produção. Não compartilhe certificado ou senha para pedir ajuda; encaminhe os campos necessários por canal adequado.

A correção termina quando a situação fiscal estiver confirmada e o XML autorizado, com protocolo correspondente, estiver arquivado. Alterar uma data e conseguir avançar para outra tela não basta.

Revisão documental por IA: 9 de outubro de 2026. Escopo: autorização de NF-e e NFC-e, com ressalva explícita sobre a redação e a fronteira temporal da B28-40.