Rejeição 750: identifique o destinatário da NFC-e acima do limite da UF

Sua venda ficou parada com o código 750? Confira se o CPF, CNPJ ou identificador de estrangeiro do comprador foi realmente enviado na NFC-e. A rejeição trata da falta dessa identificação quando o total ultrapassa o limite aplicável. Ter o cliente cadastrado na loja não garante que seus dados chegaram ao arquivo transmitido.

A primeira providência é guardar a resposta completa e conferir o documento rejeitado. Depois, corrija a identificação verdadeira do destinatário e a geração do XML. Não reduza artificialmente o valor da venda, não divida a operação para fugir do limite e não use o documento de outra pessoa.

O que a mensagem significa

No MOC 7.0, página 122, a W16-40 registra a mensagem “Rejeição: NFC-e com valor total superior ao permitido para destinatário não identificado (Código) [Limite]”. “Código” significa a identificação fiscal do destinatário, não o número interno do cliente. [1]

A conferência visual da página 19 da NT 2026.002 v1.11 resolve uma diferença importante: o modelo 55 e a expressão sobre NF-e com DANFE Simplificado Tipo 2 estão riscados na W16-40. A extração de texto preserva essas palavras, mas perde o sentido da exclusão. A regra 750 aqui se refere à NFC-e 65, com total superior ao limite aplicável e falta de identificação. Não estenda essa linha à NF-e 55 apenas pelo texto extraído. [2]

No XML, os campos são dest/CNPJ, dest/CPF e dest/idEstrangeiro. A regra impressa abrevia o último como dest/idEstrang, mas o leiaute e o esquema usam idEstrangeiro. Essa abreviação não é o nome de uma tag a criar. Informar somente xNome não supre o identificador. Nome e endereço possuem validações próprias, 751 e 752.

O contexto é autorização NFeAutorizacao, leiaute 4.00. Número igual em outro serviço ou documento exige sua documentação própria.

Qual limite deve ser usado

A página 3 da NT descreve limite definido pela UF para NFC-e sem identificação e, na ausência de definição, referência de R$ 10.000,00. Isso não comprova o limite efetivo de qualquer estabelecimento. Confira orientação oficial da UF e parâmetro do autorizador; não foi demonstrada aqui uma tabela estadual atual. [2]

O cronograma dessa alteração da W16-40 indica testes em 01/06/2026 e produção em 15/06/2026. 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 750. [2]

O índice SVRS consultado em 15/10/2026 apresenta a v1.11 e ressalva possível alteração das datas. A consulta e a leitura dos cronogramas não certificam implantação individual ou limite estadual efetivo. Registre UF, autorizador e tpAmb, separando homologação e produção. [3]

Diagnóstico antes de retransmitir

Reúna o XML efetivamente enviado, o retorno da SEFAZ, o horário, a chave, o modelo, o ambiente e a UF do estabelecimento. No XML, compare o total em total/ICMSTot/vNF com a identificação dentro de dest. Faça a leitura do arquivo rejeitado, não apenas de um cadastro atualizado depois do envio.

Verifique também qual cliente foi vinculado à venda. Uma seleção “consumidor não identificado” pode produzir XML sem documento mesmo quando o cadastro completo existe. Em integrações, procure o campo usado para CPF/CNPJ e a transformação que monta o grupo do destinatário. O identificador interno do sistema não substitui os campos fiscais.

Se o retorno envolver NF-e 55 com tpImp=6, confirme arquivo, mensagem, serviço e versão com o suporte e o autorizador. A extensão está riscada na W16-40 consultada, e a NF-e possui outras exigências de identificação. Isso não autoriza emitir NF-e sem destinatário.

Como corrigir em cada cenário

O comprador não foi vinculado à nota. Confirme quem adquiriu os produtos, obtenha os dados necessários para documentar a operação e selecione o cadastro correto no documento rejeitado. Confira a relação entre pessoa física, pessoa jurídica ou estrangeiro e o identificador pertinente. Não escolha uma categoria só porque há um campo disponível.

O cadastro contém o documento, mas o XML não. Compare o cadastro, a venda e o arquivo enviado. Uma nota preparada antes da atualização pode conservar dados antigos. Atualize seus dados pelo fluxo do emissor, gere novamente o XML e confira se o identificador verdadeiro passou a constar. O suporte deve corrigir o mapeamento quando a falha vier da integração.

O total foi preenchido incorretamente. Concilie produtos, quantidades, preços, descontos e demais componentes reais da operação. Corrija apenas o erro demonstrado e refaça a totalização. Se o total estiver certo e exceder o limite aplicável, preserve-o e identifique o comprador; a rejeição não autoriza desconto fictício ou fracionamento da venda.

O XML já contém identificação. Confira se esse é o mesmo arquivo e ambiente do retorno 750. Verifique a localização do campo, possíveis perdas na serialização e a resposta integral. CPF/CNPJ inválido pode provocar outra rejeição; não conclua que um documento correto na tela resolveu a ausência no envio. Se tudo coincidir, encaminhe evidências ao suporte e ao autorizador.

Exemplo original

Uma loja fictícia de equipamentos vende um conjunto de ferramentas por R$ 13.450. Neste exemplo, a UF utiliza o limite de R$ 10 mil para a W16-40. O pedido está associado ao cadastro do comprador, mas uma integração usa a opção “consumidor não identificado” ao gerar a NFC-e. O XML fica sem CPF, CNPJ ou identificador de estrangeiro e recebe 750.

A conferência localiza a diferença entre pedido e XML. A equipe corrige o vínculo, preserva o valor real e gera um novo arquivo com a identificação do adquirente. Também ajusta a integração para futuras vendas. Os valores e a configuração da UF pertencem apenas a esse exemplo; não estabelecem limite nacional para todo caso.

Como confirmar a solução e quando escalar

Depois da correção, retransmita pelo fluxo controlado do emissor e leia o novo retorno. O desaparecimento do 750 pode dar lugar a outra validação; ele não comprova autorização. Confira o resultado fiscal correspondente à chave, o protocolo quando autorizado e o XML preservado com a identificação correta.

Acione o suporte quando o cadastro e o XML divergirem ou quando houver dúvida sobre o parâmetro estadual. Procure o responsável fiscal se o comprador não puder ser identificado, se o modelo documental estiver em dúvida ou se houver necessidade de regularizar uma operação já realizada. Não há promessa de autorização: a correção precisa refletir os fatos e atender às demais regras aplicáveis.

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 de teste ou certificação individual de implantação por UF/ambiente.

1. MOC 7.0, Anexo I, páginas 14 e 122, identificação e W16-40 histórica. Pacote de esquemas 010f, declaração inteira de dest: nome exato idEstrangeiro. Estrutura não prova identificação fiscal suficiente.

2. NT 2026.002 v1.11, páginas 3 e 19; PNG existente da página 19 inspecionado, riscos de 55/Tipo 2 conferidos. Limite parametrizável e cronogramas documentais, sem tabela estadual atual demonstrada.

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

Apoios: Oobj, TOTVS Moda, TecnoSpeed. Oobj foi lido por captura HTTP 200; TOTVS e TecnoSpeed pela ferramenta WEB, distintas dos HTTP 403 diretos. Seus menus não pertencem ao ALRA. Endereço, nome e limites estaduais citados nesses guias exigem condições próprias; nenhum valor estadual antigo foi certificado como atual. Os exemplos não foram validados como XML completo.

Históricos preservados, sem autenticar retroativamente atos antigos. Revisão cruzada independente pendente; publicação não realizada.