Guia da nota fiscal eletrônica e do sistema fiscal no Brasil em 2026

O que este guia resolve

Documento fiscal no Brasil não é papelada. É a condição para uma mercadoria sair da empresa, para um serviço ser cobrado e para o dinheiro entrar sem susto na porta. Quem constrói ou opera software que emite nota descobre cedo que a parte fiscal é a que mais assusta, a que mais atrasa projeto e a que mais gera multa quando alguém a tratou como detalhe. Escrevi este guia para quem precisa entender o sistema fiscal de verdade, não a versão de folheto.

O conteúdo vem de projetos que entregamos na Bradata, de integrações com SEFAZ de vários estados e de prefeituras que ainda mandam XML por padrões inventados em 2011. Vou tratar do que são NF-e, NFC-e e NFS-e e onde uma termina e a outra começa, da arquitetura de emissão e da conversa com a SEFAZ, das rejeições que mais aparecem, do SPED, do ICMS-ST que derruba a margem de quem não entende, da contingência quando o autorizador cai, da integração com o ERP, do Pix e da conciliação, e da restituição tributária que quase ninguém persegue. É longo. Use os títulos para chegar no que interessa agora.

Os três documentos que você precisa distinguir

A primeira confusão que atrapalha projeto é misturar os três modelos de nota. Eles resolvem coisas diferentes, têm autorizadores diferentes e falham por motivos diferentes.

Documento	Para que serve	Quem autoriza	Layout
NF-e (modelo 55)	Venda de mercadoria entre empresas, circulação de bens	SEFAZ do estado	Nacional, padronizado
NFC-e (modelo 65)	Venda de mercadoria ao consumidor final, varejo, PDV	SEFAZ do estado	Nacional, com QR Code
NFS-e	Prestação de serviço	Prefeitura do município	Municipal, fragmentado

A NF-e é a mais madura. Padrão nacional, layout estável, autorizador estadual que na maioria dos estados funciona bem. A NFC-e é a irmã do varejo, pensada para o balcão, com QR Code para o consumidor consultar e regras de contingência mais rígidas porque a venda não pode parar quando a internet cai. A NFS-e é o pesadelo histórico. Cada prefeitura fez a sua, com o seu padrão, o seu webservice e a sua regra. Quem emite serviço em cem municípios integra, na prática, com dezenas de sistemas diferentes.

Existe um esforço nacional de padronização da NFS-e, com um sistema nacional e um layout único, e ele avança. Mas a realidade de 2026 ainda é híbrida: parte dos municípios migrou, parte não, e o software precisa suportar os dois mundos ao mesmo tempo. Se você quer o panorama completo de como esses três documentos se encaixam num sistema digital e num ERP, tratei disso em detalhe em NF-e, NFC-e e NFS-e no fiscal digital do ERP brasileiro. Este guia assume que as fronteiras entre os três estão claras.

Como a emissão funciona por dentro

Emitir uma nota parece um botão. Por dentro é uma sequência de etapas que precisa acontecer na ordem certa, e cada uma pode falhar.

O ciclo de uma NF-e é mais ou menos assim. O sistema monta um XML com todos os dados da operação: emitente, destinatário, produtos, impostos, valores. Assina esse XML com o certificado digital da empresa, um A1 em arquivo ou um A3 em token. Envia para o webservice da SEFAZ do estado. A SEFAZ valida centenas de regras e responde com autorização ou rejeição. Se autorizou, devolve um protocolo e a nota passa a existir juridicamente. O sistema então gera o DANFE, a representação em PDF que acompanha a mercadoria, e guarda o XML autorizado, que é o documento fiscal de verdade.

Parece simples até você contar os pontos de falha. O certificado pode estar vencido. O XML pode ter um campo fora do padrão. A SEFAZ pode estar fora do ar. A regra tributária do produto pode estar errada e a nota volta rejeitada. Cada um desses casos precisa de tratamento próprio, e é aqui que projeto amador quebra.

