Rejeição 821: data da entrega posterior à emissão do evento

A rejeição 821 indica que a data e a hora informadas para a entrega estão depois da emissão do evento que pretende registrá-la. O diagnóstico começa pelo XML do evento e pelo retorno recebido. Essa mensagem não significa, por si só, que a NF-e deixou de ser autorizada, foi cancelada ou teve sua numeração liberada para outra operação.

O mesmo código aparece no Comprovante de Entrega da NF-e e no Insucesso na Entrega da NF-e. Apesar de a mensagem mencionar “entrega”, no segundo caso o dado examinado representa a tentativa que não foi concluída. Identificar o evento evita corrigir o campo errado ou transformar uma ocorrência de insucesso em comprovante de recebimento.

Quais informações são comparadas

A regra P30-10 consta como obrigatória nas duas especificações. Para o Comprovante de Entrega, tipo 110130, compara-se detEvento/dhEntrega com infEvento/dhEvento. Para o Insucesso na Entrega, tipo 110192, o primeiro campo é detEvento/dhTentativaEntrega; o segundo continua sendo infEvento/dhEvento.

Nos dois casos, a ocorrência descrita não pode estar no futuro em relação à emissão do evento. A igualdade entre os instantes não configura a condição “superior” da 821, mas também não garante o registro: continuam existindo validações de autoria, chave, situação da NF-e, assinatura, duplicidade e outros campos.

Esses eventos são destinados à NF-e modelo 55. As especificações tratam da entrega relacionada diretamente à NF-e quando ela não estiver vinculada a um CT-e. Uma ocorrência documentada pelo transportador no CT-e exige examinar o serviço correspondente, sem transportar automaticamente o procedimento deste artigo. A NFC-e modelo 65 também não deve ser enquadrada nesses eventos apenas porque uma tela exibe um código parecido.

Localize o instante que foi enviado

Guarde o XML transmitido, o retorno completo, a chave da NF-e, o tipo e a sequência do evento e o ambiente utilizado. Confira os valores presentes no arquivo efetivamente enviado, pois a data mostrada na tela pode ter sido convertida, substituída ou mantida em uma mensagem gerada anteriormente.

A data do fato, a emissão do evento e o recebimento pela administração tributária têm funções diferentes. Para a 821, a comparação é com dhEvento. A data de emissão da própria NF-e participa de outras validações. Já a data de geração do hash pertence a outro campo e pode provocar a rejeição 822, mesmo que a data da entrega esteja correta.

Verifique também o fuso informado junto às datas. Comparar somente os números do relógio, ignorando o deslocamento de fuso, pode produzir um diagnóstico errado. O suporte deve conferir a conversão feita pelo sistema e preservar o instante real, sem trocar o fuso apenas para que a comparação pareça favorável.

Exemplo de conferência

Considere um comprovante cuja entrega realmente terminou em 16/10/2026, às 14h20, no fuso de Brasília. Por uma falha no processo de geração, o XML levou dhEvento correspondente às 14h05 do mesmo dia e fuso. O arquivo declara uma entrega quinze minutos posterior à emissão do evento, situação alcançada pela 821.

Se a evidência da entrega confirma 14h20, não se deve reduzir esse horário para 14h05. É necessário descobrir por que a mensagem foi emitida com um instante anterior e gerar corretamente o evento que será transmitido. Se, ao contrário, houve erro de digitação na data da entrega, a correção deve refletir o registro verdadeiro. O exemplo apenas demonstra a comparação; não comprova que um novo envio será aceito.

Para o insucesso, o raciocínio é semelhante, mas a informação corresponde à tentativa de entrega. Uma previsão de chegada não deve ocupar o campo reservado à ocorrência. Se o fato ainda não ocorreu, não há base para registrá-lo antecipadamente como entrega concluída ou tentativa frustrada.

Corrija a origem do erro

Revise os registros da operação e a origem dos horários: lançamento manual, aplicativo de entrega, integração ou geração do XML. Confira se houve inversão de dia e mês, conversão de fuso, relógio incorreto ou reaproveitamento indevido de uma mensagem antiga. São hipóteses de investigação, não causas comprovadas somente pelo código recebido.

Ajuste o dado incorreto na origem e gere novamente a mensagem pelo fluxo adequado do emissor, com sua assinatura. Preserve a tentativa rejeitada e o retorno para acompanhamento. Não edite diretamente um XML assinado nem altere o XML já autorizado da NF-e para tentar eliminar uma rejeição pertencente ao evento.

Também não transfira para a 821 a tolerância de cinco minutos prevista em regras próximas. A P13-10 compara a emissão do evento com o processamento; a 2P13-14 trata da autorização da NF-e em determinada condição. A P30-10 não apresenta essa tolerância. A decisão deve seguir a regra correspondente aos campos realmente envolvidos.

No ALRA, encaminhe ao suporte a operação pretendida, os horários reais e os arquivos de envio e retorno. O nome das telas depende da implementação disponível; instruções de outros emissores não demonstram a existência de uma função equivalente no sistema utilizado.

Confirme serviço, ambiente e resultado

As especificações consultadas distinguem os destinos: o comprovante é descrito no serviço de eventos do Ambiente Nacional, enquanto o insucesso utiliza o serviço da SVRS. Produção e homologação também precisam corresponder ao ambiente informado. Não se deve trocar o serviço ou a UF por conveniência para contornar a rejeição.

A NT 2021.001 v1.01 corrigiu a documentação dos formatos de data, sem estabelecer uma nova implantação para essa correção. A NT 2023.005 v1.02 mudou o ambiente de autorização do insucesso para a SVRS e indicou 29/04/2024 para testes e 24/06/2024 para produção. Essas referências técnicas não comprovam, isoladamente, a configuração de um emissor ou o funcionamento de um envio concreto.

Após a correção, leia o resultado individual do evento. O código 128 informa processamento do lote, não aprovação de cada ocorrência. O retorno 135 identifica evento registrado e vinculado à NF-e; qualquer outro resultado deve ser interpretado conforme sua mensagem. Guarde o protocolo efetivamente recebido e confirme sua associação à chave, ao tipo, à sequência e ao ambiente corretos.

Se a 821 persistir com horários aparentemente coerentes, forneça ao suporte os valores completos, incluindo fuso, e os registros que comprovam o fato. Repetir o envio sem investigar a divergência, reutilizar a numeração da NF-e ou cancelar documentos não constitui uma solução para esse problema.

Fontes

• NT 2021.001 v1.01 — Comprovante de Entrega da NF-e, páginas 3–10 e 14.

• NT 2023.005 v1.02 — Insucesso na Entrega da NF-e, páginas 3–11 e 16.

• Omie — Rejeição 821, guia específico do comprovante.

• FlexDocs — Insucesso na Entrega, documentação técnica de produto com a regra 821.

• InvoiSys — Evento Comprovante de Entrega, contexto histórico de 2021, confrontado com a especificação atual.

Pesquisa documental em 16/10/2026. Os apoios têm profundidades diferentes e não substituem as especificações oficiais. Não houve transmissão fiscal nem teste do ambiente do leitor.