Rejeições fiscais
Rejeição 824: data do hash anterior à emissão da NF-e
A rejeição 824 ocorre no registro de eventos relacionados à entrega quando a data e hora declaradas para a geração do hash ficam anteriores à emissão da NF-e. O diagnóstico começa pelo evento transmitido e pela chave vinculada. A mensagem não determina que se altere uma nota já autorizada, nem significa que a emissão…
A rejeição 824 ocorre no registro de eventos relacionados à entrega quando a data e hora declaradas para a geração do hash ficam anteriores à emissão da NF-e. O diagnóstico começa pelo evento transmitido e pela chave vinculada. A mensagem não determina que se altere uma nota já autorizada, nem significa que a emissão dessa nota tenha sido recusada.
O código é utilizado no Comprovante de Entrega e no Insucesso na Entrega da NF-e. Em ambos, a comparação envolve o instante informado para a geração do hash, mas os nomes dos campos são diferentes. Também é necessário separar esse instante da entrega, da tentativa de entrega, da assinatura digital e do processamento pelo serviço.
Onde está a informação examinada
Na NT 2021.001 v1.01, a regra 2P36-10, página 9, compara a data e hora do hash do comprovante com a emissão da NF-e. O campo é dhHashComprovante, descrito na página 6. Ele pertence ao evento 110130, Comprovante de Entrega, enquanto dhEntrega informa quando a entrega terminou. Corrigir o segundo campo não resolve necessariamente uma inconsistência do primeiro.
Na NT 2023.005 v1.02, a regra conserva a identificação 2P36-10, página 10, mas o leiaute do insucesso utiliza dhHashTentativaEntrega, P37. O evento é 110192, e o horário da tentativa está separado em dhTentativaEntrega. A diferença entre o número da regra e o identificador do campo não autoriza criar uma tag com nome deduzido ou reaproveitar o campo do outro evento.
As linhas estão classificadas como obrigatórias nos serviços documentados para a NF-e modelo 55. Não se deve aplicar essa orientação automaticamente a uma NFC-e, a um evento do CT-e ou a outro documento com código semelhante. As notas técnicas descrevem implementação facultativa pelas empresas; quem utiliza o evento continua sujeito às condições do respectivo serviço.
Verifique a origem do horário
Preserve o XML enviado, a resposta completa e a referência da evidência utilizada. Recupere a NF-e autorizada correspondente à chave. Compare sua emissão com o horário de geração do hash que a integração realmente gravou. Não substitua a conferência do arquivo pela data mostrada em uma lista ou pela hora atual do computador.
Investigue se o registro pertence à nota correta, se houve reaproveitamento de uma informação anterior ou se o aplicativo atribuiu ao campo uma data diferente da geração do hash. A data de criação de um arquivo no sistema operacional, por exemplo, não deve ser assumida como prova suficiente do instante fiscal declarado. É preciso compreender como a aplicação produziu esse valor.
Confira ainda o fuso e a conversão entre dispositivos, servidor e XML. Representações locais diferentes podem corresponder ao mesmo instante; compará-las sem considerar o deslocamento pode produzir uma conclusão errada. A regularização de uma conversão deve preservar o momento verdadeiro, com registros que permitam reconstruir o tratamento realizado.
Um exemplo de associação trocada
Considere uma evidência cujo hash foi gerado às 8h e que acabou vinculada a uma NF-e emitida às 9h do mesmo dia, no mesmo fuso. O XML apresenta uma sequência incompatível com a regra. Os horários são apenas ilustrativos e não constituem uma recomendação de preenchimento para uma operação concreta.
Antes de trocar qualquer data, confirme se a evidência pertence àquela NF-e. Ela pode ter sido recuperada de outro atendimento ou associada por um identificador interno incorreto. Se o vínculo estiver errado, a correção precisa alcançar a associação e a rotina que a produz. Não copie um horário posterior apenas para fazer o evento passar.
Se a informação corresponder ao fato real e a sua relação com a nota exigir esclarecimento, encaminhe o conjunto ao suporte e à área fiscal. A validação técnica não resolve sozinha uma irregularidade na sequência documental. Também não justifica substituir o comprovante, fabricar uma tentativa de entrega ou retroagir a emissão da NF-e autorizada.
Cuidados ao corrigir a integração
A 824 trata do horário declarado para o hash. Ela não afirma que o algoritmo, o conteúdo da imagem ou a assinatura digital estejam corretos ou incorretos. Esses elementos possuem outras exigências. Não troque o conteúdo criptográfico indiscriminadamente quando o problema apontado é temporal; primeiro identifique a origem da informação e a evidência correspondente.
Os dois leiautes descrevem a data do hash com ocorrência opcional. Essa característica estrutural não deve ser usada como atalho para apagar um dado verdadeiro e esconder uma inconsistência. Avalie o preenchimento no contexto do evento e da integração adotada. Se houver correção legítima, regenere o arquivo e cumpra o fluxo de assinatura, preservando a tentativa anterior.
Não há tolerância de cinco minutos declarada na 2P36-10 desses documentos. As comparações do evento com o processamento ou com a autorização são diferentes. Também não se deve confundir a 824 com a 822, que verifica um horário do hash posterior à emissão do evento, nem com a 823, que examina a entrega ou tentativa anterior à emissão da nota.
Confirme serviço, ambiente e resposta
O Comprovante de Entrega é descrito pela NT 2021.001 no Ambiente Nacional; o insucesso, pela v1.02 da NT 2023.005, na SVRS. Confira a configuração da integração atual e o ambiente correto. Este artigo não certifica que uma instalação do ALRA possua os recursos necessários nem que uma tentativa concreta será aceita.
Depois do reenvio, leia o retorno individual e confira chave, tipo, sequencial, vinculação e protocolo. O processamento do lote, identificado pelo código 128, não garante sucesso de todos os eventos. Se houver outro retorno, conserve-o e trate a condição correspondente. O desaparecimento da 824 não substitui a confirmação documental de que o evento pretendido foi efetivamente registrado.
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 de hoje, reutilizados por hash; leitura textual selecionada, sem novo render ou validação XSD.
Três apoios efetivamente confrontados: FlexDocs, parâmetros e tabela específica 824; Focus NFe, panorama das versões; InvoiSys, panorama histórico de 2021. Os dois panoramas não substituem a leitura das regras. Conversões da DLL, obrigação universal de evento e referências antigas ao serviço foram filtradas. Sem geração de hash real, acesso a evidência particular, transmissão, consulta individual ou teste ALRA.