NF-e e NFC-e
Rejeição 472: alinhe o CPF consultado ao certificado na distribuição de NF-e
A rejeição 472 ocorre quando o CPF informado no pedido de distribuição é diferente do CPF do certificado digital usado na transmissão. Para resolver, é preciso identificar quem realmente pretende consultar os documentos e conferir se o sistema está usando a identidade correta nas duas pontas.
A rejeição 472 ocorre quando o CPF informado no pedido de distribuição é diferente do CPF do certificado digital usado na transmissão. Para resolver, é preciso identificar quem realmente pretende consultar os documentos e conferir se o sistema está usando a identidade correta nas duas pontas.
Esse retorno pode interromper a entrada de XMLs no sistema e prejudicar a conferência das compras. Entretanto, ele descreve uma falha na consulta de distribuição. Sozinho, não informa que a NF-e do fornecedor foi rejeitada, cancelada ou emitida com erro. Alterar a venda ou emitir outra nota antes de entender o retorno pode criar um problema adicional.
Em qual serviço a 472 aparece
A regra H05 está na página 11 da NT 2014.002 v1.40, do serviço NFeDistribuicaoDFe, método nfeDistDFeInteresse. A página 16 traz a mensagem “Rejeição: CPF consultado difere do CPF do Certificado Digital”.
Nesse serviço do Ambiente Nacional, o pedido pode buscar documentos a partir do último NSU, consultar um NSU específico ou consultar uma chave de acesso. NSU é o número sequencial usado na distribuição. A H05 não possui a restrição de modalidade que aparece em outras linhas da tabela: a comparação de CPF integra a validação do pedido nas três formas.
O contexto é a distribuição de documentos de interesse dos atores da NF-e. A consulta por chave verifica modelo 55. Não se deve transportar este diagnóstico automaticamente para autorização de NFC-e, modelo 65, consulta pública por QR Code ou outro serviço que mostre o mesmo número em uma tela.
Qual CPF precisa coincidir
No XML de consulta, o campo CPF identifica o interessado nos documentos. Ele deve corresponder ao CPF do certificado efetivamente apresentado na conexão. Não basta que o cadastro aberto na tela exiba o nome certo: a rotina automática pode usar uma configuração diferente da consulta manual.
Também não resolve colocar o CPF do funcionário, do desenvolvedor ou de outra pessoa apenas porque existe um certificado disponível. Primeiro defina o interessado legítimo e seu vínculo com os documentos; depois corrija o cadastro ou a seleção do certificado conforme essa identidade.
A comparação de pessoa física usa o CPF completo. A possibilidade de consultar estabelecimentos pelo mesmo CNPJ-base pertence ao ramo de pessoa jurídica, tratado pela H04 e pela rejeição 593. Ela não cria uma espécie de “CPF-base” nem permite substituir o CPF de uma pessoa pelo de um familiar, sócio ou procurador. NT, seções 3 e 3.10.2
Um roteiro de conferência que evita tentativas cegas
Confirme o serviço e a mensagem completa. Peça à equipe responsável o retorno retDistDFeInt, com cStat, xMotivo, ambiente e horário. Uma descrição abreviada no ERP pode esconder a origem.
Localize o pedido realmente enviado. Confira o CPF em distDFeInt, sem se limitar ao cadastro que deveria ter originado o arquivo.
Identifique o certificado usado naquela chamada. A verificação deve ocorrer no processo que executa a integração, inclusive quando há serviço automático ou várias empresas cadastradas.
Compare as identidades em ambiente seguro. Se o CPF do pedido estiver errado, corrija seu mapeamento. Se o pedido estiver correto e o certificado selecionado pertencer a outra pessoa, ajuste a configuração autorizada.
Faça uma nova consulta controlada e guarde seu retorno. Compare o resultado com o pedido anterior antes de religar uma rotina que estava repetindo a falha.
A orientação da TecnoSpeed sobre divergência de CPF e certificado reforça a conferência do cliente e do grupo de empresas selecionado na configuração de DF-e. Os nomes de menus são específicos daquele produto; em outro ERP, procure a função equivalente.
Exemplo de uma configuração trocada
Considere duas pessoas físicas fictícias, A e B, com consultas legitimamente administradas no mesmo sistema. A rotina monta o pedido com o CPF de A, mas seleciona o certificado de B. Ao receber 472, a equipe deve corrigir a associação da consulta de A.
Mudar o pedido para B apenas para eliminar a mensagem passaria a consultar outra identidade. O sistema poderia até deixar de apresentar aquela divergência, mas isso não comprovaria a recuperação dos documentos de A. Por isso, o teste final precisa conferir tanto o retorno quanto o interessado a quem pertencem os documentos.
A documentação de consulta de DF-e da FlexDocs apresenta a seleção do certificado separada do parâmetro que identifica o interessado. É um exemplo útil para investigar integrações: o certificado pode vir de um repositório ou de uma configuração própria do componente. O nome comercial do parâmetro não substitui a conferência do XML transmitido.
Como saber se o problema terminou
A ausência da 472 é apenas a primeira verificação. O novo retorno pode indicar documentos localizados, nenhum documento disponível naquele momento ou outra rejeição. Leia o resultado inteiro e confirme que o sistema processou o que recebeu.
A documentação da Unimake sobre distribuição distingue pedido, resposta principal, documentos extraídos e erro local. Essa separação ajuda a localizar uma falha posterior de importação sem atribuí-la novamente ao certificado.
Preserve o controle de NSU do interessado correto. Trocar o certificado não é motivo para zerar a sequência ou repetir indiscriminadamente consultas antigas. Se houver retorno de consumo indevido, siga o tratamento específico antes de retomar a busca.
Cuidados para o suporte e para a empresa
A 472 é diferente de CPF inválido, ausência de identidade no certificado ou falta de permissão para acessar determinada NF-e. Essas situações têm verificações próprias. Tampouco uma manifestação do destinatário corrige a divergência entre o pedido e o certificado.
No chamado, informe serviço, ambiente, horário, versão do sistema e mensagem recebida. Use identificadores mascarados quando bastarem para explicar o caso. Não envie arquivo de certificado, senha ou chave privada em conversa, e-mail ou captura de tela. A inspeção deve ser feita pelo responsável autorizado, no ambiente seguro da empresa.
Base documental: NT 2014.002 v1.40, publicada em 03/07/2026, cópia oficial preservada em 09/10/2026 e conferida em 10/10/2026. Os três guias práticos foram lidos como apoio de integração; não são três artigos exclusivos sobre a 472. A especificação sustenta o diagnóstico, sem comprovar a execução de uma consulta concreta.