Rejeição 822: data e hora do hash posteriores ao evento

A rejeição 822 indica que a data e hora informadas para a geração do hash da entrega ficaram posteriores à emissão do evento. O problema pertence ao registro de um evento associado à NF-e; receber esse retorno não significa que a nota anteriormente autorizada perdeu sua autorização. Antes de corrigir qualquer informação, identifique qual evento foi enviado e conserve sua resposta completa.

Existem dois contextos documentados: o Comprovante de Entrega da NF-e e o Insucesso na Entrega da NF-e. Embora compartilhem o código, seus campos e serviços têm diferenças. Uma orientação que manda alterar a data de emissão da nota ou reenviar sua autorização pode atuar sobre o documento errado e criar outro problema operacional.

Campo correto em cada serviço

Na NT 2021.001 v1.01, o evento de comprovante tem tpEvento=110130. A data de geração do hash é dhHashComprovante, campo P36. A regra P36-10, página 9, rejeita esse instante quando superior à emissão do evento, informada em dhEvento. A data da entrega efetiva é outro campo, dhEntrega, e possui uma validação própria.

Na NT 2023.005 v1.02, o insucesso tem tpEvento=110192. Seu campo correspondente é dhHashTentativaEntrega, P37, descrito na página 7. A regra P37-10, página 10, mantém a comparação com a emissão do evento. Aqui o fato registrado é uma tentativa que não terminou em entrega, identificada por dhTentativaEntrega. A expressão resumida “Hash de Entrega” da mensagem não muda esse significado.

As duas regras aparecem como obrigatórias dentro dos respectivos serviços. Esses contextos tratam da NF-e modelo 55. A descrição numérica isolada não estende o procedimento à NFC-e ou a um evento do CT-e. As notas também descrevem adesão facultativa à implementação pelas empresas; isso não transforma um evento enviado em dispensado das suas validações.

Reconstrua a sequência verdadeira

Separe o instante da emissão da NF-e, a entrega ou tentativa, a geração do hash e a emissão do evento. Consulte o XML efetivamente transmitido e os registros da aplicação que preparou a evidência. Um horário apresentado na tela pode estar formatado de maneira diferente daquele gravado no arquivo.

Se o hash foi produzido depois que o evento já havia sido montado, a integração pode ter preservado um dhEvento antigo. Se o relógio do dispositivo estava incorreto, a origem do problema pode estar na captura ou na conversão de horário. Essas são hipóteses para conferir nos registros, não conclusões que o código comprove sozinho.

Confira também o fuso associado a cada instante. Representações com deslocamentos diferentes precisam ser comparadas como instantes equivalentes, não apenas pela parte numérica das horas. Não retire o deslocamento nem acrescente horas arbitrariamente. Corrigir uma conversão exige recuperar o horário real e manter a rastreabilidade entre o registro de origem e o XML gerado.

Exemplo para orientar a investigação

Considere um evento preparado às 14h, enquanto o arquivo de evidência só teve seu hash gerado às 14h12, no mesmo fuso. Se o XML conservar 14h para dhEvento e informar 14h12 no campo do hash, há uma ordem incompatível com a comparação descrita. O exemplo não representa uma operação real nem determina qual horário uma empresa deve preencher.

A equipe precisa descobrir se o evento foi montado prematuramente, se houve reaproveitamento de dados ou se algum relógio estava incorreto. Confirmada a causa, deve ajustar a rotina responsável e regenerar o evento com informações verdadeiras. Não deve antecipar artificialmente o hash, trocar a evidência por qualquer arquivo ou modificar a data da NF-e autorizada.

Se ambos os horários parecerem corretos, preserve os arquivos e encaminhe o caso ao suporte com o retorno e a versão da integração. Uma divergência entre o instante exibido e aquele transmitido pode exigir análise técnica. Evite diversas tentativas com horários escolhidos por aproximação, pois elas dificultam a identificação da origem.

O que não resolve esta rejeição

A 822 não é uma divergência do conteúdo criptográfico do hash, nem uma validação do total de imposto. O hash da evidência também não é o mesmo objeto que a assinatura digital do evento. A correção deve respeitar a geração do arquivo e a assinatura aplicável; editar manualmente o XML já assinado não constitui um procedimento de regeneração confiável.

As tolerâncias de cinco minutos citadas para outras comparações, como data do evento versus processamento ou autorização, não aparecem como concessão na P36-10 ou P37-10. Não as transfira para a 822. Da mesma forma, a validação não autoriza omitir uma informação verdadeira apenas para esconder uma inconsistência. A presença e o preenchimento dos campos devem seguir o leiaute efetivamente adotado.

O serviço de comprovante é descrito na NT 2021.001 no Ambiente Nacional; o insucesso, na v1.02 da NT 2023.005, é direcionado à SVRS. Verifique endpoint e ambiente na configuração atual da integração, sem copiar endereços de homologação para produção. Esta análise documental não comprova disponibilidade do serviço para uma instalação concreta do ALRA.

Confirme o resultado de cada evento

Após a correção, confira a resposta individual, a chave associada, o tipo, o sequencial e o protocolo retornado. Um lote com código 128 foi processado, mas seus eventos ainda podem conter rejeições. O registro vinculado à nota é identificado pelo retorno próprio do evento; não o confunda com autorização de uma nova NF-e.

Se outra mensagem aparecer, trate a nova condição sem concluir que o desaparecimento da 822 significa conclusão de todo o fluxo. Conserve a tentativa anterior e a corrigida para comparação. Ao acionar o suporte, envie somente os dados necessários por canal adequado, sem expor certificado, senha ou material particular da entrega em um chamado público.

Fontes

Conferência em 16/10/2026: NT 2021.001 v1.01, páginas 3–6, 9 e 10; NT 2023.005 v1.02, páginas 3–8, 10 e 11. PDFs HTTP200 capturados hoje; leitura textual selecionada, sem novo render, XSD ou teste fiscal.

Três corpos específicos confrontados: FlexDocs, insucesso, documentação de parâmetros e tabela; Focus NFe, panorama das versões; InvoiSys, contexto histórico da v1.00 de 2021. Todos tiveram HTTP200 novo. Conversões da DLL, exemplos e limites próprios do produto não são instruções ALRA; o panorama Focus mistura referências antigas ao Ambiente Nacional e obrigação geral com a descrição posterior da SVRS. As primárias delimitam os dois serviços. Não houve transmissão ou validação de evidência individual.