NFS-e: por que cada município tem padrão próprio e como a OCA resolve

Se você emite NF-e para o Brasil inteiro, lida com um único padrão nacional — o XML da NF-e (modelo 55) é o mesmo de São Paulo a Boa Vista, autorizado pela SEFAZ do estado mas seguindo o leiaute SEFAZ Virtual. Agora se você emite NFS-e, descobre rapidamente que é outro mundo: cada município pode ter um padrão próprio. E muitos têm.

Este post explica por que existe essa fragmentação, qual é o estado atual da padronização ABRASF/Nacional, como o Odoo+OCA cobre o problema, e o que fazer quando você precisa emitir para um município “extremo” — daqueles que ainda emitem por sistema próprio sem API documentada.

Por que cada município tem o seu padrão

A NFS-e é a Nota Fiscal de Serviço Eletrônica. Serviço, no sistema tributário brasileiro pré-Reforma, é tributado pelo ISS (Imposto Sobre Serviços), e o ISS é municipal — cada um dos 5.570 municípios brasileiros tem competência para legislar sobre alíquota (entre 2% e 5%), enquadramento de serviço, regras de retenção, e o sistema de emissão.

Resultado prático: em vez de um padrão nacional como a NF-e, surgiu uma constelação de sistemas:

• GINFES, NotaCarioca, ISS-e, NFSe-Recife, ISS Online, Goiânia ISS, e dezenas de outros — cada um com seu webservice, seu XSD, suas regras de assinatura, seu fluxo de cancelamento.
• ABRASF (Associação Brasileira das Secretarias e Finanças das Capitais) publicou um padrão de referência (versões 1.0, 2.x, 2.04 e variações) que muitos municípios adotaram com adaptações.
• NFS-e Nacional (padrão DPS) entrou em fase de implantação a partir de 2023, com adesão crescente — mas ainda longe de cobrir os 5.570 municípios.

Em 2026, com a Reforma Tributária, o ISS começa a ser substituído pelo IBS (ver Reforma Tributária 2026). Espera-se padronização nacional gradual ao longo da transição — mas até 2032, a coexistência continua.

O estado atual em três níveis

Nível 1: NFS-e Nacional (DPS)

O padrão federal mais novo, gerenciado pela Receita Federal e pelo Comitê Gestor do Simples. Webservice único, XML padronizado, integração via certificado digital. Esse é o céu fiscal: você integra uma vez e emite para qualquer município que aderiu.

A adesão municipal está crescendo, com ~3.000 municípios já no Nacional em 2025, mas as capitais maiores — São Paulo, Rio de Janeiro — mantiveram seus sistemas próprios em paralelo até a transição completa.

Nível 2: ABRASF

Municípios médios e algumas capitais usam variações do padrão ABRASF. Compartilham estrutura geral mas têm desvios em campos opcionais, em códigos de serviço (lista municipal de cada cidade), e em fluxos de assinatura. Quem cobre ABRASF cobre boa parte do Brasil — com ajustes.

Nível 3: padrão próprio

Municípios pequenos e alguns grandes (com sistemas legados) ainda têm webservices próprios, sem similaridade com ABRASF. Documentação em PDF na intranet da prefeitura, troca de chave manual, sandbox que cai com frequência. Existem.

Como a OCA cobre

O ecossistema l10n-brazil tem hoje cobertura modular, com módulos específicos por padrão:

• l10n_br_nfse — base abstrata de NFS-e, modelo de dados unificado.
• l10n_br_nfse_focus — integração com Focus NFe (provider que abstrai dezenas de prefeituras como serviço pago). É o caminho mais usado em produção, especialmente para empresas que emitem para muitas cidades.
• l10n_br_nfse_nacional — integração direta com o padrão Nacional (DPS).
• l10n_br_nfse_paulistana — integração direta com o padrão da Prefeitura de São Paulo (NotaCarioca segue lógica similar com módulo próprio).
• Módulos específicos para padrões municipais relevantes (Recife, Curitiba, Belo Horizonte, etc.) conforme demanda da comunidade.

O modelo de dados unificado significa: do ponto de vista da operação, emitir NFS-e é igual independente do padrão. Você cria a fatura no Odoo, escolhe o serviço, confirma — e o motor por baixo escolhe o conector certo conforme o município emissor.

O caso dos “municípios extremos”

E quando o município que você precisa emitir não tem cobertura OCA? Três caminhos:

1. Provider intermediário (Focus NFe, NFE.io, Migrate, eNotas) — paga por nota e o provider lida com o conector específico. Para volumes baixos, é o caminho mais barato. Para volumes altos, a tarifa unitária pesa.
2. Conector custom — sua equipe ou parceiro escreve um módulo OCA-style para o padrão municipal específico. Faz sentido se o município é estratégico (sede da empresa, cliente grande), e se a documentação do webservice está acessível.
3. Emissão manual paralela — em municípios onde o volume é muito baixo (1-2 notas por mês), tem empresa que emite direto no portal da prefeitura e registra o contábil no Odoo. Não recomendamos como solução permanente, mas para fase de transição é aceitável.

Em projetos reais, vemos a regra 80/20 funcionar: 80% do volume cai em padrões cobertos diretamente (Nacional, Focus, Paulistana), e os 20% restantes ficam em provider intermediário ou conector custom.

Cuidados específicos

• Lista de serviços municipal: cada município tem o seu desdobramento da Lei Complementar 116/2003. Cadastrar os códigos certos é tão importante quanto a alíquota.
• Retenção de ISS: depende do enquadramento do tomador e do município de destino. O Odoo+OCA tem matriz de retenção configurável, mas precisa ser populada conforme a operação.
• Substituição tributária de ISS: alguns municípios (notadamente São Paulo) têm ST para certos serviços. Regra fiscal precisa estar configurada.
• Cancelamento e carta de correção: o fluxo varia por município. Em muitos, cancelamento depois de N dias só por processo administrativo, não por API.

Para mais sobre a complexidade fiscal brasileira em geral, veja EFD ICMS/IPI layout 20 e Migração TOTVS Protheus para Odoo.

A KMEE implementa NFS-e em Odoo+OCA para clientes que emitem para um único município ou para o Brasil inteiro, há mais de 14 anos. Se sua empresa precisa revisar cobertura municipal ou ampliar para novos municípios, fale com nosso time pela página de contato.