NFS-e: o documento fiscal mais difícil do Brasil

Pergunte a qualquer pessoa que já implantou um sistema fiscal no Brasil qual é o documento mais difícil de emitir, e a resposta quase sempre é a mesma: a NFS-e, a Nota Fiscal de Serviços Eletrônica. Não porque o cálculo do imposto seja complicado — é porque, diferente da NF-e, não existia um padrão único nacional. Este post explica por que isso acontece, o que está mudando com o padrão nacional, e como o Odoo com a localização da comunidade OCA enfrenta esse cenário fragmentado.

Por que a NFS-e é tão complicada

A NF-e de mercadoria (modelo 55) é competência estadual, e a SEFAZ de cada estado segue um layout nacional unificado. Já a NFS-e é competência municipal — o imposto envolvido é o ISS (Imposto Sobre Serviços), e quem regula é a prefeitura. São mais de 5.500 municípios no Brasil, e historicamente cada um podia escolher:

• O layout do XML e do webservice.
• O provedor de software que opera a emissão (existem dezenas de provedores de NFS-e atuando como categoria, cada um com sua API).
• As regras de retenção de ISS, alíquotas e códigos de serviço.
• A lista de serviços baseada na LC 116, mas com adaptações locais.

O resultado: integrar a NFS-e de uma empresa que fatura em várias cidades significava integrar, na prática, vários sistemas diferentes — cada um com sua autenticação, seu formato e suas peculiaridades.

ABRASF: o padrão que não foi padrão

Para reduzir o caos, a ABRASF (Associação Brasileira das Secretarias de Finanças das Capitais) publicou um modelo de referência de NFS-e. Muitos municípios adotaram alguma versão dele — mas em versões diferentes (1.0, 2.0, 2.01…) e com customizações. Então mesmo entre prefeituras “padrão ABRASF” havia divergência. Era um padrão de fato, não de direito.

O que muda com o padrão nacional da NFS-e

Desde os últimos anos, o governo federal vem implantando o padrão nacional da NFS-e, com um layout único, um ambiente de dados nacional e a integração via API nacional. A promessa é que, ao aderirem, os municípios passem a emitir todos pelo mesmo formato — encerrando a fragmentação.

Na prática, a transição é gradual:

• Muitos municípios já aderiram ao padrão nacional, especialmente os menores via emissor público.
• Capitais e cidades grandes, com sistemas próprios maduros, migram em ritmos diferentes.
• Por um bom tempo conviverão o padrão nacional e os layouts municipais legados — então um sistema fiscal precisa suportar os dois mundos simultaneamente.

É por isso que a NFS-e continua sendo, hoje, o documento que mais exige flexibilidade do ERP.

Como o Odoo com a localização OCA lida com múltiplas prefeituras

Aqui está o valor de uma localização fiscal madura. No Odoo com a localização mantida pela comunidade open-source OCA — com a KMEE entre as mantenedoras principais — a NFS-e é tratada com uma arquitetura que abstrai o provedor/município:

• O documento fiscal de serviço usa o mesmo modelo base (l10n_br_fiscal.document) da NF-e, com tipo de documento próprio para serviço.
• Cada padrão ou provedor é tratado como um “backend” — o sistema sabe falar com diferentes webservices municipais e com o padrão nacional, sem reescrever toda a lógica fiscal.
• O cálculo do ISS, das retenções e dos códigos de serviço (LC 116) fica na camada fiscal comum, reaproveitada entre municípios.

O ponto crucial é o modelo de manutenção. Suportar centenas de prefeituras é um esforço grande demais para uma única empresa carregar sozinha. Numa localização open-source upstream, várias consultorias e clientes contribuem suporte a novos municípios de volta para o mesmo repositório — todos se beneficiam. Numa localização fechada ou em fork privado, você depende de um único fornecedor ter priorizado a sua cidade. Se ele não priorizou, ou se encerrar as atividades, você fica desamparado.

Aprofundamos a engenharia desse suporte multi-prefeitura — com exemplos concretos — no post NFS-e em centenas de prefeituras com Odoo + OCA. Se a sua empresa fatura serviços em mais de uma cidade, vale a leitura.

Resumindo

A NFS-e é difícil porque é municipal e nunca teve um padrão único de verdade — ABRASF ajudou, mas não unificou. O padrão nacional está mudando isso, porém a convivência com layouts legados vai durar anos. No Odoo com a localização OCA, a NFS-e roda sobre uma base fiscal comum que abstrai provedores e municípios, e o suporte a novas prefeituras é mantido coletivamente — não preso a um único fornecedor.

Leituras relacionadas

• NFS-e em centenas de prefeituras com Odoo + OCA — o aprofundamento técnico sobre suporte multi-município.
• Localização Fiscal Brasileira no Odoo — o panorama completo da localização.
• ICP-Brasil A1/A3 no Odoo — o certificado também assina a NFS-e.
• Glossário fiscal — ISS, LC 116, ABRASF e os demais termos.