Rejeição 724: NF-e sem o nome do destinatário

Por que o nome é exigido na NF-e

A Rejeição 724, regra E04-10, indica que a NF-e modelo 55 não contém o nome do destinatário em dest/xNome. O leiaute descreve o campo como razão social ou nome do destinatário e o torna obrigatório para esse modelo. Embora xNome tenha ocorrência estrutural 0-1 no schema compartilhado com a NFC-e, essa opcionalidade não elimina a exigência da regra de autorização da NF-e.

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

Nome do cadastro e nome no arquivo

Localize NFe/infNFe/dest/xNome no XML da tentativa e compare-o ao nome comprovado do participante. emit/xNome identifica o emitente e não atende a essa exigência. O mesmo vale para nomes de transportador, local de entrega ou textos em informações complementares. Se o cadastro possui nome, mas dest não contém xNome, confira o objeto usado na geração e as condições que omitem campos. Se o cadastro está incompleto, confirme o nome a partir do documento do participante; a existência de um CPF ou CNPJ isolado não preenche automaticamente esse campo.

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

Ausência, vazio e conteúdo em homologação

O campo tem tamanho de 2 a 60 caracteres no leiaute; um elemento vazio ou somente com conteúdo que não atende ao tipo pode falhar na validação estrutural, antes de uma rejeição fiscal específica. Em homologação, ide/tpAmb=2, existe ainda a E04-20, código 598, que exige em xNome a literal NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL. A 724 trata da falta do nome no modelo 55; a 598 trata do conteúdo em ambiente de teste. Não substitua permanentemente o nome cadastral verdadeiro por essa literal.

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

Exemplo de omissão causada por um mapeamento

Considere uma NF-e cujo cadastro do destinatário guarda nome e identificador corretos. A integração envia somente o identificador, supondo que a autorização completará o nome. O XML chega sem xNome e se enquadra na E04-10. Corrija a origem do payload ou a geração que deixou de obter o nome do cadastro; não invente uma razão social genérica. Se o nome foi transferido para emit/xNome por erro, a comparação entre os dois grupos revela uma mistura de participantes que também precisa ser corrigida.

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 concluir a conferência técnica

Guarde retorno e XML da tentativa, confirme modelo e ambiente e verifique se o nome esperado aparece no lugar certo após a nova geração. Respeite o conteúdo próprio da homologação sem trocar o ambiente para contornar a mensagem. A presença do nome elimina apenas a condição examinada; não garante autorização ou regularidade cadastral. Preserve documentos assinados e autorizados e consulte qualquer tentativa cujo resultado ainda esteja incerto antes de outro envio.

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

O DANFE Simplificado Tipo 2 muda esta exigência?

A NT 2026.002 v1.11 amplia expressamente E01-20 para a NF-e 55 com DANFE Simplificado Tipo 2, tpImp=6, mas não apresenta alteração de E04-10, E04-20, E05-10 ou E05-20 nem dispensa nome ou endereço da NF-e 55. A ocorrência opcional no schema compartilhado com NFC-e não basta para concluir que um campo passou a ser dispensado pela regra fiscal. O cronograma geral de atualização do DANFE Simplificado Tipo 2 registra produção em 03/08/2026; ele não fixa uma data individual para mudar as regras de nome ou endereço, que não aparecem alteradas no documento. Confirme modelo, tpImp, ambiente e retorno da tentativa para aplicar a regra efetivamente envolvida.

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

Limite dos exemplos e da conferência

O nome verdadeiro é dado cadastral protegido e sua relação com o identificador é essencial. O diagnóstico textual evita inventar participantes e um fragmento incompleto de dest. Nenhum exemplo desta página é um documento pronto para transmissão.