NF-e, NFC-e e NFS-e: guia técnico completo de nota fiscal eletrônica, SPED e conformidade fiscal no Brasil

O sistema fiscal brasileiro é o mais complexo do mundo, e seu ERP precisa lidar com isso

O Brasil tem 3 esferas tributárias (federal, estadual e municipal), 27 legislações estaduais diferentes de ICMS, mais de 5.500 municípios com regras próprias de ISS, e uma sopa de siglas que faria qualquer desenvolvedor estrangeiro questionar suas escolhas de carreira: NF-e, NFC-e, NFS-e, CT-e, MDF-e, SPED, ECD, ECF, EFD-ICMS/IPI, EFD-Contribuições, CFOP, NCM, CST, CSOSN, CEST.

Para empresas que vendem produtos, prestam serviços ou fazem as duas coisas, entender o ecossistema de documentos fiscais eletrônicos não é opcional. É sobrevivência. Um erro de CFOP gera autuação. Uma NF-e rejeitada trava o faturamento. Uma NFS-e com alíquota errada gera passivo tributário que só aparece na fiscalização municipal 3 anos depois.

Esse post é o guia técnico completo: o que é cada documento fiscal eletrônico, como eles se relacionam, quais são os campos críticos e como um ERP deve tratar tudo isso de forma integrada.

Mapa dos documentos fiscais eletrônicos brasileiros

┌─────────────────────────────────────────────────────────┐
│                 DOCUMENTOS FISCAIS ELETRÔNICOS           │
│                                                          │
│  ┌──────────────────┐  ┌──────────────────┐             │
│  │      NF-e         │  │     NFC-e        │             │
│  │  (Nota Fiscal     │  │  (Nota Fiscal    │             │
│  │   Eletrônica)     │  │   Consumidor     │             │
│  │                   │  │   Eletrônica)    │             │
│  │  B2B / remessas   │  │  B2C (varejo)    │             │
│  │  ICMS / IPI       │  │  ICMS            │             │
│  │  SEFAZ estadual   │  │  SEFAZ estadual  │             │
│  └──────────────────┘  └──────────────────┘             │
│                                                          │
│  ┌──────────────────┐  ┌──────────────────┐             │
│  │     NFS-e         │  │      CT-e        │             │
│  │  (Nota Fiscal     │  │  (Conhecimento   │             │
│  │   de Serviço      │  │   de Transporte  │             │
│  │   Eletrônica)     │  │   Eletrônico)    │             │
│  │  ISS municipal    │  │  ICMS frete      │             │
│  │  Prefeitura       │  │  SEFAZ estadual  │             │
│  └──────────────────┘  └──────────────────┘             │
│                                                          │
│  ┌──────────────────┐  ┌──────────────────┐             │
│  │     MDF-e         │  │     NF3-e        │             │
│  │  (Manifesto de    │  │  (Nota Fiscal    │             │
│  │   Documentos      │  │   de Energia     │             │
│  │   Fiscais)        │  │   Elétrica)      │             │
│  │  Transporte       │  │  Concessionárias │             │
│  └──────────────────┘  └──────────────────┘             │
└─────────────────────────────────────────────────────────┘

NF-e: a nota fiscal eletrônica modelo 55

A NF-e é o documento fiscal eletrônico mais importante do Brasil. Emitida em operações de circulação de mercadorias (vendas, transferências, remessas, devoluções) entre empresas (B2B) ou para pessoa física quando não se aplica NFC-e.

Estrutura do XML da NF-e

O XML da NF-e (layout definido pelo Manual de Orientação do Contribuinte, atualmente versão 4.0) contém:

• infNFe: dados da nota (chave de acesso, natureza da operação, série)
• emit: dados do emitente (CNPJ, IE, endereço)
• dest: dados do destinatário
• det: itens da nota (1 a 990 itens por NF-e)
  • prod: dados do produto (código, NCM, CFOP, unidade, quantidade, valor)
  • imposto: tributos por item (ICMS, IPI, PIS, COFINS, II)
• total: totais da nota
• transp: dados de transporte
• cobr: dados de cobrança (duplicatas)
• pag: formas de pagamento
• infAdic: informações adicionais (onde vai o texto legal obrigatório)

Campos que mais causam rejeição

Baseado em dados de produção de sistemas fiscais:

1. NCM (Nomenclatura Comum do Mercosul)

Código de 8 dígitos que classifica o produto. A SEFAZ valida se o NCM existe na tabela vigente. Problemas comuns:

• NCM descontinuado (tabela TIPI muda periodicamente)
• NCM genérico demais (ex: 9999.99.99, usado como coringa, gera fiscalização)
• NCM incompatível com a descrição do produto

2. CFOP (Código Fiscal de Operações e Prestações)

