Rejeição 752: confira o endereço que saiu no XML da nota

O comprador informou CPF e nome, a venda está pronta, mas a emissão retorna 752. Nesse cenário, vale conferir se o endereço do destinatário chegou ao arquivo fiscal. Um cadastro completo na tela não garante que a nota recebeu o mesmo conteúdo. A omissão pode estar no vínculo da venda, numa nota preparada antes da atualização ou na integração.

Guarde o XML enviado e a resposta completa antes de corrigir. Use os dados verdadeiros do adquirente e preserve o valor real da operação. Não preencha endereço de outra pessoa nem reduza artificialmente o total para tentar obter autorização.

O que o código verifica

No MOC 7.0, de novembro de 2020, a W16-60 registra, para NFC-e modelo 65, a mensagem histórica: “Rejeição: NFC-e com valor total superior ao permitido para destinatário não identificado (Endereço) [Limite]”. A regra está na autorização de NF-e/NFC-e, página 122, e relaciona total superior a R$ 10.000,00 com ausência de dest/enderDest. [1]

O 752 trata do endereço. O 751 trata do nome, dest/xNome, e o 750 do identificador, como CPF ou CNPJ. Esses retornos não são intercambiáveis. Informar CPF e nome não cria o grupo do endereço; escrever o endereço em observações da venda também não demonstra sua presença no lugar esperado do XML. [2]

Este diagnóstico verifica a ausência de enderDest, sem substituir a validação dos componentes do endereço. Se o grupo estiver presente, preserve essa evidência e confira a correspondência entre arquivo e retorno antes de modificar os dados.

Modelos e aplicação pela UF

A página 19 da NT 2026.002 v1.11 foi conferida visualmente nesta pesquisa. Na W16-60, o modelo 55 e a expressão sobre NF-e com DANFE Simplificado Tipo 2 estão riscados. O contexto remanescente é NFC-e modelo 65. A extração de texto conserva as palavras excluídas e não deve ser tomada como prova de extensão ao Tipo 2. [2]

Este roteiro trata de autorização NFeAutorizacao, leiaute 4.00. A NF-e tem outras exigências de endereço; não use o risco desta linha para emitir modelo 55 sem os dados devidos. Se uma NF-e receber esse retorno, confira mensagem, serviço, arquivo e versão com o suporte e o autorizador.

Há outro cuidado: os corpos consultados da W16-60 trazem “Obrig.” na coluna de aplicação e, ao mesmo tempo, uma observação expressa de regra opcional a critério da UF. Preserve ambas as informações. Elas não comprovam adoção uniforme nem dispensam a conferência da UF e do autorizador do caso. [1][2]

Valor e datas documentais

A condição escrita da W16-60 usa total superior a R$ 10 mil. Igualar essa referência não é o mesmo que superá-la. A previsão de limite definido pela UF na W16-40, código 750, não deve ser automaticamente emprestada à W16-60. Confira a regra realmente aplicada no retorno; nenhum limite estadual efetivo foi certificado aqui. [2]

O cronograma da v1.10 enumera ajustes das 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 752, já descrito no MOC histórico. [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 não certificam adoção ou implantação individual. Identifique UF, autorizador e tpAmb, separando homologação de produção. [3]

Diagnóstico do arquivo rejeitado

Localize a tentativa pelo horário, chave e resposta. Abra o XML efetivamente enviado, confira modelo e ambiente e procure enderDest dentro de dest. Compare o total em total/ICMSTot/vNF e o cadastro que estava vinculado à nota naquele momento. O DANFE ou uma ficha corrigida depois não substituem esse arquivo.

Em seguida, rastreie a informação entre cadastro, venda e geração fiscal. Uma integração pode receber o endereço e descartá-lo na transformação. Uma fila pode reenviar uma versão antiga. Confira o arquivo produzido depois da correção, incluindo os procedimentos de assinatura do emissor; editar manualmente um XML assinado não demonstra uma transmissão válida.

Quatro situações de correção

O endereço não foi cadastrado. Confirme os dados do adquirente e preencha o endereço verdadeiro, conforme o leiaute e a orientação fiscal aplicáveis. Atualize a nota rejeitada e gere novamente seu XML. Não use o endereço da loja para preencher a falta do destinatário.

O cadastro está completo, mas a nota usa dados antigos. Confira o vínculo do cliente com a venda e quando a nota foi preparada. Atualize os dados pelo fluxo do emissor. Compare o novo arquivo com o rejeitado para demonstrar que o grupo passou a ser enviado.

A integração omitiu o grupo. Peça ao suporte para comparar o conteúdo recebido com o XML final. Corrija o mapeamento que perdeu o endereço. Validar somente a tela ou o cadastro de origem não comprova que dest/enderDest chegou à transmissão.

O grupo já existe no arquivo. Confirme que arquivo, chave e ambiente correspondem ao mesmo retorno. Verifique se houve reenvio de outra versão ou mensagem interna do emissor. Se tudo coincidir, preserve os registros e encaminhe a divergência ao suporte e ao autorizador, sem inventar campos ou alterar a identidade da operação.

Exemplo de conferência

Uma loja fictícia de ferramentas prepara uma NFC-e de R$ 12.640. Neste exemplo, a UF aplica a W16-60 na condição documental acima de R$ 10 mil. CPF e nome foram enviados, mas o cadastro atualizado não foi incorporado à nota já preparada; enderDest ficou ausente e o retorno foi 752.

A equipe confirma o endereço real, atualiza a nota pelo emissor e verifica o novo XML. Mantém produtos, preço e adquirente. Depois da transmissão, lê a resposta completa: outra validação pode aparecer. O exemplo não fixa regra estadual, não demonstra implantação real e não promete autorização.

Verificação e encaminhamento

Confira o endereço correto no novo XML e o resultado fiscal correspondente à chave. Havendo autorização, preserve XML e protocolo. Uma tela sem o aviso 752 não comprova esse resultado. Se uma tentativa ficou sem resposta, consulte sua situação antes de criar outra nota para a operação.

Acione o suporte quando o endereço desaparecer ou o arquivo divergir do retorno. Procure o responsável fiscal para confirmar dados, adoção estadual e documento adequado. Leve ao autorizador as evidências conferidas quando o comportamento continuar incompatível com o contexto documentado, protegendo os dados pessoais do comprador.

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 e tipo TEndereco. 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-60. 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, coluna Obrig. e observação opcional coexistentes na W16-60, sem presumir adoção uniforme.

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

Apoios específicos: Oobj, Webmania, TecnoSpeed. Oobj e Webmania obtidos por HTTP 200; TecnoSpeed lido pela ferramenta WEB, distinta do HTTP 403 direto. O rótulo “sem tomador” e os parâmetros da API pertencem ao fornecedor; não significam que toda falta de endereço equivale a ausência total de destinatário. Limites variáveis citados em apoios não substituem a condição escrita da W16-60 nem confirmam regra estadual atual. Exemplos externos não foram validados como XML completo.

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