A arquitetura que sustenta emissão em volume tem características que valem descrever. Ela é assíncrona: o usuário clica em emitir e o sistema enfileira, porque a SEFAZ pode demorar segundos ou minutos para responder e travar a tela seria inaceitável. Ela é idempotente: se a mesma nota for enviada duas vezes por um erro de rede, o sistema não pode gerar duas notas. Ela guarda tudo: cada XML enviado, cada resposta recebida, cada tentativa, porque o fisco pode pedir qualquer coisa cinco anos depois. Desenhei o passo a passo dessa arquitetura, incluindo fila, retentativa e tratamento de erro, em pipeline de NF-e com SEFAZ: arquitetura e rejeições. Quem vai construir emissão própria deveria ler antes de escrever a primeira linha.

As rejeições que mais aparecem

A SEFAZ rejeita nota por centenas de motivos, cada um com um código. A maioria dos projetos apanha sempre dos mesmos. Vale conhecer os campeões porque eles concentram o volume de dor.

Código	O que diz	Causa comum
217	NF-e não consta na base da SEFAZ	Consulta antes da autorização terminar
204	Duplicidade de NF-e	Reenvio sem controle de idempotência
539	Duplicidade com diferença na chave	Numeração ou série mal controlada
225	Falha no schema do XML	Campo fora do layout, caractere inválido
233	Inscrição estadual do destinatário inválida	Cadastro desatualizado do cliente
999	Erro não catalogado no autorizador	Instabilidade da própria SEFAZ

A lição que se repete: a maioria das rejeições nasce de dado ruim, não de código ruim. Cadastro de cliente errado, NCM incorreto, CFOP que não bate com a operação, inscrição estadual desatualizada. Um sistema fiscal sério valida o máximo possível antes de enviar, para descobrir o erro na sua base e não no autorizador, onde o custo de descobrir é maior e a fila anda mais devagar.

Rejeição 999 e o grupo dos erros de instabilidade merecem atenção porque não são culpa sua. A SEFAZ cai, fica lenta, retorna erro genérico. O sistema precisa de retentativa com espera crescente e, quando a indisponibilidade se prolonga, de contingência, que tratamos adiante. Tratar rejeição 999 como se fosse erro de dado é queimar tempo procurando problema onde não há.

SPED: a nota é só o começo

Emitir a nota resolve o momento da operação. O SPED resolve a prestação de contas ao fisco sobre tudo que aconteceu. É a Escrituração Pública Digital, um conjunto de obrigações que a empresa entrega periodicamente e que consolida o que ela movimentou.

Os blocos que mais importam para quem opera:

O SPED Fiscal, ou EFD ICMS/IPI, é a apuração mensal de ICMS e IPI. Ele consolida todas as notas de entrada e saída, calcula o imposto devido e é cruzado pelo fisco com o que os seus fornecedores e clientes declararam. Divergência aqui gera malha fiscal.

O SPED Contribuições, ou EFD Contribuições, faz o mesmo para PIS e COFINS. É onde a complexidade do regime tributário aparece, porque cumulativo e não cumulativo mudam completamente a conta.

A ECD e a ECF são as escriturações contábil e fiscal anuais, mais ligadas ao balanço e ao IRPJ e CSLL.

O ponto que muita empresa erra: o SPED não é gerado no fim do mês do nada. Ele é a consolidação de dados que precisam estar corretos o ano inteiro. Se o CFOP da nota está errado, se o CST do imposto está trocado, o erro entra na nota em janeiro e explode no SPED que fecha o período. Sistema fiscal bem construído trata a nota e o SPED como partes do mesmo fluxo, não como duas ilhas que alguém reconcilia no fim do mês.

Um número honesto de campo: a camada fiscal, somando emissão, SPED e apuração, costuma consumir de 20% a 35% do esforço de um ERP sob medida no Brasil. Não é exagero de fornecedor, é o preço de operar sob esta legislação. Quem orça um sistema com faturamento e ignora esse peso vai estourar prazo.

