Rejeição 751: o CPF está na NFC-e, mas o nome do comprador não foi enviado

Receber o código 751 mesmo depois de informar o CPF pode parecer contraditório. A explicação é que documento e nome são informações diferentes na NFC-e. Essa rejeição indica a falta do nome do destinatário no cenário de valor previsto pela regra aplicável. A solução começa conferindo o que saiu no XML, não apenas o que aparece na ficha do cliente.

Preserve a venda, o arquivo transmitido e a resposta completa. Depois, identifique a origem da omissão: cadastro incompleto, vínculo errado ou geração do documento. Preencha o nome correspondente ao comprador real e atualize a nota rejeitada pelo fluxo do emissor. Uma alteração no cadastro, sozinha, pode deixar o XML antigo intacto.

Mensagem e alcance da regra

No MOC 7.0, de novembro de 2020, a W16-50 registra a mensagem histórica “Rejeição: NFC-e com valor total superior ao permitido para destinatário não identificado (Nome) [Limite]”. Esse contexto é da autorização da NFC-e, modelo 65, na página 122: total superior a R$ 10.000,00 e dest/xNome ausente, com aplicação opcional a critério da UF. [1]

Esse é o nome enviado no grupo fiscal do destinatário. Um apelido interno, o nome do vendedor ou a descrição “cliente balcão” não substituem a identificação verdadeira quando ela deve constar. Também não basta que dest/CPF ou dest/CNPJ esteja preenchido: esses campos atendem a outra parte do cadastro.

A página 19 da NT 2026.002 v1.11 foi conferida visualmente nesta pesquisa. Na W16-50, o modelo 55 e a expressão sobre NF-e com DANFE Simplificado Tipo 2 estão riscados. A regra remanescente refere-se à NFC-e 65 e mantém a coluna “Facult.” e a observação de aplicação opcional a critério da UF. A extração de texto perde o sentido desses riscos; não fundamenta ampliar o 751 para NF-e Tipo 2. [2]

Este roteiro trata de autorização NFeAutorizacao, leiaute 4.00. A NF-e possui outras exigências para o nome do destinatário; a exclusão desse modelo nesta linha não é dispensa de identificação.

Valor, UF e calendário: o que não confundir

Os registros consultados da W16-50 trazem R$ 10 mil na condição, aplicação facultativa e observação opcional pela UF. Isso não comprova adoção ou limite efetivo em nenhum estado/ambiente. Confirme a orientação da UF competente; ausência de rejeição não demonstra dispensa de uma obrigação de identificação. [1][2]

A página 3 da NT descreve limite definido pela UF para a W16-40, código 750. Esse parâmetro não é automaticamente o da W16-50. Retorno por falta de documento e retorno por falta de nome exigem a condição e o campo correspondentes; não são verificações intercambiáveis. [2]

No cronograma da NT, os ajustes da v1.10 enumeram W16-40, W16-50 e W16-60, com testes em 01/09/2026 e produção em 05/10/2026. A v1.11 altera para 14/12/2026 somente I08-180, BA02-35 e VC02-40. Esse prazo não se transfere ao 751, já descrito no MOC de 2020. [1][2]

O índice SVRS consultado em 15/10/2026 apresenta a v1.11 e ressalva possível alteração das datas. Disponibilidade e cronograma documentais não certificam adoção ou implantação individual. Identifique UF, autorizador e tpAmb, separando homologação e produção. [3]

Onde procurar a informação perdida

Comece pela chave e pelo arquivo correspondentes à tentativa rejeitada. Dentro de dest, procure xNome e compare com o cadastro vinculado à nota. Confira também modelo, UF, ambiente e total total/ICMSTot/vNF. Identifique quando o documento foi preparado e o cliente atualizado. Se uma NF-e 55 receber esse retorno, confira serviço, arquivo, versão e mensagem com o suporte e o autorizador: a referência ao modelo 55 está riscada na W16-50 consultada.

Essa sequência resolve uma dúvida frequente: o operador corrigiu o nome na ficha, mas continua transmitindo uma nota que guardou o conteúdo anterior. Em sistemas integrados, verifique o campo usado na origem: “nome”, “razão social” ou outra informação pode ter mapeamento próprio. O suporte deve demonstrar qual valor chegou ao XML, sem pedir que a equipe fiscal altere a identidade da operação.

