Rejeição 588 — Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem

O que é esta rejeição?#

A Rejeição 588 é retornada pela SEFAZ quando o sistema identifica o seguinte problema na NF-e: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem. A nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Não é permitida a presença de caracteres de edição no início/fim da mensagem ou entre as tags da mensagem.

Causas comuns#

• O XML contém erros de formatação, namespaces inválidos ou codificação incorreta
• A versão do layout XML não é suportada ou é superior à vigente na SEFAZ
• Há caracteres especiais, espaços ou quebras de linha indevidas no XML
• O XML deve usar codificação UTF-8 sem BOM (Byte Order Mark)

Como resolver#

1. Valide o XML com um parser antes de enviar — ele deve ser bem-formado (well-formed)
2. Use apenas o namespace padrão da NF-e: http://www.portalfiscal.inf.br/nfe
3. Salve o XML com codificação UTF-8 sem BOM
4. Atualize a versão do layout no sistema emissor para a versão vigente aceita pela SEFAZ
5. Remova caracteres de edição (tabs, espaços extras) do início e fim do XML

Verificações analíticas#

• Se o XML contém declaração <?xml ...?> seguida de espaços, quebras de linha ou tabulações antes da tag raiz <nfeProc> ou <NFe>, então o parser SEFAZ detecta caracteres de edição no início da mensagem: remova qualquer whitespace entre a declaração XML e a tag raiz, garantindo que a sequência seja exatamente '?><nfeProc' ou '?><NFe' sem caracteres intermediários.
• Se algum valor numérico de campo como vBC, vICMS, vProd, vNF ou pICMS contém espaços, tabs ou quebras de linha embutidos dentro da tag (por exemplo '<vBC> 100.00</vBC>' ou '<vICMS>23.00 </vICMS>'), então o SEFAZ interpreta esses espaços como caracteres de edição entre tags da mensagem: serialize todos os valores numéricos sem whitespace interno, garantindo que o conteúdo da tag seja apenas o valor puro como '100.00'.
• Se o arquivo XML foi salvo com BOM UTF-8 (bytes EF BB BF no início do arquivo) precedendo a declaração <?xml version='1.0' encoding='UTF-8'?>, então o SEFAZ rejeita com cStat 588 porque os três bytes de BOM são interpretados como caracteres de edição antes da mensagem: re-encode o arquivo em UTF-8 sem BOM usando um editor hexadecimal ou biblioteca que permita controle explícito do BOM.
• Se o atributo xmlns da tag <NFe> ou <nfeProc> difere de 'http://www.portalfiscal.inf.br/nfe' ou se há declarações de namespace adicionais como xmlns:xsi ou xmlns:xsd inseridas automaticamente por serializadores como .NET XmlSerializer ou Java JAXB, então o SEFAZ pode interpretar os namespaces extras como estrutura não reconhecida e rejeitar: remova todos os namespaces além do padrão e garanta que a declaração seja exatamente xmlns='http://www.portalfiscal.inf.br/nfe'.
• Se o valor do campo verNFe no atributo da tag <infNFe> ou o campo <versao> no envelope <nfeProc> for diferente de '4.00' ou contiver espaços extras como ' 4.00' ou '4.00 ', então ocorre dupla falha: rejeição por versão incompatível e por caracteres de edição no valor do atributo: normalize o atributo para exatamente versao='4.00' sem qualquer whitespace antes ou depois do valor.