Rejeição 598 na NF-e e NFC-e: nome do destinatário em homologação

A rejeição 598 acontece quando o nome do destinatário de uma NF-e ou NFC-e de teste não atende ao texto exigido para o ambiente de homologação. A primeira providência é confirmar se a emissão realmente deveria ser um teste. Se sim, confira o campo dest/xNome e a exceção da Nota Fiscal Fácil. Se a intenção era emitir uma nota real, investigue a configuração de ambiente antes de substituir dados do cliente.

O cuidado evita uma correção perigosa: colocar informação de teste no cadastro usado pelas vendas reais ou mudar o sistema para produção apenas para a mensagem desaparecer. A solução deve respeitar a finalidade da emissão e manter os ambientes separados.

Qual texto deve aparecer no XML

A regra E04-20 do MOC 7.0, página 83 tem aplicação obrigatória e escopo de modelos 55 e 65. Quando ide/tpAmb=2, o nome ou razão social do destinatário deve usar este literal, observada a exceção de NFF:

NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL

O texto acima deve ser reproduzido sem aspas, sem ponto final e sem acrescentar o nome do cliente. HOMOLOGACAO aparece sem acento e sem cedilha. Há um hífen comum entre HOMOLOGACAO e SEM, com um espaço de cada lado. A troca por travessão, a alteração das palavras ou a inclusão de caracteres invisíveis pode impedir a correspondência esperada.

O destino é infNFe/dest/xNome, identificado como E04 no leiaute. Existem outros campos chamados xNome no documento. Alterar emit/xNome, que identifica o emitente, ou o nome do local de entrega não corrige o destinatário. O arquivo final precisa ser conferido pelo caminho completo, não apenas pela busca da primeira ocorrência de xNome.

A exceção da Nota Fiscal Fácil

A NT 2021.002 v1.12, página 11 acrescenta uma exceção expressa: a E04-20 não se aplica quando tpEmis=3-NFF.

Essa condição pertence à emissão efetiva pelo regime especial Nota Fiscal Fácil. Não é uma alternativa de configuração para um emissor comum escapar da rejeição. Mudar tpEmis altera a identificação do processo de emissão e se relaciona a outras exigências próprias da NFF.

Também é importante não confundir os números: tpAmb=2 identifica homologação; tpEmis=3 identifica, nesse contexto documental, NFF. O tipo de impressão tpImp é outro campo. Nenhum deles pode ser interpretado isoladamente como uma autorização para usar dados fictícios em produção.

Destinatário e primeiro produto são verificações diferentes

A 598 trata de dest/xNome. A rejeição 373 trata de prod/xProd do primeiro item em homologação e possui outro literal, iniciado por “NOTA FISCAL”. Copiar a frase do produto para o destinatário pode conservar o erro, mesmo que os dois textos pareçam semelhantes.

O MOC apresenta a regra do primeiro produto para NFC-e. A NT 2026.002 v1.11, página 11, também contempla a NF-e modelo 55 com DANFE Simplificado Tipo 2, tpImp=6, na I04-10. Essa ampliação não transforma xProd em xNome e não estende automaticamente a exigência do primeiro produto a toda NF-e modelo 55.

A identificação obrigatória do destinatário é uma questão separada. O leiaute-base distingue NF-e e NFC-e, e há condições específicas da operação que exigem identificação. A 598 não deve ser usada como justificativa para inventar CPF, CNPJ ou destinatário em uma NFC-e na qual a identificação não seja exigida. Quando o nome é informado ou exigido no teste, confira sua representação conforme as regras aplicáveis.

Como fazer a correção com segurança

1. Salve a resposta completa da Sefaz e o XML enviado. Confirme que o código pertence à autorização de NF-e/NFC-e, pois outros documentos podem reutilizar números de rejeição.

2. Confira ide/tpAmb no XML e o ambiente configurado no ERP, no integrador e no endereço do serviço. A tela pode indicar uma escolha enquanto outro componente transmite por configuração diferente.

3. Verifique se a emissão está efetivamente enquadrada na exceção NFF. Se não estiver, compare dest/xNome com o literal oficial, incluindo os caracteres e espaços.

4. Ajuste a origem dos dados no ambiente de teste ou a transformação específica de homologação. Evite substituir definitivamente a razão social verdadeira de um cliente compartilhado com a base de produção.

5. Gere novamente o documento, confira o XML final e deixe o emissor assinar e transmitir pelo fluxo normal. Guarde a nova resposta.

Se houver uma configuração de ambiente inconsistente, o suporte deve corrigir o componente responsável. Alternar para produção durante um teste, apenas para tentar destravar o sistema, cria risco de enviar documento indevido. Procedimentos de reconfiguração de um ERP precisam ser avaliados dentro daquele produto e com controle sobre as filas de envio.

Por que mudar a tela pode não resolver

Uma integração pode guardar uma cópia do destinatário no pedido, no movimento ou no lote já preparado. Nesse caso, corrigir o cadastro e retransmitir o mesmo arquivo não altera dest/xNome. É necessário identificar de onde o XML está obtendo o nome e refazer sua geração.

Outro caso é o sistema acrescentar automaticamente a razão social verdadeira depois do texto de homologação. A intenção de facilitar a identificação interna é compreensível, mas o campo deixa de conter o literal previsto. Use referências internas apropriadas para distinguir os testes, preservando o conteúdo exigido nesse campo.

Se o arquivo conferido está correto e o retorno continua igual, compare-o com o payload realmente transmitido e com o horário da resposta. Evite analisar uma versão nova contra a rejeição de um lote anterior. Essa conferência costuma separar defeitos de geração de problemas de fila ou reprocessamento.

Encerramento do teste e passagem para produção

Superar a 598 confirma apenas que essa validação deixou de impedir o processamento. Uma autorização em homologação continua sem valor fiscal. Para operações reais, a configuração precisa apontar para produção, com dados verdadeiros do destinatário e revisão das demais exigências da emissão.

Inclua a separação dos ambientes na verificação de implantação do ERP: parâmetros, integrações, cadastros e arquivos de exemplo. Não reutilize o literal de teste em notas reais. A inclusão de IBS/CBS não altera automaticamente essa regra de identificação, e este procedimento não abrange NFS-e.

Fontes práticas consultadas: TecnoSpeed, TOTVS Datasul e Alterdata. Foram usadas como apoio de integração e configuração; o literal, o campo E04 e a exceção NFF foram conferidos nas fontes oficiais.

Base documental: MOC 7.0, NT 2021.002 v1.12 e NT 2026.002 v1.11, preservados no recorte de 9 de outubro de 2026 e relidos em 10 de outubro. Datas previstas em notas técnicas não certificam implantação em todos os autorizadores.