Rejeição 541: como revisar o CPF do local de entrega

A rejeição 541, “CPF do Local de Entrega inválido”, indica um problema no CPF informado no grupo de entrega da nota. Para resolver, confira a identificação daquele local no XML rejeitado, confirme o dado correto na documentação da operação e ajuste o cadastro ou pedido que alimentou o emissor.

Este guia trata do retorno de autorização de NF-e/NFC-e. Se o número veio de consulta pública, QR Code, evento ou outro serviço, confirme a mensagem e sua origem antes de aplicar o diagnóstico.

O cuidado principal é localizar o campo certo. Alterar o CPF do comprador, do transportador ou do local de retirada não corrige automaticamente o CPF da entrega. Uma nota pode conter mais de uma identificação, com funções diferentes, e a correção precisa alcançar exatamente a informação apontada pelo retorno.

O que está sendo validado

No MOC 7.0, a regra G02a-10 verifica o CPF do local de entrega: conteúdo zerado, nulo, sequência de um mesmo algarismo ou dígito de controle inválido. O campo tem identificador G02a e está no caminho NFe/infNFe/entrega/CPF. O leiaute prevê 11 algarismos para o CPF. MOC 7.0, páginas 16 e 88.

A regra aparece como facultativa para NF-e, modelo 55, e NFC-e, modelo 65. Isso não torna facultativa a veracidade da informação. A lista publicada pela SEFAZ-SP mostra G02a-10 como ativa. A situação paulista não deve ser estendida automaticamente aos demais autorizadores.

O grupo entrega identifica um local diferente do endereço do destinatário, conforme a orientação do leiaute. Quando houver dúvida sobre quem deve ser identificado ali, confira os documentos e a natureza da operação com a área fiscal. O nome de alguém que apenas recebe fisicamente uma encomenda não deve ser usado, por suposição, para substituir a identificação fiscal daquele local.

Comece pelo pedido e termine a conferência no XML

Guarde a mensagem completa da rejeição, a chave, o modelo, a UF, o ambiente e o horário. Obtenha o XML da mesma transmissão. Essa correspondência evita analisar uma prévia diferente ou uma nota já alterada após o erro.

A ajuda da Omie trata a correção nos dados de entrega do pedido de venda e depois orienta o reenvio. Esse fluxo pertence àquele sistema, mas ilustra uma pergunta útil: o CPF veio do cadastro geral do cliente ou de uma informação específica daquele pedido?

Confira os dois pontos quando necessário. Alguns emissores copiam o endereço e a identificação na criação do pedido. Uma atualização posterior no cadastro pode não substituir automaticamente o conteúdo que já ficou gravado na venda.

No arquivo, localize entrega/CPF. A Dynamicca documenta essa localização no Gestão DF-e, usando a visualização do XML. A comparação deve considerar os algarismos exportados, inclusive zeros à esquerda, além da ausência de pontuação e espaços. Tamanho ou formatação incompatíveis também podem gerar uma falha de estrutura, com outro código de retorno.

Separe o erro de digitação da origem errada

Se o CPF diverge do documento confirmado, ajuste a informação no ponto em que nasceu o erro. Se o cadastro está correto e o XML está diferente, investigue o caminho entre cadastro, pedido e integração.

Um exemplo: a empresa recebe um pedido para entrega em outro endereço, corretamente identificado por pessoa física. O cadastro desse local foi atualizado, mas o pedido manteve uma cópia antiga com um algarismo trocado. Alterar novamente o cadastro sem revisar o pedido repete o envio errado. A solução é atualizar o registro efetivamente utilizado e conferir o novo XML antes da transmissão.

Há situações em que uma planilha ou integração remove um zero inicial, envia pontuação ou preenche campos desconhecidos com zeros. A equipe técnica deve corrigir a transformação e preservar o identificador completo. Não complete o número por tentativa nem recalcule os dígitos finais para criar uma combinação que apenas passe no teste.

CPF e CNPJ precisam representar a pessoa correta

Se foi informado CNPJ no campo destinado a CPF, confirme primeiro a identidade vinculada ao local de entrega. O preenchimento deve usar o campo correspondente à pessoa identificada. Não troque essa pessoa pelo cliente, por um funcionário ou por um familiar para conseguir transmitir a nota.

A documentação do Berga descreve o uso de cadastros para os dados de entrega em seu produto e recomenda cadastrar locais recorrentes. Essa prática ajuda a evitar redigitação, desde que os registros estejam atualizados e o pedido use o endereço correto.

Quando o CPF verdadeiro ainda não foi confirmado, obtenha a informação necessária. Apagar o grupo ou deixar a identificação vazia só porque o preenchimento gera rejeição pode retirar um dado que a operação exige. A revisão da necessidade do grupo deve ser feita com base no endereço real, no modelo e nas regras aplicáveis.

Atenção à regra de presença do grupo

A NT 2026.002 v1.11 apresenta G01-10, ligada à rejeição 670, para local de entrega em NFC-e ou NF-e com DANFE Simplificado Tipo 2, identificado por tpImp igual a 6. Porém, a própria linha traz a observação “Implementação futura”. Essa ressalva impede tratar o cronograma geral do Tipo 2 como prova de ativação dessa linha. Homologação, produção e implantação efetiva pelo autorizador devem ser verificadas separadamente. NT 2026.002 v1.11, página 11.

A rejeição 541 continua exigindo a análise do CPF efetivamente enviado. Não retire o grupo preventivamente com base em uma implantação futura nem altere o tipo de documento para contornar a conferência. Verifique a documentação aplicável à data, ao modelo e ao autorizador da emissão.

Validade formal e reenvio são etapas distintas

Um CPF com dígitos verificadores consistentes não comprova titularidade ou regularidade cadastral. A rejeição 541, por sua vez, não permite concluir que a pessoa esteja fiscalmente irregular. Confirme o número com a documentação adequada; se houver necessidade de consulta cadastral, faça essa verificação separadamente, em canal apropriado.

Após corrigir a origem, gere novamente o XML pelo emissor. Revise entrega/CPF, endereço e a compatibilidade dos demais dados. O sistema deve validar a estrutura e assinar o arquivo corrigido antes da transmissão.

Leia o novo retorno e confirme a autorização e o protocolo. Caso a rejeição permaneça apesar de o conteúdo estar correto, leve ao suporte o XML e o retorno daquela mesma tentativa por canal seguro. Evite publicar CPF ou documentos completos em chamados abertos. Resolver a origem do erro reduz a chance de a próxima entrega repetir o problema.

Referência de atualização: 09/10/2026. Consulta documental e fontes práticas citadas; sem certificação operacional para todos os autorizadores.