01
Context
Summary of what changes from 2026 onward and how the test/adaptation period affects application contracts, data persistence and reconciliation.
Technical summary
- • Fiscal documents become operational data sources: CBS/IBS/IS enter the XML, DPS, events and assisted tax assessment.
- • Fiscal and financial become coupled: Split Payment connects invoice, payment, write-off, reversal and cash flow.
- • Master data stops being support: cClassTrib, CST, destination, benefit and regime start determining transactional behavior.
Timeline that systems must support
| Phase | Theme | What changes | Application impact |
|---|---|---|---|
| 2026 H1 | Inventory and architecture design | Map all touchpoints that calculate price, tax, invoice, receivables, credits and tax assessment. | Build backlog by domain: ERP, fiscal, pricing, checkout, payments, finance, data/BI and integrations. |
| 2026 | CBS/IBS test and adaptation year | Fiscal documents (DF-e) must highlight CBS and IBS per technical notes; official focus is validation of digital models and ancillary obligations. | Systems must generate new XML/JSON, persist bases/values and reconcile what was issued with the assisted tax assessment. |
| 2027 | Full CBS and phased Split Payment | CBS replaces PIS/Cofins; Split Payment expands gradually according to regulation, payment arrangements and technical capacity. | Checkout, accounts receivable, bank reconciliation and ledger must handle gross value, segregated tax and net received amount. |
| 2029-2032 | Gradual IBS transition | ICMS/ISS coexist with IBS at progressive percentages, requiring two parallel models. | Tax engine and accounting must support coexistence, destination-based allocation, credits and comparative reports. |
| 2033 | Full new model | IBS fully replaces ICMS/ISS and the legacy model ceases to be the main path. | Controlled deactivation of old rules, master data cleanup and consolidation of the definitive operational model. |
| Source | Topic | Usage in 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. |
In 2026, fields may not technically block all issuances from the start, but the legal obligation and the need to persist data already affect application contracts and reconciliation.
02
Impacted applications
System domains to inventory before changing schemas or rules: fiscal, finance, master data, pricing, checkout, integrations and data.
Applications that typically break first
| Area | Common state today | What changes | Risk | Recommended modernization |
|---|---|---|---|---|
| Tax Engine | Rules spread across ERP, fiscal module, pricing, NCM, CFOP and per-state/city configurations. | CBS, IBS and IS require per-item calculation, tax-exclusive base, broad credits, specific regimes and dynamic tax classification. | Risk of inconsistency between order, invoice, financials and assisted tax assessment. | Centralize rules in a versioned service with date-effective parameters and per-item explainability. |
| Fiscal document issuer / DF-e | Existing layouts for NF-e, NFC-e, CT-e, NFS-e and sector-specific documents. | New IBS/CBS/IS groups, new totals, events and sharing/credit information. | A technically authorized document may still be inconsistent with ancillary obligations or tax assessment. | Decouple fiscal generation from tax rules; version schemas and support layout coexistence. |
| Product, service and customer master data | NCM, service code, CFOP, CST and tax benefits maintained as operational master data. | GTIN where applicable, cClassTrib, CBS/IBS CST, ZFM/ALC indicators, benefits, destination and consumer type become central. | Risk of incorrect tax classification at scale, especially in e-commerce, marketplace and PDV. | Build fiscal catalog governance with validity, rule source, approval workflow and audit trail. |
| Pricing, quote and checkout | Price usually treated as a final value with embedded taxes and little real-time fiscal separation. | Tax-exclusive base, itemized display and Split Payment change what the customer sees, pays and what lands net in the cash account. | Margin, discount, freight, coupon and installment calculated on wrong bases. | Expose gross price, taxes, net amount and credit/benefit effects within the same calculation contract. |
| Payments and accounts receivable | Payment, invoice and reconciliation often resolved in batch. | Split Payment links the fiscal document to the financial transaction where applicable; part of the tax may be segregated at settlement. | Risk of divergence between settlement, write-off, reversal, return and tax assessment. | Event-driven reconciliation model with idempotency, per-transaction status and complete audit trail. |
| Accounting, ledger and tax assessment | Monthly close with manual reconciliations and spreadsheet or ERP report adjustments. | Assisted tax assessment consolidates debits and credits from fiscal documents and records. | Internal ledger does not match the tax authority preliminary assessment; manual adjustments become routine. | Build fiscal sub-ledger per item/document, automated reconciliation and explainable divergence. |
| B2B integrations, marketplace and digital platforms | Legacy EDI/API contracts exchange XMLs, orders and payments without all the new fiscal fields. | Digital platforms will have specific obligations once layouts are published; marketplaces, sellers and PSPs must prepare contracts. | Risk of incompatibility between seller, marketplace, ERP, gateway and tax authorities. | Version external APIs, create fiscal schema registry and per-partner compatibility strategy. |
| Data, BI and audit | Fiscal data used mainly for ancillary obligations rather than real-time operations. | Fiscal data now feeds assisted assessment, credit control, cash flow and operational audit. | Revenue, margin and cash indicators inconsistent across finance, fiscal and BI. | Analytical model with granularity per item, document, payment, credit and event. |
Recommended control point: document, for each domain, which system calculates, transforms or persists fiscal values.
Expected evidence: inventory with owner, data contract, mandatory fields, consuming systems and rule effective date.
03
Reference architecture
Recommended flow to keep order, calculation, fiscal document, payment, ledger and assessment consistent during the transition.
Flows that change structurally
| Flow | Before | After | Systems involved |
|---|---|---|---|
| Order -> pricing -> invoice -> payment | Linear flow with embedded taxes, deferred financial write-off and batch assessment. | Coupled fiscal-financial flow: CBS/IBS/IS calculation, document with itemized tax, payment with possible split and event-based reconciliation. | E-commerce, ERP, tax engine, fiscal issuer, gateway/PSP, accounts receivable. |
| Service -> DPS/NFS-e -> municipality/national environment | Municipalities with different standards and city-specific integrations. | National NFS-e/DPS standard with IBS/CBS groups and national environment integration. | Service system, billing, NFS-e, municipality/national environment, accounting. |
| Purchase -> credit -> assessment | Tax credit depends on PIS/Cofins/ICMS/ISS rules and manual reconciliation. | Broad CBS/IBS credit requires traceability per document, item, supplier and payment. | Procurement, fiscal inbound, accounts payable, ledger, fiscal data lake. |
| Cancellation/return -> fiscal/financial reversal | Fiscal events and financial reversals handled by separate routines. | Fiscal event must reconcile highlighted tax, credit, split and net amount. | OMS, ERP, fiscal issuer, PSP, finance and customer service. |
Target architecture for 2026-2033 coexistence
+-------------+ +-------------+ +---------------+
| Pedido/Cart | ---> | Tax Engine | ---> | Emissor DF-e |
+-------------+ +-------------+ +---------------+
| | |
v v v
+-------------+ +-------------+ +---------------+
| PSP/Gateway | ---> | AR/Ledger | ---> | Apuracao/Fisco|
+-------------+ +-------------+ +---------------+
| | |
+--------------------+--------------------+
v
Data Lake fiscal auditavel
Architecture decision
- • Centralize the calculation contract: price, discount, freight, destination and taxes must have a single explainable answer.
- • Version by effective date: tax rules are not a single deploy; they are regulatory data with start and end dates.
- • Design for coexistence: the legacy and new model will run together for years.
04
Tax calculation
Calculation changes affecting tax engine, pricing, invoice preview, API contracts and item-level persistence.
What changes in the application calculation
| Dimension | What changes | Application impact |
|---|---|---|
| Tax-exclusive base | Tax no longer compounds its own base as in the current model in many situations. | Pricing and invoice preview must recalculate gross, net, discount, freight and taxes within the same contract. |
| Destination-based taxation | IBS depends on the destination/consumption location and the sharing between government entities. | Address, municipality, state, end consumer and operation type become mandatory calculation inputs. |
| Broad credit | Credit tends to be financial and broader, but depends on traceable documents and payments. | Accounts payable, fiscal inbound and ledger must expose credit per item/document/supplier. |
| Specific regimes | Finance, healthcare, insurance, hospitality, fuels, single-phase and others have their own rules. | Tax engine must support plugins/rules per sector, not just a simple table by NCM/service. |
| Selective Tax (IS) | IS applies to specific goods/services and adds another classification layer. | Product catalog must indicate IS applicability, effective date, base and exceptions. |
The calculation contract must return values per item, applied rule, rule effective date and enough explanation for audit and customer service.
05
Electronic fiscal documents
DF-e listed by Receita Federal and layouts that start carrying CBS/IBS according to technical notes. The point is preparing data contracts, not only issuer screens.
Fiscal documents and contracts impacted
| Document | New fields | Application change | Owner |
|---|---|---|---|
| NF-e / NFC-e | UB group (IBS/CBS/IS per item), W03 totals and CST/cClassTrib tables per NT 2025.002. | Update issuer, validators, XML storage, DANFE/representation and downstream integrations. | ERP / Fiscal / PDV |
| NFS-e / DPS national | IBS/CBS group, national codes, indicators such as ZFM/ALC and national environment rules where applicable. | Support own issuer or national environment, Sefin/ADN APIs and municipal coexistence. | Billing / Services / Fiscal |
| CT-e / CT-e OS | CBS/IBS highlight in transportation and totalization adjustments. | Update TMS, freight calculation, linked documents and shipper integrations. | Logistics / TMS |
| NFCom / NF3e / BP-e | CBS/IBS fields and sector-specific rules. | Adapt sector platforms and contracts with regulators/operators. | Telecom / Energy / Transport |
| DeRE and specific regime declarations | Specific layouts for finance, healthcare, insurance, consortiums and others. | Create new declaratory layer and reconcile with operations without traditional fiscal documents. | Fiscal / Compliance / Product |
Authorized document does not mean correct system
The initial relaxation of technical validations does not eliminate the legal obligation. This creates a new risk: documents may pass through the authorizer but still generate non-compliance, assessment divergence and operational rework.
06
Master data and fiscal tables
Master data fields that start directly influencing operations: product, service, customer, supplier and regulatory tables.
Master data that now governs transactional behavior
| Data | Critical fields | Typical failure |
|---|---|---|
| Product / SKU | GTIN where applicable, NCM, cClassTrib, IS applicability, tax benefit, single-phase flag, cBenef. | New SKU without correct classification can generate tax divergence, rejection or subsequent adjustment. |
| Service | National code, DPS, incidence municipality, provider/taker, special regime. | NFS-e issued with incorrect municipality or code breaks assisted tax assessment. |
| Customer / taker | CNPJ/CPF, registrations, destination address, taxpayer status, end consumer, ZFM/ALC. | Destination rule and benefit applied incorrectly in checkout or invoice. |
| Supplier | Tax regime, regularity, received documents, confirmed payment. | Tax credit not claimed or blocked due to lack of traceability. |
| Tax table | CST CBS/IBS, rates, reductions, deferrals, effective date, normative source. | Table update without versioning causes different behavior across environments. |
Recommended control point: simulate journeys with variation of fiscal classification, destination, benefit and regime.
Expected evidence: the same item produces a consistent result across pricing, fiscal document, payment, ledger and assisted assessment.
07
Payments and Split Payment
Split Payment should be treated as phased fiscal-financial integration, not as an instant universal obligation for all flows.
How Split Payment changes product and finance
| Area | Impact | Required architecture |
|---|---|---|
| Checkout and order | Order must store gross, estimated tax, net, payment method and linked fiscal document for scenarios with segregation. | Single contract between pricing, tax engine and payment. |
| Gateway / PSP | Transaction must be ready to carry fiscal identifiers and receive segregation response when the model is applicable. | Idempotent callbacks, retry, granular status and signing/verification. |
| Accounts receivable | Financial write-off may no longer equal the total invoice amount when tax is segregated at settlement. | Ledger with gross, retained tax, net, fees and divergences. |
| Treasury | Working capital may change because part of the tax is no longer temporarily available in cash. | Cash forecast with split, installment and reversal scenarios. |
| Customer service and refund | Cancellations and returns must reverse fiscal and financial records in a synchronized way. | Return orchestrator with fiscal compensation and automatic reconciliation. |
Real impact: cash flow and reconciliation
- • The amount that lands in cash may be less than the total invoice.
- • Installments, partial returns, cancellations and chargebacks must carry the fiscal effect.
- • Each transaction must be reconcilable by document, installment, tax, fee and net amount.
08
Integrations and API contracts
Internal and external contracts that need new fiscal fields, events and reconcilable identifiers.
Integration contracts that need to change
| Contract | New fields / events | Recommended versioning |
|---|---|---|
| ERP -> fiscal issuer | item.cClassTrib, item.CST, IBS/CBS base, rate, value, IS, destination. | Version by NT and effective date; accept optional/mandatory fields per phase. |
| E-commerce -> tax engine | sku, consumer, destination address, coupon, freight, channel, marketplace, operation date. | Explainable response with gross/net/taxes per item and applied rule. |
| ERP -> PSP/gateway | fiscal document id, CBS value, IBS value, IS value, net value, original transaction. | Idempotency and confirmation/error/reversal callbacks. |
| ERP -> data warehouse | document, item, tax, credit, payment, reversal, event, divergence. | Append-only analytical model for audit and reprocessing. |
| Marketplace -> seller | tax responsible party, seller, document, split, commission, transfer, return. | Contract per seller and per regime, with legacy/new coexistence. |
Systems that already have versioned APIs and a fiscal schema registry will suffer less. Those exchanging XML and CSV without a formal contract will discover the impact when partners start sending new fields.
09
Production operations
Concrete divergence signals for operations: order vs invoice, invoice vs payment, master data vs calculation, invoice vs assisted assessment.
Operational signals that need to become dashboards
| Signal | Why it matters | Owner |
|---|---|---|
| Documents missing CBS/IBS fields | Legal obligation may exist even without immediate technical rejection. | Fiscal Platform |
| Order vs invoice divergence | Pricing and tax engine may apply different rules. | Commerce Platform |
| Invoice vs payment divergence | Split Payment changes write-off and net amount received. | Payments / AR |
| Invoice vs assisted assessment divergence | Tax authority consolidates debits/credits from documents. | Fiscal / Accounting |
| Expired fiscal master data | cClassTrib/CST/benefits table changes by effective date. | Master Data |
| Fiscal contingency queues | SEFAZ, national NFS-e or PSPs may fail and impact issuance, receipt or reconciliation. | SRE / Fiscal Ops |
Recommended control point: continuously compare order, fiscal document, payment, master data and assessment.
Expected evidence: open divergences by type (calculation, master data, document, split, write-off, assessment) with traceable payloads and events.
10
Adaptation roadmap
Practical sequence to prepare existing systems: inventory, central calculation, documents, Split Payment, coexistence and operations.
Modernization roadmap by phase
| Phase | Typical window | Deliverable |
|---|---|---|
| 1. Inventory flows | 2-4 weeks | Map of applications, contracts, owners and critical fiscal journeys. |
| 2. Separate tax engine | 4-8 weeks | Single tax calculation contract with explainability and versioning. |
| 3. Update documents and schemas | 4-10 weeks | New DF-e/NFS-e validated in staging with new fields persisted. |
| 4. Connect fiscal and financial | 6-12 weeks | Split Payment modeled in order, payment, accounts receivable and reconciliation. |
| 5. Operate coexistence | 2026-2033 | Two models running with monitoring, audit and feature flags per domain. |
Discovery
Initial inventory
0/4
Architecture
Contracts and data
0/5
Operations
Production and sustaining
0/4
Prioritize flows that combine high volume, cash impact and dependency on multiple integrations: checkout, billing, Split Payment, returns/cancellations and assessment.
The goal is to reduce divergence between systems, not just update fiscal fields. Each step must produce traceable evidence of calculation, issuance, payment and reconciliation.