Rejeição 787: falta destinatário na NFC-e ou NF-e Tipo 2

O que a rejeição 787 verifica

A Rejeição 787 ocorre quando falta a identificação do destinatário, grupo infNFe/dest, na NFC-e modelo 65 ou na NF-e modelo 55 com DANFE Simplificado Tipo 2, ide/tpImp=6, em operação não presencial com entrega, ide/indPres=4. Essa é a redação da E01-20 na NT 2026.002 v1.11. A falta do grupo é diferente de CPF inválido ou endereço incorreto. O cronograma geral da atualização para o DANFE Simplificado Tipo 2 registra homologação em 01/07/2026 e produção em 03/08/2026. A lista dessa linha usa o identificador D01-20, enquanto a tabela do grupo E apresenta E01-20; por isso ela não fornece uma correspondência individual inequívoca da data com esta regra. A redação da E01-20 está expressa na página 11, mas cronograma geral não comprova sua implantação individual. A data de 05/10/2026 da estrutura de alertas não deve ser atribuída a esta comparação.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Autorização com alerta e estrutura do protocolo NT 2026.002 v1.11

Onde procurar a informação que ficou de fora

No XML da tentativa rejeitada, localize NFe/infNFe/ide/indPres e, no mesmo infNFe, procure dest. Se o arquivo estiver em um envelope de envio ou em um processo, esses ancestrais aparecem antes de NFe. Todos os elementos fiscais pertencem ao namespace http://www.portalfiscal.inf.br/nfe; uma busca que ignora namespaces pode dizer que um grupo existente está ausente. Dentro de dest, a identificação é representada por uma das alternativas CNPJ, CPF ou idEstrangeiro, conforme o participante real e o leiaute aplicável. O nome de uma pessoa em informações adicionais, no pedido ou no comprovante de entrega não cria esse grupo no XML.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Identificação, nome e endereço não são a mesma conferência

O leiaute permite que dest seja estruturalmente opcional, mas a E01-20 atual exige sua presença na condição descrita. O grupo contém a alternativa de identificação, indIEDest e campos como xNome e enderDest, cada um com exigências próprias. A E05-20, código 788, trata da falta de enderDest na NFC-e de entrega. Na NF-e 55, E04-10 exige nome e E05-10 exige endereço; a NT 2026.002v1.11 não apresenta dispensa dessas regras para tpImp=6. Portanto, não se deve inferir que a adoção do Tipo 2 transforma nome ou endereço em opcionais na autorização da NF-e. A E01-10, código 719, permanece a referência do MOC para NF-e 55 sem dest; leia o retorno exato sem escolher por conta própria qual rejeição terá precedência.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd Autorização com alerta e estrutura do protocolo NT 2026.002 v1.11

Exemplo: comprador existe no pedido, mas não no arquivo

Considere uma entrega real em que o pedido guarda o comprador e seu endereço, enquanto o XML gerado contém indPres=4 e nenhum dest. A condição da 787 está presente mesmo que a tela do pedido exiba os dados. Compare o vínculo do pedido com o cadastro selecionado e o objeto enviado à geração fiscal. Se a integração envia o comprador, mas o serializador omite dest, a correção é no mapeamento do emissor. Se o pedido não aponta o destinatário correto, primeiro é necessário identificar o participante com os documentos da operação. Preencher um identificador fictício ou mudar indPres para aparentar atendimento presencial não corrige a causa.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Como verificar a correção com segurança

Preserve o XML rejeitado e o retorno individual com cStat e xMotivo, conferindo empresa, ambiente e tentativa. Compare os dados reais do comprador com o cadastro e com o XML antes de uma nova transmissão autorizada. A evidência técnica da correção é a presença do grupo dest correto, a identificação coerente e o endereço exigido para a entrega; o desaparecimento da mensagem 787, isoladamente, não comprova autorização. Se houve timeout ou retorno incerto em outra tentativa, esclareça a situação dessa tentativa antes de repetir o envio. Não edite um XML assinado ou uma nota já autorizada para fazer essa conferência.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Limite dos exemplos e da conferência

A ausência de dest precisa ser comparada no XML original da tentativa e no cadastro protegido do comprador. Um fragmento sem identificação não representaria o grupo completo; os cenários textuais evitam fabricar CPF, CNPJ ou documento estrangeiro. Nenhum exemplo desta página é um documento pronto para transmissão.