Código de 4 dígitos que identifica a natureza da operação. Existem mais de 500 CFOPs. Os mais usados:

5.102: Venda de mercadoria dentro do estado
6.102: Venda de mercadoria para outro estado
5.405: Venda de mercadoria com ST (substituição tributária)
5.949: Outra saída não especificada
6.949: Outra saída interestadual não especificada
1.102: Compra de mercadoria dentro do estado
2.102: Compra de mercadoria de outro estado
5.901: Remessa para industrialização
5.902: Retorno de industrialização

Erro de CFOP é o erro fiscal mais caro: pode gerar autuação com multa de 100% do imposto mais juros.

3. CST (Código de Situação Tributária) do ICMS

Indica como o ICMS é tributado naquele item:

• 00: Tributada integralmente
• 10: Tributada com cobrança de ICMS-ST
• 20: Com redução de base de cálculo
• 30: Isenta ou não tributada com cobrança de ICMS-ST
• 40: Isenta
• 41: Não tributada
• 60: ICMS cobrado anteriormente por ST
• 70: Com redução de base + ST
• 90: Outros

Para empresas do Simples Nacional, usa-se o CSOSN (101, 102, 103, 201, 202, 203, 300, 400, 500, 900) em vez do CST.

NFC-e: a nota do varejo

A NFC-e (modelo 65) substituiu o cupom fiscal (ECF) na maioria dos estados. É emitida na venda ao consumidor final no PDV (Ponto de Venda).

Diferenças técnicas entre NF-e e NFC-e

Aspecto	NF-e (modelo 55)	NFC-e (modelo 65)
Uso	B2B, remessas	Varejo (B2C)
Identificação do destinatário	Obrigatória	Opcional (CPF na nota)
DANFE	A4 (folha cheia)	Bobina térmica (compacto)
Número de itens	Até 990	Até 990
Contingência	SCAN, SVC, EPEC	Contingência offline
Prazo de cancelamento	24 horas	30 minutos (varia por estado)
QR Code	Não obrigatório	Obrigatório (QR Code + URL de consulta)

Contingência offline da NFC-e

Quando a SEFAZ está fora do ar (ou a internet do estabelecimento cai), o PDV precisa continuar vendendo. A contingência offline funciona assim:

1. PDV detecta que não consegue comunicar com SEFAZ
2. Muda para modo contingência (tpEmis = 9)
3. Gera NFC-e com numeração sequencial e assina com certificado digital local
4. Imprime DANFE com indicação de contingência
5. Quando a comunicação volta, transmite todas as NFC-e em lote
6. SEFAZ autoriza retroativamente (ou rejeita, gerando inutilização)

O prazo para transmissão após retorno da comunicação varia por estado, geralmente 24 horas. Sistemas que não implementam contingência corretamente deixam o caixa travado quando a SEFAZ cai.

NFS-e: a nota fiscal de serviço, o caos municipal

Se a NF-e e NFC-e são relativamente padronizadas (uma SEFAZ por estado, layout nacional), a NFS-e é o oposto. Cada município tem:

• Seu próprio sistema de emissão
• Seu próprio layout de XML (ou não tem XML, alguns ainda usam RPS em texto)
• Sua própria API (ou webservice, ou upload manual de arquivo)
• Suas próprias regras de ISS

O padrão ABRASF

A ABRASF (Associação Brasileira das Secretarias de Finanças das Capitais) criou um padrão nacional para NFS-e, mas a adesão é parcial. Existem várias versões:

• ABRASF 1.0: layout básico, ainda usado em muitos municípios
• ABRASF 2.04: versão mais completa, adotada por parte das capitais
• Padrão Nacional NFS-e (Nota Técnica 2023.004 da Receita Federal): padronização federal que está sendo gradualmente implantada

Além do ABRASF, existem provedores de tecnologia que cada prefeitura contrata, cada um com sua própria API:

• Betha Sistemas (centenas de municípios no Sul)
• IPM Sistemas (interior de SP, MG, RS)
• Ginfes (grandes capitais)
• Simpliss (municípios de médio porte)
• e-Governe (municípios diversos)
• WebISS (ISS.net, várias capitais)

O pesadelo da integração

Um ERP que precisa emitir NFS-e para clientes em todo o Brasil precisa lidar com dezenas de APIs diferentes. A estratégia técnica para isso:

1. Abstração por interface: camada única de emissão no ERP, com adaptadores por município/provedor
2. Gateway fiscal: usar um gateway intermediário (Oobj, Migrate, TecnoSpeed, Focus NFe) que abstrai a complexidade municipal
3. Mapeamento de serviços: cada município tem sua lista de serviços (código LC 116/2003 com desdobramentos locais)