ICMS-ST: onde a margem some sem aviso

Se existe um assunto que derruba a margem de quem não entende, é a substituição tributária do ICMS. A ideia é simples de descrever e brutal de operar. Em vez de cada elo da cadeia recolher o ICMS sobre a sua parte, um elo, geralmente o fabricante ou o importador, recolhe antecipadamente o imposto de toda a cadeia até o consumidor final. É o ICMS-ST.

O problema para o software é triplo. Primeiro, saber se o produto está sujeito a ST, o que depende do NCM, do estado de origem, do estado de destino e de convênios que mudam. Segundo, calcular a base de ST, que usa uma margem de valor agregado, a MVA, definida por produto e por estado, às vezes ajustada quando a operação cruza fronteira. Terceiro, tratar os casos de restituição e complemento quando o preço presumido do cálculo não bate com o preço real da venda.

Um exemplo concreto de como isso morde. Uma empresa compra um produto com ICMS-ST já recolhido pelo fornecedor. Ela paga esse imposto embutido no custo. Se depois vende esse produto para outro estado, ou para consumidor final por um preço menor que a base presumida, ela pode ter direito a restituir parte do ICMS-ST pago a mais. A maioria das empresas nunca reclama esse valor, porque não tem sistema que rastreie a diferença entre o imposto presumido e o imposto efetivo. É dinheiro parado no caixa do estado.

Nós construímos um SaaS que faz exatamente esse rastreamento e recupera crédito de ICMS-ST e de outros tributos pagos a mais. Contei os números e o método em o caso do SaaS de restituição tributária. O ponto que vale guardar aqui: ST mal tratada no sistema não é só risco de multa, é margem que evapora sem ninguém perceber. E a recuperação, quando bem feita, paga o projeto.

Contingência: quando o autorizador cai

A SEFAZ vai cair. Não é hipótese, é certeza estatística ao longo de um ano de operação. A pergunta que separa o sistema sério do amador é o que acontece com a venda quando o autorizador não responde.

Para NF-e e NFC-e existem modos de contingência previstos em lei. Os principais:

A EPEC, Evento Prévio de Emissão em Contingência, permite registrar que a nota foi emitida em contingência e transmitir depois, quando a SEFAZ voltar. É o modo mais usado para NF-e.

A contingência offline da NFC-e permite ao PDV continuar vendendo mesmo sem resposta do autorizador, gerando a nota com uma numeração de contingência e transmitindo em lote quando a conexão volta. Sem isso, o caixa do supermercado para quando a internet cai, o que é inaceitável.

A SVC, SEFAZ Virtual de Contingência, é um autorizador alternativo que assume quando o autorizador principal do estado está fora. O sistema aponta para a SVC e a emissão continua.

O erro comum é construir emissão sem contingência e descobrir o buraco no primeiro dia de queda da SEFAZ, geralmente numa data de pico como fechamento de mês. Contingência não é funcionalidade opcional, é parte do desenho desde o começo. Um sistema que só emite quando a SEFAZ está de bom humor não está pronto para produção.

Integração com o ERP: a nota não vive sozinha

A nota fiscal é o desfecho de um processo que começou antes: um pedido de venda, uma saída de estoque, um contas a receber que vai nascer. Emitir nota num sistema isolado do ERP é criar mais uma ilha, e o problema das ilhas é que alguém reconcilia à mão.

Num ERP bem integrado, a emissão da nota é um efeito do faturamento, não um ato separado. O pedido de venda vira nota, a nota baixa o estoque, gera o recebível no financeiro, alimenta a apuração fiscal e entra no SPED do período. Tudo num fluxo, sem redigitação. Quando a nota é rejeitada, o pedido não avança, o estoque não baixa errado, o financeiro não lança um recebível de uma venda que não existe.

