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.
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
Guarde a resposta integral e confirme cStat 404 com a mensagem de namespace. Anote serviço, modelo, UF, ambiente e horário.
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.
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.
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.
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
NT 2014.002 v1.40, Distribuição DF-e, seção 3.10.1, regra D02: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=uWO2d%2FgTuWg%3D#page=11
NT 2020.001 v1.60, manifestação do destinatário, seção 6.3.6: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=%2BWTd7iuD21s%3D#page=13