NF-e e NFC-e
Rejeição 410: como conferir a UF atendida pelo Web Service
A rejeição 410 informa que a UF indicada na chamada não é atendida pelo Web Service que recebeu a mensagem. Para corrigir, compare o destino da transmissão com a UF, o modelo do documento e a operação efetivamente realizada. Alterar o estado cadastrado na nota apenas para fazê-la passar pode criar um erro fiscal e…
A rejeição 410 informa que a UF indicada na chamada não é atendida pelo Web Service que recebeu a mensagem. Para corrigir, compare o destino da transmissão com a UF, o modelo do documento e a operação efetivamente realizada. Alterar o estado cadastrado na nota apenas para fazê-la passar pode criar um erro fiscal e não é uma solução de encaminhamento.
Este código tem uma particularidade: aparece tanto em contratos antigos com cabeçalho SOAP quanto na regra B05 do MOC 7.0, aplicada à validação inicial da mensagem. Portanto, sua existência atual não depende de recolocar nfeCabecMsg nas chamadas da versão 4.00.
O que o serviço está conferindo
Um endereço de autorização da Sefaz não recebe necessariamente documentos de todas as UFs. Existem estruturas próprias e autorizadores virtuais que atendem estados determinados. Além disso, o atendimento pode variar conforme o serviço. A configuração adequada para autorizar uma NF-e não deve ser presumida para uma consulta cadastral, uma NFC-e ou um evento especializado.
No MOC 7.0, Anexo I, página 71, B05 verifica se a UF informada é atendida pelo serviço e prevê o retorno 410. É uma validação de encaminhamento. A mensagem, isoladamente, não demonstra erro de imposto, produto, destinatário ou enquadramento tributário.
O primeiro cuidado é obter o texto integral do retorno. Em um evento, a referência pode ser ao órgão que recebe a solicitação, representado por cOrgao, em vez de uma instrução para editar ide/cUF da nota. O código numérico deve sempre acompanhar o nome da operação.
Autorização 4.00 e cabeçalhos antigos são contextos diferentes
A NT 2016.002 retirou as variáveis do SOAP Header dos serviços migrados para 4.00. Na sua explicação histórica, aparecem riscadas as antigas validações de nfeCabecMsg, incluindo a verificação de UF. O MOC 7.0 mantém a retirada do cabeçalho e, ao mesmo tempo, registra a verificação B05.
Isso significa que uma integração pode receber 410 mesmo sem precisar enviar cUF em um SOAP Header. A correção deve seguir o conteúdo e o contrato do serviço atual. Copiar um exemplo antigo com nfeCabecMsg acrescenta uma peça desnecessária quando o WSDL utilizado já a eliminou.
WSDL é a descrição técnica da interface. O suporte precisa conferir essa interface junto da URL realmente acessada, e não apenas a versão exibida no cadastro do emissor. Endereço, método, estrutura XML e ambiente devem corresponder à mesma operação.
Um roteiro de verificação para a empresa
1. Delimite onde a falha ocorre. Identifique a filial, a UF, o modelo 55 ou 65 e a operação: autorização, inutilização, consulta, evento ou outro serviço. Registre o tipo de emissão e, para eventos, tpEvento e cOrgao. Uma falha restrita a uma filial ou módulo ajuda a localizar a configuração responsável.
2. Confira a origem dos dados no ERP. Verifique de onde o programa obtém a UF. Pode haver parâmetros próprios de filial, integrações ou cadastros duplicados. A TOTVS, por exemplo, documenta uma ocorrência de NFC-e no Protheus relacionada à origem do endereço selecionado pelo parâmetro MV_SPEDEND. Essa é uma investigação específica daquele produto, não uma autorização para substituir a UF fiscal pelo endereço do cliente.
3. Compare a URL com a relação oficial do serviço. Verifique se o autorizador atende aquela UF e aquele modelo na operação desejada. Se o endereço estiver errado, ajuste o encaminhamento. Se o dado fiscal estiver realmente incorreto, corrija-o com base no cadastro legítimo do estabelecimento e, se o documento ainda não estiver autorizado, regenere-o pelo fluxo normal. Não altere XML já autorizado.
4. Separe ambiente de jurisdição. Homologação é utilizada para testes; produção, para operações reais. A mistura de ambientes precisa ser corrigida, mas não equivale automaticamente a UF não atendida. O código 252 trata de divergência de ambiente em seus contextos próprios. Mudar de homologação para produção não justifica alterar a UF, nem o contrário.
5. Examine contingência e atualizações recentes. Um componente pode conservar a rota de outro autorizador depois de uma alteração de configuração. A contingência depende das condições do serviço e da UF. Não ative modalidades ou tente endereços aleatórios como forma de vencer a rejeição.
Eventos que exigem atenção ao órgão receptor
No ECONF, evento de conciliação financeira disciplinado pela NT 2024.002, a mensagem 410 faz referência a cOrgao. O leiaute distingue NF-e modelo 55, direcionada ao código 92/SVRS, de NFC-e modelo 65, cujo encaminhamento depende da participação da UF na SVRS ou de autorizador próprio. Essa indicação pertence ao evento e não muda a UF do emitente na nota.
Outros documentos também conservam 410 na validação inicial, como as especificações de EPEC da NF-e, comprovante de entrega, insucesso na entrega, ator interessado/transportador e cancelamento por substituição da NFC-e. Isso não torna seus endereços intercambiáveis. Para qualquer evento, identifique o tipo, o órgão previsto e a versão aplicável antes de ajustar a rota.
Na prorrogação de industrialização, a NT 2015.001 v1.30 ainda lista 410 nas chamadas de pedido, cancelamento de pedido e resposta fiscal. A documentação menciona SP e MG; a disponibilidade e o contrato da UF precisam ser confirmados. Eventos emitidos pelo Fisco não devem ser enviados pelo contribuinte.
EPEC da NFC-e e administração do CSC
A NT 2014.003 v1.02 do EPEC da NFC-e contém a verificação de UF em seu contrato documentado. Em São Paulo, o portal separa os serviços de EPEC dos serviços comuns 4.00 e informa que a Sefaz só o ativa em produção diante de indisponibilidade da autorização normal. Não se deve transportar para esse contexto, automaticamente, a configuração do EPEC da NF-e modelo 55.
Já o manual de administração do CSC prevê a regra A15 com retorno 410. É um serviço auxiliar descrito em documento de 2014 com vigências “a definir”, sem comprovação de oferta universal. O Amazonas anunciou implantação em 2015, sem comprovar a disponibilidade atual. Essa referência não transforma uma rejeição da autorização de NFC-e em problema no segredo do CSC. Gerar ou revogar códigos de segurança não corrige, por si só, o destino errado de uma requisição.
Validação final e prevenção
Depois de corrigir a causa comprovada, acompanhe o resultado da operação. Se houve transmissão anterior com retorno incerto, consulte a situação antes de reenviar. Eliminar a 410 não garante que todas as demais validações tenham passado.
Guarde o diagnóstico por filial, modelo, serviço, ambiente e versão. No chamado técnico, informe cStat, xMotivo, horário e URL utilizada, com os dados necessários protegidos. Não envie certificado, senha, chave privada ou CSC. Essa documentação permite resolver falhas de encaminhamento sem modificar informações fiscais corretas nem expor credenciais.
Fontes e limites da consulta
Verificação documental em 10/10/2026. Os PDFs oficiais foram relidos de capturas preservadas; não houve teste de transmissão nem comprovação de disponibilidade em todas as UFs.
NT NFC-e 2014.003 v1.02, administração do CSC v1.00 e Sefaz-SP: condições do EPEC
Referências práticas comparadas: TecnoSpeed, TOTVS, Protheus NFC-e e InvoiSys. A página da InvoiSys contém uma menção interna a 920; ela não altera a identificação oficial de 410 adotada aqui.
NT 2018.004, cancelamento por substituição da NFC-e, seção 2.5 e Sefaz-AM, implantação histórica do WS-CSC em 2015