Quem já tem um ERP e quer acoplar emissão própria precisa que o ERP exponha uma API ou pelo menos um ponto de integração confiável. Quem constrói do zero tem a chance de desenhar o fiscal integrado desde a fundação, que é o caminho mais limpo. Se a sua operação tem fiscal complexo, múltiplos estados, ST pesada e muitas NFS-e municipais, o parceiro que você escolher precisa dominar essa camada, não improvisar. Um ERP sob medida com fiscal completo é justamente o tipo de projeto onde essa integração nasce certa em vez de ser remendada depois.

Pix, cobrança e conciliação

A nota diz o que foi vendido. O recebimento diz se o dinheiro entrou. Ligar os dois é o que fecha o ciclo financeiro, e é onde muita empresa ainda perde tempo com conferência manual.

O Pix mudou a cobrança no Brasil. Um recebível gerado pela nota pode virar um Pix com QR Code dinâmico, com identificador único, que quando pago é reconhecido automaticamente e baixa o título no financeiro sem ninguém conferir extrato. A diferença de eficiência é grande: em vez de uma pessoa cruzando pagamentos com boletos numa planilha, o sistema concilia sozinho pelo identificador. Descrevi como montar essa integração, incluindo o webhook de confirmação e a baixa automática, em Pix integrado ao ERP para cobrança e conciliação.

A conciliação bancária mais ampla, que vai além do Pix e cobre todo o extrato da conta, ganhou uma ferramenta poderosa com o Open Finance. Em vez de importar OFX manualmente ou digitar lançamentos, o sistema puxa o extrato via API do banco e casa cada movimento com o lançamento correspondente no ERP. O que sobra sem par é o que merece atenção humana. Tratei da arquitetura dessa automação em conciliação bancária com Open Finance no ERP. O ganho não é só tempo, é confiança no caixa: uma empresa que concilia automático sabe o saldo real todo dia, não uma vez por semana quando alguém tem paciência.

Compliance fiscal na prática

Compliance fiscal não é um documento na gaveta, é um conjunto de comportamentos que o sistema precisa sustentar. Alguns pilares que separam a empresa tranquila da que vive com medo de auditoria.

Guarda de documentos. O XML autorizado é o documento fiscal, não o PDF. Ele precisa ser guardado por cinco anos, íntegro, recuperável. Sistema que guarda só o DANFE e perde o XML está descumprindo a lei sem saber.

Cruzamento e conferência. O fisco cruza a sua nota com a do seu fornecedor e a do seu cliente. Se você declarou uma entrada que o fornecedor não declarou como saída, cai na malha. Sistema que confere antes de fechar o período evita a surpresa.

Cadastros corretos. NCM, CFOP, CST, CEST, origem da mercadoria. Esses códigos definem o imposto. Cadastro errado gera imposto errado, que gera nota errada, que gera SPED errado, que gera multa. A qualidade do cadastro é a base de tudo.

Rastreabilidade. Toda alteração fiscal precisa deixar rastro. Quem mudou a regra tributária de um produto, quando, por quê. Numa auditoria, a diferença entre explicar e apanhar é ter esse log.

A pergunta honesta que todo gestor deveria fazer ao seu sistema fiscal: se o fisco pedir hoje o XML de uma nota emitida há três anos, com todas as tentativas, a resposta da SEFAZ e o registro de quem a emitiu, o sistema entrega em minutos ou a resposta é um encolher de ombros? Essa é a medida real de compliance.

Quanto custa uma camada fiscal bem feita

Não cabe em tabela fechada, mas dá para dar faixas honestas. Construir emissão própria de NF-e e NFC-e, com contingência, tratamento de rejeição e integração ao ERP, é um projeto de meses, não de semanas. Somar NFS-e multiplica o trabalho pelo número de padrões municipais que você precisa suportar. Somar SPED e apuração completa adiciona outra frente relevante.

Escopo fiscal	O que inclui	Faixa de esforço
Básico	NF-e com contingência e rejeições	Poucos meses de uma equipe pequena
Intermediário	NF-e, NFC-e, SPED Fiscal, apuração de ICMS	Meio ano ou mais
Completo	Tudo acima, NFS-e multi-município, ST, Contribuições	Frente contínua, parte central do ERP

