01
Contexto
Resumo do que muda a partir de 2026 e como o período de teste/adaptação afeta contratos de aplicação, persistência de dados e conciliação.
Resumo técnico
- • Documentos fiscais viram fonte operacional de dados: CBS/IBS/IS entram no XML, na DPS, nos eventos e na apuração assistida.
- • Fiscal e financeiro ficam acoplados: Split Payment conecta nota, pagamento, baixa, estorno e fluxo de caixa.
- • Cadastros deixam de ser apoio: cClassTrib, CST, destino, benefício e regime passam a determinar comportamento transacional.
Linha do tempo que sistemas precisam suportar
| Fase | Tema | O que muda | Impacto na aplicação |
|---|---|---|---|
| 2026 H1 | Inventário e desenho de arquitetura | Mapear pontos que calculam preço, imposto, nota, recebimento, crédito e apuração. | Criar backlog por dominio: ERP, fiscal, pricing, checkout, pagamentos, financeiro, data/BI e integracoes. |
| 2026 | Ano de teste e adaptação CBS/IBS | DF-e deve destacar CBS e IBS conforme notas técnicas; foco oficial é validação de modelos digitais e obrigações acessórias. | Sistemas precisam gerar XML/JSON novos, persistir bases/valores e reconciliar o que foi emitido com a apuracao assistida. |
| 2027 | CBS plena e faseamento do Split Payment | CBS substitui PIS/Cofins; Split Payment avança de forma gradual conforme regulamentação, arranjos de pagamento e capacidade técnica. | Checkout, contas a receber, conciliacao bancaria e ledger precisam trabalhar com valor bruto, tributo segregado e valor liquido recebido. |
| 2029-2032 | Transição gradual do IBS | ICMS/ISS convivem com IBS em percentuais progressivos, exigindo dois modelos em paralelo. | Tax engine e contabilidade precisam suportar convivencia, rateio por destino, creditos e relatorios comparativos. |
| 2033 | Novo modelo pleno | IBS substitui integralmente ICMS/ISS e o legado deixa de ser caminho principal. | Desativacao controlada de regras antigas, limpeza de cadastros e consolidacao do modelo operacional definitivo. |
| Fonte | Tema | Uso no playbook |
|---|---|---|
| Receita Federal | Orientações para 2026 | Obrigações acessórias, DF-e com CBS/IBS, DeRE, plataformas digitais e ano de teste. |
| Receita Federal | Período de adaptação e multas | Evita tom alarmista: 2026 é período de teste/adaptação e orientação antes de punição. |
| Ministério da Fazenda | Regulamento CBS/IBS | Apuração assistida, documentos padronizados, regras uniformes e centralização da apuração. |
| Avalara Brasil | Descomplica Reforma Tributária | Benchmark editorial sobre cálculo de tributos, Split Payment, GTIN e TCO de conformidade. |
| NT 2025.002 / NF-e | Grupos UB, W03, CST e cClassTrib | Base técnica para impactos em NF-e/NFC-e e contratos de documento fiscal. |
Em 2026, os campos podem não bloquear tecnicamente todas as emissões no início, mas a obrigação legal e a necessidade de persistir os dados já afetam contratos de aplicação e conciliação.
02
Aplicações impactadas
Domínios de sistema que precisam ser inventariados antes de alterar schemas ou regras: fiscal, financeiro, cadastro, pricing, checkout, integrações e dados.
Aplicações que normalmente quebram primeiro
| Área | Estado comum hoje | O que muda | Risco | Modernização recomendada |
|---|---|---|---|---|
| Motor tributario / Tax Engine | Regras espalhadas em ERP, fiscal, pricing, NCM, CFOP e parametrizacoes por UF/municipio. | CBS, IBS e IS exigem calculo item a item, base por fora, creditos amplos, regimes especificos e classificacao tributaria dinamica. | Risco de inconsistência entre pedido, nota, financeiro e apuração assistida. | Centralizar regras em um servico versionado, com parametros datados e explicabilidade por item. |
| Emissor fiscal / DF-e | Layouts existentes para NF-e, NFC-e, CT-e, NFS-e e documentos setoriais. | Novos grupos IBS/CBS/IS, novos totalizadores, eventos e informacoes de partilha/creditos. | Documento autorizado tecnicamente pode ainda ficar inconsistente com obrigação acessória ou apuração. | Separar geracao fiscal de regra tributaria; versionar schemas e aceitar convivencia de layouts. |
| Cadastro de produtos, servicos e clientes | NCM, servico, CFOP, CST e beneficios fiscais mantidos como cadastro operacional. | GTIN quando aplicável, cClassTrib, CST CBS/IBS, indicativos ZFM/ALC, benefícios, destino e tipo de consumidor ganham centralidade. | Risco de classificação fiscal incorreta em escala, especialmente em e-commerce, marketplace e PDV. | Criar governanca de catalogo fiscal com validade, origem da regra, workflow de aprovacao e auditoria. |
| Pricing, quote e checkout | Preco geralmente tratado como valor final com impostos embutidos e pouca separacao fiscal em tempo real. | Base por fora, destaque individualizado e Split Payment mudam o que o cliente ve, paga e o que entra liquido no caixa. | Margem, desconto, frete, cupom e parcelamento calculados sobre bases erradas. | Expor preco bruto, tributos, valor liquido e efeitos de credito/beneficio no mesmo contrato de calculo. |
| Pagamentos e contas a receber | Pagamento, nota e conciliacao muitas vezes sao reconciliados em batch. | Split Payment vincula documento fiscal à transação financeira quando aplicável; parte do tributo pode ser segregada na liquidação. | Risco de divergência entre liquidação, baixa, estorno, devolução e apuração tributária. | Modelo de conciliacao event-driven com idempotencia, status por transacao e trilha completa. |
| Contabilidade, ledger e apuracao | Fechamento mensal com conciliacoes manuais e ajustes por planilhas ou relatórios de ERP. | Apuracao assistida consolida debitos e creditos a partir de documentos e registros fiscais. | Ledger interno nao bate com apuracao preliminar do Fisco; ajustes manuais viram rotina. | Criar sub-ledger fiscal por item/documento, conciliacao automatica e divergencia explicavel. |
| Integracoes B2B, marketplace e plataformas digitais | Contratos legados de EDI/API trocam XMLs, pedidos e pagamentos sem todos os campos fiscais novos. | Plataformas digitais terão obrigações específicas quando os leiautes forem disponibilizados; marketplaces, sellers e PSPs precisam preparar contratos. | Risco de incompatibilidade entre seller, marketplace, ERP, gateway e fiscos. | Versionar APIs externas, criar schema registry fiscal e estrategia de compatibilidade por parceiro. |
| Dados, BI e auditoria | Dado fiscal usado mais para obrigacao acessoria do que para operacao em tempo real. | Dados fiscais passam a alimentar apuracao assistida, controle de creditos, caixa e auditoria operacional. | Indicadores de receita, margem e caixa inconsistentes entre financeiro, fiscal e BI. | Modelo analitico com granularidade por item, documento, pagamento, credito e evento. |
Ponto de controle recomendado: registrar, para cada domínio, qual sistema calcula, transforma ou persiste valores fiscais.
Evidência esperada: inventário com owner, contrato de dados, campos obrigatórios, sistemas consumidores e data de vigência da regra.
03
Arquitetura de referência
Fluxo recomendado para manter pedido, cálculo, documento fiscal, pagamento, ledger e apuração consistentes durante a transição.
Fluxos que mudam de forma estrutural
| Fluxo | Antes | Depois | Sistemas envolvidos |
|---|---|---|---|
| Pedido -> precificacao -> nota -> pagamento | Fluxo linear com impostos embutidos, baixa financeira posterior e apuracao em batch. | Fluxo fiscal-financeiro acoplado: calculo CBS/IBS/IS, documento com destaque, pagamento com possivel split e conciliacao por evento. | E-commerce, ERP, tax engine, emissor fiscal, gateway/PSP, contas a receber. |
| Servico -> DPS/NFS-e -> municipio/ambiente nacional | Municipios com padroes diferentes, integracoes especificas por prefeitura. | Padrao nacional NFS-e/DPS com grupos IBSCBS e integracao ao ambiente nacional. | Sistema de servicos, billing, NFS-e, prefeitura/ambiente nacional, contabilidade. |
| Compra -> credito -> apuracao | Credito tributario depende de regras de PIS/Cofins/ICMS/ISS e conciliacao manual. | Credito amplo de CBS/IBS exige rastreabilidade por documento, item, fornecedor e pagamento. | Procurement, fiscal inbound, contas a pagar, ledger, data lake fiscal. |
| Cancelamento/devolucao -> estorno fiscal/financeiro | Eventos fiscais e estornos financeiros tratados por rotinas separadas. | Evento fiscal precisa reconciliar tributo destacado, credito, split e valor liquido. | OMS, ERP, emissor fiscal, PSP, financeiro e atendimento. |
Arquitetura alvo para convivência 2026-2033
+-------------+ +-------------+ +---------------+
| Pedido/Cart | ---> | Tax Engine | ---> | Emissor DF-e |
+-------------+ +-------------+ +---------------+
| | |
v v v
+-------------+ +-------------+ +---------------+
| PSP/Gateway | ---> | AR/Ledger | ---> | Apuracao/Fisco|
+-------------+ +-------------+ +---------------+
| | |
+--------------------+--------------------+
v
Data Lake fiscal auditavel
Decisão de arquitetura
- • Centralize o contrato de cálculo: preço, desconto, frete, destino e tributos precisam ter uma única resposta explicável.
- • Versione por vigência: regra tributária não é deploy único; é dado regulatório com data de início e fim.
- • Projete convivência: o legado e o novo modelo vão rodar juntos por anos.
04
Cálculo tributário
Mudanças no cálculo que afetam tax engine, pricing, invoice preview, contratos de API e persistência por item.
O que muda no cálculo da aplicação
| Dimensão | O que muda | Impacto na aplicação |
|---|---|---|
| Base por fora | O imposto deixa de compor sua propria base como no modelo atual em varias situacoes. | Pricing e invoice preview precisam recalcular bruto, liquido, desconto, frete e tributos no mesmo contrato. |
| Tributacao no destino | IBS depende do local de destino/consumo e da partilha entre entes. | Endereco, municipio, UF, consumidor final e tipo de operacao viram inputs obrigatorios do calculo. |
| Credito amplo | Credito tende a ser financeiro e mais amplo, mas depende de documento e pagamento rastreaveis. | Contas a pagar, fiscal inbound e ledger precisam expor credito por item/documento/fornecedor. |
| Regimes especificos | Financeiro, saude, seguros, hotelaria, combustiveis, monofasicos e outros possuem regras proprias. | Tax engine precisa suportar plugins/regra por setor e nao apenas tabela simples por NCM/servico. |
| Imposto Seletivo | IS incide sobre bens/servicos especificos e adiciona outra camada de classificacao. | Catalogo de produto precisa indicar sujeicao ao IS, vigencia, base e excecoes. |
O contrato de cálculo deve retornar valores por item, regra aplicada, vigência da regra e explicação suficiente para auditoria e atendimento.
05
Documentos fiscais eletrônicos
DF-e listados pela Receita e leiautes que passam a carregar CBS/IBS conforme notas técnicas. O ponto é preparar contratos de dados, não apenas telas de emissão.
Documentos e contratos fiscais impactados
| Documento | Novos campos | Mudança na aplicação | Owner |
|---|---|---|---|
| NF-e / NFC-e | Grupo UB (IBS/CBS/IS por item), totalizadores W03 e tabelas CST/cClassTrib conforme NT 2025.002. | Atualizar emissor, validadores, armazenamento XML, DANFE/representacao e integracoes downstream. | ERP / Fiscal / PDV |
| NFS-e / DPS nacional | Grupo IBSCBS, codigos nacionais, indicativos como ZFM/ALC e regras de ambiente nacional quando aplicáveis. | Suportar emissor proprio ou ambiente nacional, APIs Sefin/ADN e convivencia municipal. | Billing / Servicos / Fiscal |
| CT-e / CT-e OS | Destaque CBS/IBS em transporte e ajustes de totalizacao. | Atualizar TMS, calculo de frete, documentos vinculados e integracoes com embarcadores. | Logistica / TMS |
| NFCom / NF3e / BP-e | Campos CBS/IBS e regras por setor regulado. | Adaptar plataformas setoriais e contratos com reguladores/operadoras. | Telecom / Energia / Transporte |
| DeRE e declaracoes de regimes especificos | Layouts especificos para setores financeiros, saude, seguros, consorcios e outros. | Criar nova camada declaratoria e reconciliar com operacoes sem documento fiscal tradicional. | Fiscal / Compliance / Produto |
Nota autorizada não significa sistema correto
A flexibilização inicial de validações técnicas não elimina a obrigação legal. Isso cria um risco novo: documentos podem passar pelo autorizador, mas ainda assim gerar não conformidade, divergência de apuração e retrabalho operacional.
06
Cadastros e tabelas fiscais
Campos cadastrais que passam a influenciar diretamente a operação: produto, serviço, cliente, fornecedor e tabelas regulatórias.
Cadastros que passam a governar comportamento transacional
| Dado | Campos críticos | Falha típica |
|---|---|---|
| Produto / SKU | GTIN quando aplicável, NCM, cClassTrib, sujeicao a IS, beneficio fiscal, monofasico, cBenef. | SKU novo sem classificacao correta pode gerar divergencia de imposto, rejeicao ou ajuste posterior. |
| Servico | Codigo nacional, DPS, municipio de incidencia, prestador/tomador, regime especial. | NFS-e emitida com municipio ou codigo incorreto quebra apuracao assistida. |
| Cliente / tomador | CNPJ/CPF, inscricoes, endereco destino, contribuinte, consumidor final, ZFM/ALC. | Regra de destino e beneficio aplicada errado no checkout ou nota. |
| Fornecedor | Regime tributario, regularidade, documentos recebidos, pagamento confirmado. | Credito tributario nao aproveitado ou bloqueado por falta de rastreabilidade. |
| Tabela fiscal | CST CBS/IBS, aliquotas, reducoes, diferimentos, vigencia, fonte normativa. | Atualizacao de tabela sem versao gera comportamento diferente entre ambientes. |
Ponto de controle recomendado: simular jornadas com variação de cadastro fiscal, destino, benefício e regime.
Evidência esperada: o mesmo item produz resultado consistente em pricing, documento fiscal, pagamento, ledger e apuração assistida.
07
Pagamentos e Split Payment
Split Payment deve ser tratado como integração fiscal-financeira faseada, não como obrigação universal instantânea para todos os fluxos.
Como Split Payment muda produto e financeiro
| Área | Impacto | Arquitetura necessária |
|---|---|---|
| Checkout e pedido | Pedido precisa guardar bruto, imposto estimado, liquido, meio de pagamento e documento fiscal vinculado para cenários com segregação. | Contrato unico entre pricing, tax engine e pagamento. |
| Gateway / PSP | Transacao precisa estar preparada para carregar identificadores fiscais e receber retorno de segregacao quando o modelo for aplicável. | Callbacks idempotentes, retentativa, status granular e assinatura/verificacao. |
| Contas a receber | Baixa financeira pode deixar de ser igual ao valor total da nota quando houver segregação do tributo na liquidação. | Ledger com bruto, tributo retido, liquido, tarifas e divergencias. |
| Tesouraria | Capital de giro pode mudar porque parcela do tributo deixa de ficar temporariamente disponível no caixa. | Forecast de caixa com cenarios de split, parcelamento e estorno. |
| Atendimento e refund | Cancelamentos e devolucoes precisam estornar fiscal e financeiro de forma sincronizada. | Orquestrador de devolucao com compensacao fiscal e conciliacao automatica. |
Impacto real: caixa e conciliação
- • O valor que entra no caixa pode ser menor que o total da nota.
- • Parcelamento, devolução parcial, cancelamento e chargeback precisam carregar efeito fiscal.
- • Cada transação precisa ser reconciliável por documento, parcela, tributo, tarifa e valor líquido.
08
Integrações e contratos de API
Contratos internos e externos que precisam receber novos campos fiscais, eventos e identificadores reconciliáveis.
Contratos de integração que precisam mudar
| Contrato | Campos / eventos novos | Versionamento recomendado |
|---|---|---|
| ERP -> emissor fiscal | item.cClassTrib, item.CST, IBS/CBS base, aliquota, valor, IS, destino. | Versionar por NT e data de vigencia; aceitar campos opcionais/obrigatorios por fase. |
| E-commerce -> tax engine | sku, consumidor, endereco destino, cupom, frete, canal, marketplace, data da operacao. | Resposta explicavel com bruto/liquido/tributos por item e regra aplicada. |
| ERP -> PSP/gateway | id documento fiscal, valor CBS, valor IBS, valor IS, valor liquido, transacao original. | Idempotencia e callbacks de confirmacao/erro/estorno. |
| ERP -> data warehouse | documento, item, tributo, credito, pagamento, estorno, evento, divergencia. | Modelo analitico append-only para auditoria e reprocessamento. |
| Marketplace -> seller | responsavel tributario, seller, documento, split, comissao, repasse, devolucao. | Contrato por seller e por regime, com convivencia legado/novo. |
Sistemas que já possuem API versionada e schema registry fiscal vão sofrer menos. Quem troca XML e CSV sem contrato formal vai descobrir o impacto quando parceiros começarem a mandar campos novos.
09
Operação em produção
Sinais de divergência concretos para operação: pedido x nota, nota x pagamento, cadastro x cálculo e nota x apuração assistida.
Sinais operacionais que precisam virar painel
| Sinal | Por que importa | Dono |
|---|---|---|
| Documentos sem campos CBS/IBS | Obrigacao legal pode existir mesmo sem rejeicao tecnica imediata. | Fiscal Platform |
| Divergencia pedido x nota | Pricing e tax engine podem aplicar regras diferentes. | Commerce Platform |
| Divergencia nota x pagamento | Split Payment altera baixa e valor liquido recebido. | Payments / AR |
| Divergencia nota x apuracao assistida | O Fisco consolida debitos/creditos a partir dos documentos. | Fiscal / Accounting |
| Cadastros fiscais vencidos | Tabela cClassTrib/CST/beneficios muda por vigencia. | Master Data |
| Filas de contingencia fiscal | SEFAZ, NFS-e nacional ou PSPs podem falhar e impactar emissão, recebimento ou conciliação. | SRE / Fiscal Ops |
Ponto de controle recomendado: comparar continuamente pedido, documento fiscal, pagamento, cadastro e apuração.
Evidência esperada: divergências abertas por tipo (cálculo, cadastro, documento, split, baixa, apuração), com payloads e eventos rastreáveis.
10
Roadmap de adaptação
Sequência prática para preparar sistemas existentes: inventário, cálculo central, documentos, Split Payment, convivência e operação.
Roadmap de modernização por fases
| Fase | Janela típica | Entregável |
|---|---|---|
| 1. Inventariar fluxos | 2-4 semanas | Mapa de aplicacoes, contratos, donos e jornadas fiscais criticas. |
| 2. Separar tax engine | 4-8 semanas | Contrato unico de calculo tributario com explicabilidade e versionamento. |
| 3. Atualizar documentos e schemas | 4-10 semanas | DF-e/NFS-e novos com validacao em homologacao e persistencia dos campos novos. |
| 4. Conectar fiscal e financeiro | 6-12 semanas | Split Payment modelado em pedido, pagamento, contas a receber e conciliacao. |
| 5. Operar convivencia | 2026-2033 | Dois modelos rodando com monitoramento, auditoria e feature flags por dominio. |
Discovery
Inventário inicial
0/4
Arquitetura
Contratos e dados
0/5
Operação
Produção e sustentação
0/4
Priorize fluxos que combinam alto volume, impacto em caixa e dependência de múltiplas integrações: checkout, faturamento, Split Payment, devolução/cancelamento e apuração.
O objetivo é reduzir divergência entre sistemas, não apenas atualizar campos fiscais. Cada etapa deve produzir evidência rastreável de cálculo, emissão, pagamento e conciliação.