cMun do emitente na NF-e: código IBGE e rejeições 272, 273 e 480
<cMun>emit › enderEmit › cMunRevisão editorial em 27 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
cMun, em emit/enderEmit/cMun, é o código IBGE de sete dígitos do município do emitente. Ele é obrigatório e acompanha xMun, o nome do município, e UF, a sigla da unidade federativa. Não é CEP, código de país nem necessariamente o município de ocorrência do fato gerador informado em ide/cMunFG.
O caminho completo é /nfeProc/NFe/infNFe/emit/enderEmit/cMun, no namespace http://www.portalfiscal.inf.br/nfe. Deve representar a localização cadastral do estabelecimento identificado pela nota. MOC 7.0, C10, p. 13.
Como obter e conferir o código
Consulte a tabela oficial de municípios do IBGE para o município real e compare código, nome e UF. Não derive um código pelo nome abreviado, pelo CEP ou pelo município de uma filial diferente. Municípios homônimos ou cadastros internos desatualizados exigem identificação por UF e código, não apenas pelo texto exibido.
O tipo TCodMunIBGE exige [0-9]{7}. Esse padrão identifica o formato; a existência do código é uma verificação adicional. As duas primeiras posições devem corresponder ao código da UF. No exemplo confirmado pelo IBGE, Goiânia é 5208707, localizada em GO, código 52. Schema PL010d v1.03, TCodMunIBGE.
O nome da cidade não entra na tag cMun. Preservar o código como texto evita alterações inadvertidas na importação; o emissor deve obter o valor do cadastro e do catálogo oficial, sem pedir que alguém invente os sete dígitos.
Três rejeições e três comparações diferentes
| Código | Regra e comparação | O que conferir |
|---|---|---|
| 272 | C10-10: código inexistente na tabela de municípios do IBGE | Se o código do XML consta da tabela oficial e representa o município pretendido |
| 273 | C10-20: duas primeiras posições diferentes do código da UF do emitente | Prefixo municipal e UF cadastral, distinguindo sigla de código numérico |
| 480 | 7C10-10, facultativa: município diferente do cadastrado na UF | Município do XML e cadastro estadual datado do emitente |
As duas primeiras regras se aplicam a modelos 55 e 65; a comparação cadastral 480 também é descrita para 55/65, com aplicação facultativa. MOC, pp. 82 e 138.
Um código existente de Goiânia com sigla SP não deixa de existir no IBGE, mas a combinação é incoerente para 273. Um código existente e coerente com GO ainda pode divergir do município cadastrado para aquela IE/CNPJ na UF, condição de 480. Não trate 480 como uma instrução para copiar o município do cadastro estadual sem verificar se houve mudança real de endereço e atualização pendente.
Exemplo XML e leitura das relações
Trecho parcial e sintético, não pronto para transmissão. A combinação geográfica abaixo é oficial; endereço e CEP não representam um estabelecimento comprovado.
<enderEmit xmlns="http://www.portalfiscal.inf.br/nfe">
<!-- logradouro, número e bairro omitidos -->
<cMun>5208707</cMun>
<xMun>Goiânia</xMun>
<UF>GO</UF>
<CEP>74000000</CEP>
</enderEmit>
cMun e xMun referem-se ao mesmo município. A UF é textual, enquanto o prefixo 52 do código municipal é numérico. O fragmento omite outros campos obrigatórios; não serve como nota nem como grupo completo para transmissão.
cMun do endereço não é cMunFG nem município da entrega
O caminho identifica a função: emit/enderEmit/cMun é localização do emitente; dest/enderDest/cMun é localização do destinatário; os grupos de entrega e retirada representam locais próprios; ide/cMunFG descreve o município de ocorrência do fato gerador conforme seu contrato.
Esses dados podem coincidir em uma operação sem serem cópias obrigatórias uns dos outros. O município do endereço também pode participar de uma regra específica: por exemplo, C22-10 da NT 2025.002 compara município do emitente quando ISUFEmit está informada. Passar em 272/273 não comprova pertencer à área dessa outra validação. A aplicabilidade de incentivos ou do fato gerador depende da operação e não deve ser decidida apenas pelo município. NT 2025.002 v1.51, C22-10, p. 37.
A regra C22-10 integra a etapa 1.40 da NT, com produção documentada em 03/08/2026, já passada no corte de 26/09/2026. A observação geral do cronograma condiciona as validações específicas de IBS/CBS/IS a documentos com campos dos novos tributos preenchidos, ressalva variação em homologação por UF e separa os prazos legais de validade jurídica. Confira esse alcance e o documento efetivo; a ressalva não orienta omitir dados aplicáveis. NT 2025.002 v1.51, pp. 5–6.
Como verificar a causa e a correção
Reúna XML gerado, retorno original, documento do emitente, IE, UF e endereço comprovado. Para 272, consulte a existência e a identidade na tabela IBGE. Para 273, compare código e sigla com a localização verdadeira. Para 480, consulte o cadastro estadual e sua data de atualização, especialmente após mudança real de município.
Se a origem interna estiver comprovadamente errada, corrija o cadastro ou o mapeamento autorizado. Se houver divergência oficial, confirme atualização pelo canal competente. Depois compare novamente código, nome e UF no XML e no cadastro, preservando o arquivo anterior sem editar assinatura. Não altere município para atingir uma condição tributária; leve os dados reais ao responsável contábil quando o problema envolver enquadramento da operação.
Referência técnica para integração
- XPath completo
/nfeProc/NFe/infNFe/emit/enderEmit/cMun- Namespace
http://www.portalfiscal.inf.br/nfe- Leiaute
- 4.00 · PL_010e_v1.02
- Ocorrências no XSD
- 1–1 no contexto do elemento pai
- Tipo
- TCodMunIBGE · string
- Preenchimento no catálogo
- Obrigatório
A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.
- pattern
[0-9]{7}- whiteSpace
preserve