A alternativa a construir é usar um provedor de emissão pronto, uma API de terceiros que cuida da conversa com a SEFAZ. Faz sentido para quem quer emitir rápido sem dominar a complexidade. A troca é depender de terceiro, pagar por nota e ter menos controle sobre casos de borda. Empresa com volume alto e fiscal complexo costuma migrar para emissão própria com o tempo, pelo custo por nota e pelo controle. Não existe resposta única, existe o seu volume e a sua complexidade.

Perguntas frequentes

Qual a diferença prática entre NF-e, NFC-e e NFS-e? NF-e (modelo 55) é para venda de mercadoria entre empresas e circulação de bens, autorizada pela SEFAZ estadual. NFC-e (modelo 65) é a nota do consumidor final no varejo, com QR Code e regras de contingência mais rígidas para o PDV não parar. NFS-e é para serviço, autorizada pela prefeitura, e é a mais fragmentada porque cada município teve o seu padrão. A padronização nacional da NFS-e avança, mas em 2026 o cenário ainda é híbrido.

Por que minha nota é rejeitada com tanta frequência? Na maioria dos casos, por dado ruim e não por erro de sistema. Cadastro de cliente desatualizado, NCM incorreto, CFOP que não bate com a operação, inscrição estadual inválida. Um sistema fiscal sério valida o máximo antes de enviar para descobrir o erro na própria base. Rejeições do grupo 999 são exceção: costumam ser instabilidade da SEFAZ e pedem retentativa, não correção de dado.

Preciso guardar o PDF ou o XML da nota? O XML autorizado. Ele é o documento fiscal juridicamente válido e precisa ser guardado íntegro por cinco anos. O DANFE em PDF é apenas a representação visual que acompanha a mercadoria. Sistema que guarda só o PDF e perde o XML está em situação irregular, mesmo sem saber.

O que é ICMS-ST e por que ele afeta minha margem? Substituição tributária é quando um elo da cadeia, em geral o fabricante ou importador, recolhe antecipadamente o ICMS de toda a cadeia até o consumidor. O software precisa saber se o produto está sujeito a ST, calcular a base com a MVA correta por estado e tratar restituição quando o preço real fica abaixo do presumido. Empresa sem sistema que rastreie essa diferença deixa crédito parado no caixa do estado.

O que acontece com minhas vendas quando a SEFAZ cai? Se o sistema tem contingência, as vendas continuam. NF-e usa EPEC ou a SEFAZ Virtual de Contingência. NFC-e usa contingência offline, gerando a nota localmente e transmitindo em lote quando a conexão volta. Sem contingência desenhada desde o começo, o faturamento para junto com o autorizador, o que é inaceitável em varejo.

Vale mais construir emissão própria ou usar uma API de terceiros? Depende do volume e da complexidade. API pronta faz sentido para emitir rápido sem dominar a legislação, com a troca de pagar por nota e depender de terceiro. Emissão própria compensa em volume alto e fiscal complexo, pelo custo por nota e pelo controle sobre casos de borda. Muitas empresas começam com API e migram para emissão própria conforme crescem.

Fechamento

A camada fiscal é a que mais afunda projeto de software no Brasil, e quase sempre porque alguém a tratou como detalhe que se resolve no fim. Ela não se resolve no fim. Nota, contingência, SPED, ST e conciliação são um sistema só, e precisam ser desenhados juntos desde o dia um. O sistema que valida antes de enviar, guarda tudo, aguenta a SEFAZ cair e concilia sozinho o recebimento é o que deixa o gestor dormir. O que trata fiscal como enfeite é o que gera a multa que aparece três anos depois.

Se você precisa de emissão fiscal que aguenta volume, trata rejeição de verdade e vive integrada ao seu ERP, a Bradata já construiu pipelines de NF-e com SEFAZ, SaaS de restituição tributária e integrações de Pix e Open Finance. Fale com a gente para uma conversa técnica, sem folheto.