O módulo fiscal da Bradata adota a abordagem de gateway com fallback para integração direta, permitindo cobertura de milhares de municípios sem manter centenas de integrações individualmente.

ICMS: o imposto que ninguém entende completamente

O ICMS é o tributo mais complexo do sistema tributário brasileiro. Cada estado tem sua própria legislação, alíquotas, benefícios fiscais e obrigações acessórias.

Alíquotas interestaduais

Quando uma empresa de SP vende para uma empresa do RJ, a alíquota interestadual depende da origem e destino:

Origem → Destino    | Alíquota
Sul/Sudeste → Sul/Sudeste  | 12%
Sul/Sudeste → N/NE/CO/ES  | 7%
N/NE/CO/ES → qualquer     | 12%
Importados (qualquer)      | 4%

ICMS-ST (Substituição Tributária)

Na substituição tributária, o fabricante ou importador recolhe o ICMS de toda a cadeia (até o consumidor final) antecipadamente. O cálculo envolve:

1. Base de cálculo própria: valor da operação do contribuinte substituto
2. MVA (Margem de Valor Agregado): percentual presumido de margem até o consumidor final (varia por produto e estado)
3. ICMS-ST = (Base x MVA) x Alíquota interna - ICMS próprio

O sistema fiscal precisa manter tabela atualizada de MVAs por NCM e por estado, são milhares de combinações que mudam frequentemente via protocolos ICMS do CONFAZ.

DIFAL (Diferencial de Alíquota)

Desde a EC 87/2015, nas vendas interestaduais para consumidor final não contribuinte, o vendedor recolhe o DIFAL (diferença entre alíquota interna do destino e alíquota interestadual).

Exemplo: empresa de SP vende para pessoa física no BA
- Alíquota interestadual SP→BA: 7%
- Alíquota interna BA: 20,5% (com FCEP)
- DIFAL: 20,5% - 7% = 13,5% (recolhido pelo vendedor via GNRE)

O ERP precisa calcular isso automaticamente, gerar a GNRE (Guia Nacional de Recolhimento de Tributos Estaduais) e incluir na NF-e.

SPED: o ecossistema de escrituração digital

O SPED (Sistema Público de Escrituração Digital) é o guarda-chuva que engloba todas as obrigações acessórias digitais:

EFD-ICMS/IPI (SPED Fiscal)

Arquivo mensal com todas as operações de entrada e saída de mercadorias, apuração de ICMS e IPI. Contém:

• Bloco 0: abertura, identificação, tabelas
• Bloco C: documentos fiscais de mercadorias (NF-e, NFC-e)
• Bloco D: documentos de transporte (CT-e)
• Bloco E: apuração de ICMS e IPI
• Bloco H: inventário físico (obrigatório em fevereiro)
• Bloco K: controle de produção e estoque (obrigatório para indústrias)

EFD-Contribuições

Arquivo mensal com apuração de PIS e COFINS:

• Regime cumulativo (Lucro Presumido): alíquotas de 0,65% (PIS) e 3% (COFINS) sobre receita bruta
• Regime não cumulativo (Lucro Real): alíquotas de 1,65% (PIS) e 7,6% (COFINS) com direito a créditos

ECD (Escrituração Contábil Digital)

Substituiu os livros contábeis em papel: Diário, Razão, Balancetes. Entrega anual.

ECF (Escrituração Contábil Fiscal)

Substituiu a DIPJ. Apuração de IRPJ e CSLL. Entrega anual, vinculada à ECD.

Geração do SPED a partir do ERP

O ERP deve gerar os arquivos SPED automaticamente a partir dos dados já registrados no sistema. Os problemas mais comuns:

• Divergência entre NF-e emitida e SPED: NF-e cancelada que aparece no SPED, ou NF-e autorizada que não aparece
• Créditos de PIS/COFINS não vinculados: entrada de mercadoria sem vínculo com o item de estoque
• Inventário desatualizado: Bloco H com quantidades divergentes do estoque real
• CST de PIS/COFINS inconsistente: item tributado na entrada mas com crédito na saída

Reforma Tributária: o que muda com IBS e CBS

A Reforma Tributária (EC 132/2023) vai substituir gradualmente ICMS, ISS, PIS e COFINS por dois novos tributos:

• CBS (Contribuição sobre Bens e Serviços): federal, substituindo PIS e COFINS
• IBS (Imposto sobre Bens e Serviços): estadual/municipal, substituindo ICMS e ISS

Cronograma de transição

2026: CBS começa a ser cobrada (alíquota teste de 0,9%)
      IBS começa a ser cobrado (alíquota teste de 0,1%)
2027-2028: convivência dos sistemas antigo e novo
2029-2032: redução gradual de ICMS, ISS, PIS, COFINS
2033: extinção completa dos tributos antigos

