Rejeição 409: cUF ausente no cabeçalho SOAP exige identificar o serviço

A mensagem “Campo cUF inexistente no elemento nfeCabecMsg do SOAP Header” aponta para uma informação de controle ausente na chamada de um serviço. Antes de preencher qualquer campo, porém, é preciso descobrir qual serviço respondeu. A autorização comum da NF-e e da NFC-e na versão 4.00 deixou de exigir esse cabeçalho. Adicioná-lo indiscriminadamente pode manter uma integração desatualizada em vez de resolver a causa.

O código 409 continua documentado em contratos específicos, como os eventos de prorrogação de industrialização. Também aparece em documentos antigos do EPEC da NFC-e e da administração do CSC. Esta orientação serve para interpretar esses contextos e investigar um retorno real, sem afirmar que todos estejam ativos em qualquer estado ou ambiente.

O que está faltando, exatamente?

SOAP é o formato usado na comunicação entre muitos sistemas emissores e a administração tributária. Nos contratos que utilizam nfeCabecMsg, esse grupo transporta informações de controle separadas do XML principal. cUF identifica uma unidade federativa por código numérico, conforme o contrato da operação.

Por isso, preencher a UF na tela do cliente ou encontrar cUF dentro de ide, no XML da nota, não comprova que o campo exigido chegou ao cabeçalho da requisição. São posições diferentes. O diagnóstico deve olhar a mensagem efetivamente enviada, depois de sua montagem pelo componente de transmissão.

Também há uma distinção importante entre ausência e conteúdo incompatível. A 409 descreve ausência de cUF no local esperado. Quando a UF informada não é atendida pelo serviço, o código relacionado é 410. O texto integral de xMotivo ajuda a evitar que um número apresentado pelo ERP seja interpretado fora de contexto.

Por que uma receita antiga pode atrapalhar a NF-e 4.00

A NT 2016.002 eliminou as variáveis do SOAP Header na migração dos serviços relacionados à versão 4.00. O MOC 7.0, seção 4.4.1, confirma essa mudança. Ela alcança autorização, retorno de autorização, inutilização, consultas e os serviços de eventos enumerados na nota técnica.

Assim, se o sistema afirma estar chamando NFeAutorizacao4 e exibe 409, o suporte precisa conferir o endereço real, o método chamado e o WSDL utilizado para construir a integração. WSDL é a descrição técnica dos parâmetros aceitos pelo serviço. Uma configuração da aplicação pode dizer “4.00” enquanto outro módulo conserva um endereço ou uma estrutura antiga.

O objetivo é alinhar a integração ao contrato correto. Não se deve acrescentar um bloco antigo apenas porque uma tabela de rejeições ainda contém a mensagem. Tampouco se deve remover cabeçalhos de todos os serviços da empresa sem verificar suas particularidades.

Onde ainda existe documentação específica

Prorrogação de industrialização, NF-e modelo 55. A NT 2015.001 v1.30, de dezembro de 2024, conserva 409 nas seções de pedido de prorrogação, cancelamento desse pedido e eventos de resposta do Fisco. Os pedidos do contribuinte usam tipos 111500 e 111501; seus cancelamentos, 111502 e 111503. Os eventos de resposta fiscal pertencem à administração tributária e não são uma alternativa de envio para a empresa. O documento menciona adoção por SP e MG, sem estabelecer disponibilidade nacional. A exigência concreta deve ser confrontada com a implementação da UF e seu serviço.

EPEC da NFC-e, modelo 65. A NT 2014.003 v1.02 lista a 409 na seção 03.7. Trata-se de documentação própria desse evento, diferente do EPEC da NF-e modelo 55. A página oficial paulista distingue seus serviços de EPEC dos serviços comuns 4.00 e informa que, em produção, a Sefaz só o ativa diante de indisponibilidade da autorização normal. Essa referência estadual não comprova funcionamento equivalente nas demais UFs.

Administração do CSC. A NT NFC-e 2014.001 v1.00 prevê a regra A14 para consulta, geração e revogação de CSC pelo serviço de administração. Entretanto, o próprio manual deixa datas de vigência “a definir”. O Amazonas anunciou sua implementação em 2015; essa notícia histórica não comprova disponibilidade atual. A tabela do manual permite entender o código, sem assegurar que o serviço esteja disponível hoje para o contribuinte. Uma falha na administração do CSC também não equivale à rejeição de uma NFC-e enviada para autorização.

Como conduzir a correção sem mexer nos dados fiscais certos

1. Identifique a operação: autorização de documento, pedido de prorrogação, cancelamento de pedido, EPEC ou administração do CSC. Anote modelo, tipo de evento, UF e ambiente.

2. Guarde o retorno completo e o horário. Confirme que 409 veio em cStat, acompanhado da mensagem sobre nfeCabecMsg, e não é apenas um código interno do programa.

3. Solicite ao suporte a URL efetivamente chamada e o WSDL correspondente. Compare-os com a documentação oficial do serviço, incluindo a versão e a separação entre homologação e produção.

4. Se o contrato aplicável realmente exigir cUF no cabeçalho, verifique sua presença, localização e namespace, isto é, a identificação XML do serviço. Preencha o código numérico previsto para aquela operação. Não use a sigla “SP” no lugar de “35” quando o campo exige código.

5. Se o contrato já dispensar nfeCabecMsg, corrija o componente, o método ou o encaminhamento incompatível. Não recrie uma obrigação retirada da versão utilizada.

Imagine uma empresa que autoriza suas notas normalmente, mas recebe 409 ao pedir prorrogação. Alterar o cadastro de todas as filiais seria uma intervenção excessiva. Primeiro, deve-se isolar o módulo de eventos e comparar sua chamada com o serviço específico. A venda normal e o pedido de prorrogação podem seguir configurações distintas.

Como saber se o problema terminou

Depois do ajuste, faça uma validação controlada e leia o resultado da operação solicitada. O desaparecimento da 409 pode apenas permitir que outras verificações sejam executadas. No caso de evento, acompanhe seu retorno próprio; a autorização anterior da NF-e não confirma que o evento foi registrado.

Se houve dúvida sobre o processamento anterior, consulte a situação antes de repetir o envio. Não altere o XML de uma nota já autorizada, não cancele uma nota válida nem mude sua UF para compensar uma falha de comunicação. Encaminhe ao suporte somente registros necessários e protegidos, sem senha, arquivo de certificado, chave privada ou valor secreto do CSC.

Para prevenir recorrências, mantenha uma relação de configurações por filial, serviço, modelo, ambiente e versão. Esse registro torna visível quando uma atualização mudou apenas o módulo de autorização e deixou uma integração auxiliar com parâmetros antigos.

Fontes e limites da consulta

Base documental verificada em 10/10/2026, com PDFs oficiais preservados em capturas anteriores e páginas públicas consultadas nesta data. Documentação técnica não substitui a confirmação da implementação específica da UF.

• MOC 7.0, Visão Geral, seção 4.4.1

• NT 2016.002 v1.61, seções 2.2 e 2.3

• NT 2015.001 v1.30, seções 6.6, 7.6 e 8.6

• NT NFC-e 2014.003 v1.02, EPEC e manual de administração do CSC v1.00

• Sefaz-SP: serviços da NFC-e e condições do EPEC

• Referências práticas comparadas: NFePHP, pedido de prorrogação, FlexDocs, consulta cadastral multiversão e DataPlace, migração para NF-e 4.00 e seção SOAP. Seus exemplos e tabelas legados não comprovam ativação atual nem impõem cabeçalho aos serviços 4.00.

• Sefaz-AM, anúncio histórico de implantação do WS-CSC, 05/02/2015