Rejeição 588: ajuste a formatação da mensagem XML com segurança

A rejeição 588 indica a presença de caracteres de edição no início, no fim ou entre as tags da mensagem enviada. É uma falha de preparação ou transmissão do XML que pode aparecer na autorização de uma nota, em um evento ou em outro serviço. Antes de mexer em cadastros e tributos, identifique qual solicitação recebeu a resposta.

Se o erro surgiu ao registrar um evento, isso não significa que a NF-e anteriormente autorizada perdeu sua validade. Da mesma forma, uma consulta rejeitada não comprova que a nota procurada inexiste. O efeito deve ser analisado na operação que realmente falhou.

O que a regra verifica

O MOC 7.0, Anexo I, página 72, apresenta D01e no grupo de validação da área de dados. A aplicação é facultativa. Isso permite variação de implementação pelo autorizador; não significa que o emissor deva preparar mensagens fora do padrão.

O MOC, Visão Geral, página 51, orienta a geração do XML sem caracteres de formatação, como quebras de linha, retornos de carro, tabulações e espaços entre tags. Também diferencia essa formatação do conteúdo dos campos e do tratamento de caracteres especiais do XML.

Por exemplo, o espaço que separa as palavras de uma descrição comercial não deve ser apagado indiscriminadamente. Um “&” pertencente à razão social precisa do tratamento XML previsto, sem que a empresa seja renomeada. Remover todos os espaços e caracteres especiais do arquivo pode corromper dados válidos e produzir outro problema.

A aparência do arquivo pode enganar

Um visualizador costuma organizar o XML em linhas e recuos para facilitar a leitura. Essa apresentação não prova que esses mesmos caracteres foram transmitidos. Também pode ocorrer o inverso: o arquivo salvo está correto, mas uma integração o reformata antes de enviar.

Por isso, a comparação precisa alcançar a mensagem efetiva de saída e a resposta do serviço. O suporte deve verificar em qual etapa surgiram os caracteres: geração, assinatura, montagem do lote, biblioteca de comunicação ou transformação intermediária. Uma captura de tela isolada raramente permite localizar essa etapa.

A Dynamicca orienta a localizar o XML nas consultas do seu produto. Esse é um ponto de partida para obter evidência, mas uma cópia exibida de forma organizada precisa ser distinguida dos bytes enviados. A TecnoSpeed aponta os caracteres de formatação previstos no padrão; a correção exige preservar o conteúdo fiscal e as estruturas assinadas.

Onde o código pode aparecer

O grupo geral do MOC atende às mensagens dos serviços conforme suas remissões, incluindo autorização, retorno, inutilização, consulta de situação, status, cadastro e eventos, como cancelamento e Carta de Correção. Para NF-e/NFC-e, confirme o modelo e a operação oferecida em cada serviço; uma regra comum de XML não torna todos os eventos disponíveis para ambos os modelos.

As notas técnicas consultadas também documentam 588 nos seguintes contratos:

• EPEC da NF-e, NT 2014.001 v1.41, página 9; EPEC da NFC-e, NT 2014.003 v1.02, página 9, sujeito à disponibilidade específica desse serviço na UF

• Pedido de prorrogação de suspensão do ICMS, seu cancelamento e respostas do Fisco, NT 2015.001 v1.30, páginas 36, 44 e 53

• Manifestação do destinatário, NT 2020.001 v1.60, página 13; Ator Interessado/Transportador, NT 2020.007 v1.40, página 8

• Comprovante de entrega, NT 2021.001 v1.01, página 7; insucesso na entrega, NT 2023.005 v1.02, página 8

• Cancelamento por substituição da NFC-e, NT 2018.004 v1.00, página 7; conciliação financeira ECONF, NT 2024.002 v1.00, página 9

• Consulta GTIN, NT 2022.001 v1.00, página 9; Visto Eletrônico do Fisco, BT 2018.002 v1.00, página 12

Essas ocorrências identificam a verificação da mensagem. Não autorizam o empresário a executar atos reservados ao Fisco, nem demonstram disponibilidade universal. A consulta GTIN, por exemplo, tem finalidade distinta da autorização da nota.

As revisões anteriores de manifestação e Ator Interessado, assim como os MOC 5 e 6, ajudam a interpretar registros antigos. Não devem definir sozinhas o contrato atual. Uma tabela que apenas lista 588, como as páginas finais de algumas notas técnicas, precisa ser lida junto da seção de validação correspondente.

Corrigir na origem sem comprometer a assinatura

Evite abrir um XML assinado, apagar caracteres por tentativa e reenviá-lo. Dependendo de onde a alteração ocorrer, a integridade da assinatura pode ser afetada. O resultado pode deixar de ser 588 e passar a uma rejeição de assinatura, sem resolver corretamente o processo.

O caminho seguro é ajustar a serialização do emissor: gerar a estrutura conforme o padrão, preservar os valores legítimos, aplicar as assinaturas necessárias e conferir a mensagem final antes da transmissão. Se um componente de comunicação altera o arquivo depois dessa etapa, ele também precisa ser corrigido.

Documentos já autorizados devem ser conservados com seus protocolos. A rejeição de uma mensagem posterior não justifica reformatar o arquivo autorizado, sobrescrever o original ou modificar a operação. Trabalhe com cópias de diagnóstico e mantenha a evidência que permite comparar as tentativas.

A NS7 recomenda validar o XML e revisar a inserção automática de caracteres extras. Essa orientação é útil para prevenção, mas “limpar” o arquivo não deve virar uma rotina cega que apaga conteúdo. Schema, formatação e assinatura precisam ser verificados em conjunto.

Roteiro para fechar a ocorrência

1. Registre serviço, ambiente, autorizador, modelo quando houver, horário e mensagem completa

2. Preserve XML gerado, mensagem transmitida e retorno; em lote, separe resposta geral e resultados individuais

3. Identifique os caracteres indevidos e a etapa que os introduziu, diferenciando visualização de transmissão

4. Corrija o componente responsável, sem alterar valores fiscais para contornar a validação

5. Gere e valide novamente a solicitação pelo fluxo adequado, respeitando sua assinatura

6. Antes de repetir um evento com resultado anterior incerto, confira o que já foi registrado

7. Guarde o retorno conclusivo e teste outras mensagens que utilizam o mesmo componente

Passar pelo schema não substitui todos os controles do autorizador. E deixar de receber 588 não significa, por si só, que uma nota foi autorizada ou um evento registrado. A conclusão depende da resposta específica à solicitação corrigida.

Base consultada e limites

Fontes oficiais preservadas com corte em 9 de outubro de 2026, relidas em 10 de outubro, sem confirmação de implantação em todas as UFs. Três editores práticos confrontados: TecnoSpeed, caracteres de edição, Dynamicca, localização do XML e NS7, revisão da geração. Procedimentos de telas e referências históricas foram mantidos em seu contexto.