Impacto nos sistemas

Durante a transição (2026-2033), os ERPs precisam manter os dois sistemas simultaneamente: calcular ICMS/ISS/PIS/COFINS E CBS/IBS para as mesmas operações. Isso dobra a complexidade fiscal por pelo menos 7 anos.

Sistemas que não se prepararem para a convivência dos regimes vão enfrentar sérios problemas de conformidade. A Bradata já está adaptando seu módulo fiscal para suportar o cálculo dual, com motor de regras configurável para o período de transição.

Arquitetura de um módulo fiscal robusto

Um módulo fiscal de ERP que funciona no Brasil precisa de:

Motor de regras tributárias

┌──────────────────────────────────┐
│        Motor de Regras           │
│                                  │
│  Entrada:                        │
│  - Produto (NCM, CEST)          │
│  - Operação (CFOP)              │
│  - Origem (UF, município)       │
│  - Destino (UF, município)      │
│  - Regime tributário emitente    │
│  - Regime tributário destinatário│
│  - Benefício fiscal aplicável   │
│                                  │
│  Saída:                          │
│  - CST ICMS + alíquota + base   │
│  - ICMS-ST (MVA + cálculo)      │
│  - DIFAL (quando aplicável)     │
│  - CST PIS/COFINS + alíquota    │
│  - IPI (quando aplicável)       │
│  - ISS (quando serviço)         │
│  - CBS/IBS (período transição)  │
└──────────────────────────────────┘

Atualização de tabelas legais

O motor de regras depende de tabelas que mudam constantemente:

• Tabela NCM/TIPI: atualizada pela Receita Federal
• Tabela CEST: atualizada pelo CONFAZ
• MVAs por estado: atualizadas por protocolos ICMS
• Alíquotas internas por estado: alteradas por lei estadual
• Benefícios fiscais: convênios CONFAZ, regimes especiais
• Lista de serviços ISS: Lei Complementar 116/2003 + legislação municipal

Manter essas tabelas atualizadas manualmente é humanamente impossível em escala. Sistemas fiscais sérios automatizam a atualização via provedores de conteúdo tributário (IOB, Thomson Reuters, Systax, TaxWeb).

Certificado digital e assinatura de documentos fiscais

Todo documento fiscal eletrônico no Brasil é assinado digitalmente com certificado ICP-Brasil. Os tipos:

• A1: arquivo digital (PFX/P12), validade 1 ano, armazenado no servidor
• A3: token ou cartão criptográfico, validade 3 anos, requer hardware

Para emissão automatizada em servidor (ERP, PDV cloud), o certificado A1 é o padrão. O sistema precisa:

1. Armazenar o certificado de forma segura (vault, HSM ou arquivo protegido)
2. Assinar o XML com algoritmo SHA-256 (obrigatório desde 2018)
3. Monitorar vencimento e renovar antes de expirar
4. Suportar múltiplos certificados (um por filial/CNPJ)

Boas práticas para implementação fiscal em ERP

Lições aprendidas em implementações reais:

1. Nunca hardcodar alíquotas: toda alíquota deve ser parametrizável e vinculada a regra (NCM x UF x operação)

2. Validar XML antes de enviar à SEFAZ: validação local contra XSD economiza 60-80% das rejeições

3. Implementar contingência desde o dia 1: SEFAZ cai. Internet cai. O faturamento não pode parar.

4. Separar motor fiscal do motor de negócio: regras fiscais mudam independentemente do negócio. Acoplamento gera retrabalho.

5. Guardar XML por 5 anos: obrigação legal. Implementar política de retenção e archival desde o início.

6. Testar com todas as UFs: uma NF-e que funciona em SP pode ser rejeitada em BA porque a SEFAZ autorizada é diferente (SVRS, SVAN, etc.)

7. Monitorar rejeições com alertas: rejeição silenciosa é a pior. Dashboard de saúde fiscal com taxa de rejeição por tipo, por UF e por hora.

Conclusão: fiscal digital é infraestrutura, não módulo secundário

No Brasil, o módulo fiscal não é um acessório do ERP. É a fundação. Sem emissão correta de NF-e, NFC-e e NFS-e, a empresa não vende. Sem SPED correto, a empresa toma autuação. Sem preparação para a Reforma Tributária, a empresa vai operar em desconformidade durante 7 anos de transição.

A complexidade é real, mas não é intransponível. Com arquitetura adequada (motor de regras parametrizável, tabelas legais atualizadas automaticamente, validação antes do envio e contingência robusta), é possível transformar o caos fiscal brasileiro em um processo previsível e automatizado. É exatamente esse o objetivo do módulo fiscal que a Bradata desenvolve e mantém em seus sistemas empresariais.