Correção por cenário

O cadastro está sem nome. Confirme os dados do adquirente e complete a informação verdadeira. Para pessoa jurídica, verifique a identificação correspondente ao CNPJ informado; para pessoa física, confira o nome do titular. Atualize a nota rejeitada e inspecione o arquivo regenerado. Não use dados do funcionário ou do proprietário da loja para preencher a lacuna.

O nome existe, mas a nota usa outro cadastro. Revise o vínculo do cliente com a venda. Uma operação feita inicialmente como consumidor não identificado pode manter um cadastro genérico mesmo após o preenchimento do CPF. Corrija o vínculo e verifique a coerência entre documento e nome. Apenas mudar a etiqueta exibida na tela não comprova a atualização fiscal.

A integração deixou xNome de fora. Compare os dados recebidos pela integração com o XML transmitido. Identifique a transformação que descartou a informação e corrija seu mapeamento. Gere novamente o documento pelo emissor, incluindo os procedimentos de assinatura necessários quando o conteúdo mudar. Não edite um XML assinado manualmente e o trate como arquivo válido.

O nome está presente no XML rejeitado. Preserve essa evidência e confira se o retorno pertence ao mesmo arquivo, chave e ambiente. Um log antigo ou uma fila que reenviou outra versão pode explicar a divergência. Se os dados realmente coincidirem, peça análise do fornecedor e do autorizador, incluindo a regra estadual utilizada. Não acrescente palavras arbitrárias ao nome para tentar superar o erro.

Exemplo original

Uma loja de móveis prepara uma NFC-e de R$ 14.280. Neste cenário hipotético, a UF aplica a W16-50 para total superior a R$ 10 mil. O cliente está identificado por CPF, mas a integração importou somente esse campo e deixou xNome ausente. A autorização retorna 751.

A comparação entre cadastro e XML confirma a omissão. A equipe inclui o nome verdadeiro no mapeamento, atualiza a nota e preserva os produtos e o valor negociado. Não cria uma venda menor para evitar o limite. Depois, verifica o novo retorno: outra rejeição pode aparecer, pois o preenchimento do nome não comprova conformidade com todas as validações.

Verificação final e encaminhamento

Confirme que o novo XML contém o nome correto dentro de dest, associado à identificação do comprador. Examine o resultado da transmissão e, se houver autorização, preserve o XML e o protocolo correspondentes à chave. Uma tela sem a mensagem 751 não substitui essa conferência.

Acione o suporte quando a informação desaparecer entre cadastro, venda e XML ou quando houver resposta incompatível com o arquivo enviado. Procure o responsável fiscal para dúvidas sobre a obrigação estadual de identificar o consumidor, o documento apropriado ou a regularização de uma operação. Em homologação, siga as informações de teste exigidas pelo leiaute aplicável; não transforme exemplos técnicos em dados de produção.

Fontes e limites

Pesquisa textual em 15/10/2026, horário de Brasília. Capturas oficiais desse dia reutilizadas por hash e três corpos práticos específicos confrontados. Sem acesso ao ALRA, emissão fiscal de teste, limite estadual efetivo ou certificação individual de implantação.

1. MOC 7.0, Anexo I, páginas 14 e 122: identificação e regra histórica. Pacote de esquemas 010f do Portal NF-e, declaração de dest. A estrutura XML não determina sozinha a aplicação fiscal.

2. NT 2026.002 v1.11, páginas 3 e 19, cronograma e W16-50. PNG existente da página 19 examinado nesta sessão na pesquisa750 e reutilizado aqui: referências a 55/Tipo 2 riscadas nas três W16, Facult. e observação opcional na W16-50.

3. Índice SVRS, captura de 15/10, disponibilidade e ressalva sobre datas.

Apoios específicos: Oobj, Dynamicca, TecnoSpeed. Oobj e Dynamicca obtidos por HTTP 200; TecnoSpeed lido pela ferramenta WEB, distinta do HTTP 403 direto. O caminho abreviado do total no guia Dynamicca não substitui total/ICMSTot/vNF. As instruções do Gestão DF-e e os formatos TecnoSpeed não pertencem ao ALRA. Condições de outras rejeições e exemplos de homologação não viraram receita de produção.

Históricos preservados; as leituras atuais não autenticam atos antigos. Revisão cruzada independente pendente; publicação não realizada.