Voltar para o blog

NF-e e NFC-e

Rejeição 404: como corrigir o uso de prefixo de namespace no XML

A rejeição fiscal 404 informa que a mensagem enviada usa um prefixo de namespace que não é permitido pelo padrão do serviço. A correção normalmente depende do gerador de XML ou da integração: o suporte deve ajustar a forma como a mensagem é montada e verificar novamente o envio.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 404: como corrigir o uso de prefixo de namespace no XML.

A rejeição fiscal 404 informa que a mensagem enviada usa um prefixo de namespace que não é permitido pelo padrão do serviço. A correção normalmente depende do gerador de XML ou da integração: o suporte deve ajustar a forma como a mensagem é montada e verificar novamente o envio.

Mensagem: “Rejeição: Uso de prefixo de namespace não permitido”.

Confira primeiro se esse é o cStat retornado no XML da SEFAZ. Um erro HTTP 404 de acesso a um endereço é outra ocorrência e exige investigação da comunicação, não a aplicação automática deste procedimento.

O que significa namespace?

Namespace é uma identificação que associa os elementos XML ao padrão a que pertencem. No projeto NF-e, o namespace dos dados fiscais é http://www.portalfiscal.inf.br/nfe. Esse texto funciona como identificador técnico; não é o endereço do serviço para o qual o sistema deve transmitir a nota.

Um prefixo é uma forma de abreviar essa identificação nos nomes dos elementos, como “nfe:” em nfe:enviNFe. Embora XML permita trabalhar com prefixos, o MOC exige a forma definida pelo projeto e a regra D02 rejeita o uso de prefixo não permitido. MOC 7.0, Anexo I, seção 4.1.3.

O MOC apresenta a declaração padrão dos dados da NF-e e trata separadamente o namespace da assinatura digital, que deve ficar no elemento Signature. Por isso, a solução precisa preservar a assinatura e a estrutura de comunicação. Remover todas as declarações de namespace do arquivo indiscriminadamente pode produzir novos erros. MOC, Visão Geral, seção 4.2.1.2.

A 404 pode ocorrer fora da emissão da nota

A regra aparece na validação geral dos Web Services de NF-e/NFC-e, mas a mensagem recusada pode ser uma autorização, uma consulta ou um envio de evento. A SEFAZ-MS, ao comunicar a ativação da D02 em produção em 25/11/2020, utilizou um exemplo de consulta de status do serviço. Esse comunicado é uma referência histórica de implantação em MS, não uma data de início nacional. Orientação oficial da SEFAZ-MS.

Há regras equivalentes na Distribuição DF-e, pela NT 2014.002 v1.40, e no gerenciamento de CSC da NFC-e, pela NT NFC-e 2014.001. Também há previsão nos eventos de manifestação do destinatário, EPEC e prorrogação de industrialização. Identifique a operação concreta antes de escolher o XML a corrigir.

Se a rejeição veio de uma consulta, corrija a consulta. Se veio de um evento de uma nota já autorizada, corrija o evento. A ocorrência não justifica refazer a venda ou substituir uma nota que continua válida.

Como investigar com o suporte

  1. Guarde a resposta integral e confirme cStat 404 com a mensagem de namespace. Anote serviço, modelo, UF, ambiente e horário.

  2. Separe a mensagem efetivamente enviada, incluindo a área de dados que foi entregue ao Web Service. Uma exportação anterior pode não mostrar a alteração feita pela camada de transmissão.

  3. Peça ao fornecedor que confira as declarações de namespace e os nomes dos elementos fiscais. Procure prefixos introduzidos na geração, conversão ou remontagem do XML.

  4. Compare a mensagem com a especificação do serviço e do pacote aplicável. O namespace de uma assinatura ou de um envelope de comunicação não deve ser apagado por uma regra genérica de substituição de texto.

  5. Corrija a geração na origem e execute nova validação. Se o conteúdo assinado foi alterado, a assinatura precisa ser produzida novamente pelo emissor.

A TecnoSpeed orienta conferir os namespaces da mensagem de envio. Use o leiaute atual do seu serviço; um exemplo antigo de consulta não deve ser copiado integralmente como modelo de autorização.

O que fazer em cada cenário

O erro começou após mudar a integração: compare a mensagem antes e depois da mudança. Bibliotecas de XML podem usar prefixos ao reescrever um documento. O fornecedor deve configurar a geração para o padrão fiscal, em vez de pedir que o usuário edite cada arquivo manualmente.

O arquivo salvo parece correto, mas o envio falha: confira o conteúdo depois que ele passa pela assinatura e pela camada de comunicação. A investigação precisa alcançar o ponto em que o prefixo é introduzido. Apenas olhar o DANFE ou o cadastro de produtos não revela essa transformação.

O problema ocorre apenas em uma UF ou ambiente: guarde um envio rejeitado e a configuração utilizada. A aceitação em outro autorizador não comprova que o XML esteja de acordo com o padrão. O caso histórico de MS mostra que uma regra já prevista pode passar a ser efetivamente aplicada. A TOTVS documentou esse contexto para seu emissor.

O retorno ocorreu no gerenciamento do CSC: revise o XML da consulta, solicitação ou revogação em questão. A 404 aponta a forma da mensagem; não é uma indicação de que o CSC precisa ser revogado. O serviço e sua disponibilidade dependem da UF. NT NFC-e 2014.001, regra A13.

Exemplo hipotético

Após atualizar a biblioteca de integração, uma empresa passa a enviar a consulta de status com o elemento fiscal “nfe:consStatServ” e uma declaração de namespace com prefixo. O autorizador devolve a 404.

O fornecedor ajusta a geração dos dados da consulta para usar a declaração padrão do projeto, sem o prefixo indevido, mantendo o serviço e o ambiente corretos. A consulta volta a ser processada. Como o problema estava na consulta de status, nenhuma nota precisava ser reemitida ou ter seus dados fiscais alterados.

Como confirmar a solução

Confira o retorno da mesma operação, agora com a mensagem corrigida. Em uma consulta de status, verifique a resposta do serviço; na autorização, o resultado da nota; em um evento, seu resultado individual. Um retorno de consulta de status não autoriza uma nota que ainda não foi transmitida.

Se a rejeição continuar, encaminhe ao suporte o XML de saída e a resposta, com os dados necessários por um canal seguro. A orientação de procurar o fornecedor quando o usuário não controla a geração do XML também aparece em uma discussão técnica do Projeto ACBr sobre a D02.

Revisão: 09/10/2026. A especificação nacional foi cotejada com documentos de serviços e orientações de implantação; não foi realizado teste em cada autorizador.

Referências complementares

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.