NF-e e NFC-e
Rejeição 587: como corrigir o namespace do XML da NF-e ou NFC-e
A rejeição 587 indica que a área de dados da mensagem usa um namespace diferente do padrão fiscal esperado. A correção deve ocorrer no componente que gera o XML: confira o arquivo realmente transmitido, ajuste a declaração e valide novamente o documento. Alterar tributos, trocar o certificado ou emitir outra nota sem…
A rejeição 587 indica que a área de dados da mensagem usa um namespace diferente do padrão fiscal esperado. A correção deve ocorrer no componente que gera o XML: confira o arquivo realmente transmitido, ajuste a declaração e valide novamente o documento. Alterar tributos, trocar o certificado ou emitir outra nota sem investigar não corrige esse problema de estrutura.
Mensagem: “Rejeição: Usar somente o namespace padrão da NF-e”. A documentação do EPEC NFC-e também apresenta a redação com “NFC-e”.
O que significa namespace
Namespace identifica a família à qual pertencem os elementos de um XML. Para os dados da NF-e e NFC-e, o identificador é http://www.portalfiscal.inf.br/nfe. Embora pareça um endereço de site, sua função aqui é identificar o vocabulário do documento; não é o endereço do serviço para transmissão.
A regra D01d, no grupo de validação da área de dados, verifica namespaces divergentes. Sua aplicação é facultativa para o autorizador na especificação. Isso não permite gerar um XML fora do padrão: outro ambiente pode devolver 587 ou uma falha de schema. MOC 7.0, Anexo I, seção 4.1.3.
A sequência é exata. Não substitua http por https, não acrescente barra final e não use um domínio da empresa. Também não troque o namespace ao mudar a versão do leiaute: versão e namespace são informações distintas.
Preserve a assinatura e o envelope de comunicação
O MOC determina a declaração fiscal no elemento raiz e proíbe prefixos nos elementos fiscais. Também prevê expressamente o namespace XMLDSig na própria tag Signature: http://www.w3.org/2000/09/xmldsig#. Portanto, apagar toda declaração diferente do namespace fiscal destruiria uma parte legítima da assinatura. MOC, Visão Geral, seção 4.2.1.2.
O envelope SOAP pertence à camada de comunicação e deve seguir o WSDL do serviço. Não confunda seus namespaces com a área fiscal nem tente transformar o envelope inteiro em um documento NF-e. Essa separação ajuda a localizar onde a biblioteca introduziu uma declaração inadequada.
Como investigar e corrigir
Registre cStat, xMotivo, serviço, ambiente, UF ou autorizador, modelo e versão. Descubra se o erro aconteceu ao autorizar, consultar, inutilizar ou registrar um evento.
Solicite o XML efetivamente enviado. O arquivo salvo antes de passar pelo integrador pode estar correto, enquanto a mensagem final foi reconstruída com outro namespace.
Confira a raiz esperada para aquele pedido e a declaração fiscal. Autorização, consulta e evento usam estruturas diferentes; não renomeie todas as raízes para NFe.
Examine os elementos internos com um leitor XML que reconheça namespaces. Procure declarações herdadas de outra integração ou redefinições como xmlns="", que retiram elementos do namespace esperado. Essa é uma hipótese técnica a confirmar no arquivo, não a causa automática de toda 587.
Corrija a configuração ou o serializador responsável pela geração. A NS7 recomenda conferir a raiz, revisar a geração e validar com o schema. Preserve as declarações legítimas da assinatura e do transporte.
Gere novamente a mensagem rejeitada e, quando o serviço exigir assinatura, assine o conteúdo final. Alterar namespaces depois de assinar pode comprometer a verificação da assinatura.
Valide com o pacote de schemas específico e teste a alteração em homologação. Depois confira o resultado definitivo da operação em produção, sem presumir sucesso apenas porque a 587 desapareceu.
A TecnoSpeed confirma o identificador fiscal e ilustra uma consulta de status. Seu exemplo usa versão antiga e não deve ser copiado como leiaute atual. A TOTVS direciona a análise ao componente de transmissão. Procedimentos específicos daquele produto não constituem solução universal para outros emissores.
Em quais operações esse diagnóstico se aplica
A validação integra as regras gerais dos serviços fiscais. O MOC inclui o grupo D na autorização, consulta de recibo quando aplicável, inutilização, consulta de protocolo, status, cadastro, distribuição e recepção de eventos. Cada pedido conserva seu próprio leiaute e suas condições de utilização.
Há ocorrência explícita de 587 nas especificações de:
NF-e 55: EPEC, prorrogação da suspensão do ICMS na industrialização, manifestação do destinatário, comprovante de entrega, insucesso na entrega e ator interessado
NFC-e 65: EPEC, sujeito à adoção da UF, e cancelamento por substituição; a NT desse cancelamento também documenta o cancelamento normal
NF-e/NFC-e: evento de conciliação financeira, respeitando o destino de recepção previsto para cada modelo
Consulta GTIN: mensagem própria de consulta, não uma nova emissão de nota
As notas técnicas desses serviços remetem à validação geral da área de dados. O número 587 não autoriza usar um evento de modelo 55 no modelo 65 nem comprova disponibilidade em toda UF. Veja, por exemplo, a NT 2022.001, seção 04.6 e a NT 2024.002 de conciliação financeira, seção 3.6.
Exemplos hipotéticos
Uma atualização acrescenta uma barra ao namespace fiscal. A equipe compara os fragmentos abaixo, corrige o serializador e regenera a mensagem. São fragmentos didáticos de consulta de status, sem os demais campos, não mensagens prontas para transmissão:
Incorreto, com barra extra:
<consStatServ xmlns="http://www.portalfiscal.inf.br/nfe/" versao="4.00"/>
Namespace correto para este leiaute:
<consStatServ xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"/>
A versão 4.00 é deste exemplo; não a copie para eventos ou serviços com outro leiaute. Não altere destinatário, valores ou tributação.
Em outro caso, a emissão funciona, mas a consulta de status recebe 587. O responsável descobre que somente o gerador da consulta herdou o namespace de outro serviço. Corrigir a consulta resolve a mensagem estrutural; gerar outra nota não teria relação com a causa.
Verificação final e cuidados
Compare o XML testado com a mensagem enviada. Uma validação local favorável perde utilidade se outra etapa modifica o documento. Confira também o serviço correto: 404 trata do uso de prefixo, 402 da codificação e 588 de caracteres de edição; esses retornos têm diagnósticos próprios.
Se houve tentativa anterior sem resposta, consulte sua situação antes de retransmitir. Em autorização ou evento, guarde o protocolo e o resultado individual. Em consulta, confirme que recebeu a informação solicitada. Não inutilize numeração nem crie outra nota apenas porque apareceu 587.
Se não for possível identificar o namespace divergente, encaminhe ao suporte os retornos, versões e a mensagem transmitida por canal seguro. Evite publicar XML fiscal integral em fóruns ou validadores de terceiros; ele pode conter dados pessoais e comerciais.
Revisão documental: 09/10/2026. Referência geral: MOC 7 e notas técnicas dos serviços; aplicação operacional depende do autorizador, ambiente e versão aplicável.