Rejeição 271: município do fato gerador diferente da UF do emitente

A rejeição 271 ocorre quando os dois primeiros algarismos do município do fato gerador do ICMS não correspondem ao código da UF do emitente. Para corrigir, compare cMunFG com cUF no XML efetivamente enviado e confirme os dados da operação. Ajuste a informação que estiver errada na origem e gere novamente o documento pelo emissor.

O município pode existir no IBGE e ainda assim provocar essa rejeição. O problema, aqui, é a relação entre município e estado. Escolher outra cidade apenas porque seu código começa com os algarismos esperados não é uma correção segura: o preenchimento precisa representar a operação real.

Os dois campos que precisam ser comparados

A regra B12-20 compara as duas primeiras posições de NFe/infNFe/ide/cMunFG, campo B12, com NFe/infNFe/ide/cUF, campo B02. O MOC 7.0, página 76 apresenta a validação como obrigatória para os modelos 55 e 65, no serviço de autorização.

cUF é numérico, como 35 para São Paulo. Já UF, no endereço do emitente, usa uma sigla, como SP. Esses campos devem ser coerentes com o estabelecimento, mas não são intercambiáveis. Procurar somente a sigla visível na tela pode deixar um cUF incorreto na configuração de emissão.

A documentação da Tecnospeed para a rejeição 271 identifica justamente cUF e cMunFG na integração. O nome que cada software atribui a esses parâmetros pode variar; a conferência final deve chegar ao XML.

Um exemplo que separa existência e compatibilidade

Considere uma emissão cujo estabelecimento e fato gerador, após conferência fiscal, estão em Campinas/SP. O XML informa cUF igual a 35, mas cMunFG recebeu 3303302, código de Niterói/RJ. Os dois códigos municipais constam da tabela oficial do IBGE, porém o prefixo 33 não corresponde a 35.

Nesse cenário, a origem do erro pode ser um mapeamento que trouxe para cMunFG a cidade de outro participante. O valor correto para Campinas é 3509502. A mudança se justifica pela informação confirmada da operação, e não pela conveniência de eliminar a rejeição.

A regra 271 não exige que cMunFG seja idêntico, em todos os sete algarismos, ao município do endereço do emitente. Sua comparação é com a UF. Isso não permite escolher livremente qualquer município daquele estado: a definição do fato gerador continua precisando de fundamento fiscal.

Investigue o cadastro e a integração

Comece pelo retorno rejeitado, registrando cStat, xMotivo, modelo, ambiente e horário. Separe o XML dessa mesma tentativa. A configuração atual do sistema pode já ter mudado e não explicar o arquivo que o autorizador recebeu.

Depois, confira:

• qual estabelecimento foi selecionado para emitir a nota;

• de onde o programa obtém cUF;

• qual cadastro ou parâmetro fornece cMunFG;

• se uma nota copiada preservou a cidade de outra filial;

• se a integração misturou endereço do cliente e informações do emitente;

• se a seleção da cidade respeitou a UF correta.

A base da NS7 aponta o preenchimento a partir do destinatário como uma possível origem do problema. Isso é uma hipótese de diagnóstico, não uma conclusão sobre toda nota rejeitada. Compare os dados para saber se ela se aplica ao seu caso.

A orientação da Oobj também parte da divergência entre os dois primeiros dígitos do município e cUF. Ao consultar a tabela, procure pelo par cidade/estado e use o código completo. Não reaproveite códigos de exemplos publicados como se fossem parâmetros gerais.

O que não deve ser alterado por tentativa

Se cUF estiver correto, não o mude para acompanhar uma cidade indevida. Esse código participa da identificação do documento e precisa corresponder à UF do emitente. Também não altere o estabelecimento, o endereço verdadeiro ou o enquadramento da operação só para produzir uma combinação aceita.

Se a conferência mostrar que cUF foi configurado incorretamente, corrija o parâmetro com apoio do responsável pela emissão e gere o documento de forma consistente. Não faça uma substituição isolada em arquivo assinado. A correção deve percorrer o fluxo normal do sistema, inclusive identificação e assinatura.

Não apague cMunFG. Ele é um campo previsto no leiaute, e sua ausência pode gerar outra falha. O valor especial 9999999 usado em determinados campos de endereço no exterior não serve como alternativa para contornar a comparação de UF do fato gerador do ICMS.

Rejeições parecidas e o novo campo do IBS

A rejeição 270 verifica se o código de cMunFG existe. A 271 verifica sua compatibilidade com a UF. A 273 faz outra comparação, envolvendo o município do endereço do emitente. Ler somente “município” na mensagem pode levar à correção do grupo errado.

A NT 2025.002 v1.52, página 15 distingue cMunFG, do ICMS, de cMunFGIBS, do IBS/CBS. O campo novo tem condições próprias. Sua presença não substitui o campo antigo nem muda, por si, o significado da rejeição 271.

Este diagnóstico trata de autorização de NF-e/NFC-e. Se o código apareceu em um evento, em consulta pública por QR Code ou em outro serviço, verifique a mensagem e o serviço antes de transportar a solução. A classificação obrigatória no MOC também não equivale a um teste operacional de todos os autorizadores.

Como confirmar que a correção chegou à SEFAZ

Salve a correção na origem, gere outro XML e confira novamente cUF e cMunFG. Se ambos estiverem coerentes com os dados confirmados, valide, assine e transmita pelo emissor. Leia o novo retorno até obter uma conclusão sobre a autorização.

Se a divergência persistir, encaminhe ao suporte as duas versões do XML e seus retornos, preservando os dados fiscais em canal seguro. Comparar o antes e o depois ajuda a identificar configurações que o programa sobrescreve durante a geração. Corrigir esse ponto evita que a mesma rejeição reapareça na próxima nota ou em outra filial.

Referência de atualização: 09/10/2026. Documentação oficial e fontes práticas consultadas; aplicar ao modelo, à versão, à UF e ao ambiente correspondentes.