Legacy systems and Brazil’s tax reform: adapt, integrate or rewrite before split payment

January 2027 is the date that matters for your company’s system. That is when Brazil starts actually collecting the CBS (the new federal tax on goods and services) and PIS and Cofins cease to exist, under Constitutional Amendment 132/2023. In 2026 the new taxes already appear on invoices on a test basis, and Complementary Law 214/2025 spells out how everything works: rates, credits, tax documents and collection at payment settlement, known as split payment.

For companies running an in-house ERP, a Delphi system built many years ago or a patchwork of spreadsheets and integrations that only one employee understands, the board’s question is blunt: will our system cope? And if it will not, do we patch it, build something next to it or replace it altogether?

This article answers in boardroom language. It explains what the reform requires from software, the signs that a legacy system has hit its limit, a decision matrix across three paths (adapt, integrate around it, rewrite) and how to migrate without stopping billing. At Reiko we have kept systems running for more than 20 years, and the lesson is simple: good software is the kind that keeps working years after delivery, including when the law changes.

What the reform requires from software

The reform replaces five taxes (PIS, Cofins, IPI, ICMS and ISS) with three: the CBS (federal), the IBS (state and municipal, run by a Management Committee) and a Selective Tax on specific goods. For the system, the problem is not just changing a rate. For years both models coexist, and the software has to calculate, issue, assess and reconcile both at the same time.

The timeline your system has to follow

• 2026 (test year): CBS at 0.9% and IBS at 0.1% shown on the tax document. The amount is offset against PIS and Cofins, and Complementary Law 214/2025 waives payment for taxpayers who meet their filing obligations. Cash barely changes, but the invoice has to be right.
• 2027: CBS starts being collected, PIS and Cofins are abolished and the IPI rate goes to zero (except for products with incentivized manufacturing in the Manaus Free Trade Zone). In 2027 and 2028 the IBS stays in test mode, at 0.05% state and 0.05% municipal. According to the Federal Revenue Service, CBS and IBS obligations apply to Simples Nacional companies (Brazil’s simplified regime for small businesses) from January 1, 2027.
• 2029 to 2032: ICMS (state VAT) and ISS (municipal service tax) step down one notch a year (9/10, 8/10, 7/10 and 6/10 of current rates) while the IBS rises to compensate. For four years the same sale carries the old taxes, reduced, and the new ones, growing.
• 2033: ICMS and ISS are abolished and the new model stands alone.

What changes inside the system

• Product and service catalog: every item needs an IBS and CBS classification. For the NF-e (Brazil’s electronic goods invoice), Technical Note 2025.002-RTC created a per-item field group with CST, a tax classification code (cClassTrib), tax base and separate rates for state IBS, municipal IBS and CBS.
• Parallel calculation: until 2032 the tax engine calculates ICMS, ISS and the new taxes on the same transaction, each with its own rule, reduction and exception.
• Tax documents: NF-e, NFC-e (consumer invoice) and NFS-e (service invoice) with new layouts that change through technical notes. For services, the Federal Revenue Service announced that the national-standard NFS-e becomes mandatory for micro and small companies under Simples Nacional from November 1, 2026.
• Split payment: at payment settlement, the payment institution separates the IBS and CBS and pays them straight to the tax authorities. For that, the payment has to be linked to the tax document. A system that issues the invoice in one place and settles the bank slip in another, with no link between them, will struggle.
• Reconciliation: with split payment, what lands in the account tends to be the amount net of the segregated tax. Finance has to reconcile invoice, payment, withheld amount and credit, and receivables has to understand why the deposit is smaller than the bill.
• Credits and assessment: under the new model, the general rule of Complementary Law 214/2025 ties the buyer’s credit to the settlement of the tax at the previous stage. The system has to keep the link between purchase, incoming invoice and payment.
• Audit trail: every calculated amount must be explainable: which rule, which table version, which date. In a tax audit, "the system calculated it that way" is not an answer.

The details of the service invoice are in our article on NFS-e with IBS and CBS. Here the focus is the bigger decision: what to do with the system as a whole.

Signs that the legacy system will not cope

Not every old system needs replacing. Many have run well for decades and only need adjustments. The signs below indicate that adjusting will be riskier than it looks:

• Tax rules scattered through the code: hard-coded rates in screens, reports, database procedures and helper spreadsheets. Change one place, forget another, and the invoice goes out wrong.
• Nobody knows exactly how the calculation works: whoever wrote it left the company, there is no documentation and the original vendor no longer exists.
• Incomplete or inaccessible source code: third-party components without source, an old version of Delphi, Clipper, VB6 or Access that only runs on a new machine with workarounds.
• Invoicing tied to a component that no longer gets updates: the layout changes through technical notes, several times during the transition.
• No test environment: every change goes straight to production, and calculation errors only surface when a customer complains.
• Integration by manual file: export a TXT, someone imports it into the database, someone else keys in the payment. Split payment requires an automatic link between invoice and payment.

If three or more of these signs show up, the question stops being "can we adapt it?" and becomes "is adapting it worth it?".

Three paths: adapt, integrate around it, rewrite

There is no single answer. There is a combination of the system’s condition, the size of the tax risk and how much the business depends on rules that only exist in that code. The three paths:

Path 1: adapt the legacy system

Change the system itself to add the new fields, the parallel calculation and invoicing in the updated layout. It makes sense when the source code is accessible, someone knows it and the tax rules sit in a few places. The risk: from 2026 to 2033 there is not one change, there are many. Adapting once is feasible; adapting every year in fragile code usually is not.

Path 2: integrate around it (strangler fig pattern)

The name comes from the fig tree that grows around an old tree until it replaces it. The pattern, described by Martin Fowler, replaces the system gradually: you build a new layer next to the legacy system (an API, a tax calculation service, an invoicing module) and route one function at a time to it. The legacy system keeps doing what it does well, such as inventory and master data, and the new tax logic is born outside it.

For the tax reform, this usually means a service that receives sales data from the old system, calculates ICMS, ISS, IBS and CBS with versioned rules, issues the invoice, records the link to the payment and returns the result. Once the new engine is stable, the next function moves out of the legacy system. At no point does the company stop billing.

Path 3: rewrite (or switch to an off-the-shelf ERP)

Build a new system or implement a market ERP. It makes sense when the legacy system already holds the business back elsewhere (cloud, mobile, bank integration), when there is no source code or when maintenance has become hostage to a single person. The risk is the classic one: business rules forgotten along the way and the temptation to flip the switch in a single day, in the middle of the tax transition.

Decision matrix

For many companies with an in-house system that works well day to day, path 2 tends to carry the lowest risk during the transition: it protects billing, isolates the part that will change most until 2033 and leaves the decision about the rest of the system for later, without pressure. The broader comparison is in our article custom vs off-the-shelf software, and the factors behind the investment are in how much a web system costs.

Migrating without stopping billing

Whatever the path, the golden rule is the same: the company cannot go a single day without issuing invoices. Practices that reduce the risk:

• Run in parallel before switching: the new calculation runs next to the old one, on the same sales, and differences are analyzed before anything reaches the customer.
• Switch by function, not by date: invoicing first, then reconciliation, then receivables. Each step with a definition of done and a way back.
• Migrate data in waves: master data first, then open documents, and closed history last. History can stay queryable in the legacy system in read-only mode, without being fully converted.
• Check by totals: revenue per month, balance per customer, stock per item. If the totals do not match between old and new, the migration is not finished.
• Avoid critical windows: month-end close, year-end and rule-change dates (every January 1 of the transition) are not days to switch systems.
• Involve the accountant from day one: item classification, tax regime and incentives are tax decisions, not IT decisions. The system executes; the tax team decides.

The reasoning is the same as in any well-run platform change, as we showed when discussing moving from WordPress to a custom system: first understand everything the old platform does, then move one part at a time.

AI to map business rules hidden in old code

The biggest risk in a migration is what the old system does that nobody remembers: a special discount for one customer, a rounding rule the accountant asked for, an exception for one product. Those rules live in the code, not in the documentation.

This is where AI genuinely helps. Current language models read Delphi, VB, Clipper, PL/SQL and database procedures, and can:

• Summarize what each routine does, in plain language, for non-programmers.
• List the places in the code where tax calculations, hard-coded rates or customer-specific rules appear.
• Draft documentation of business rules and test cases with expected inputs and outputs.

The caveat: AI reads and drafts, people validate. It can misread a rule or invent a plausible explanation. Every rule it surfaces must be confirmed by someone who knows the business and by the accountant, and tested with real data. And company code should only go to tools whose contract forbids using the data for training.

Checklist for the board meeting

Before choosing between adapting, integrating or rewriting, bring these answers to the table:

1. Which systems issue tax documents today (NF-e, NFC-e, NFS-e) and who maintains each one?
2. Do we have the source code and someone who knows it? Does the original vendor still exist?
3. Where do the tax rules live: in one place or scattered across the system?
4. Is the product and service catalog ready to receive the IBS and CBS classification? Who will review it?
5. How is payment linked to the invoice today? Do bank slips, Pix (Brazil’s instant payment system) and cards arrive with a reference to the tax document?
6. Is finance ready to receive amounts with the tax already segregated and to reconcile them?
7. Is there a test environment? Can we issue invoices in the sandbox without affecting production?
8. What is the company’s tax regime and what does the accountant recommend for 2027?
9. Who decides, who follows up and what is the criterion for calling the transition done?

With these answers, the right path usually becomes obvious. Mapping this scenario and executing the chosen path is what we do in our custom web systems work.

Conclusion

The tax reform is a multi-year project, not a January event. From 2026 to 2033 the company’s system will live with two models, several rate shifts and a new way of receiving money from sales. A legacy system is not a problem in itself: the problem is not knowing what it does or how much it can take.

Adapting, integrating around it or rewriting are all legitimate paths. What decides is the state of the code, the risk to billing and what the business needs for the coming years. If you want to discuss your case, talk to Reiko.

Frequently asked questions

Is split payment mandatory in 2027?

Complementary Law 214/2025 provides for split payment and leaves its gradual rollout to a joint act of the Federal Revenue Service and the IBS Management Committee, including cases where it will be optional. In September 2026, according to the specialized press, the Federal Revenue Service stated that the mechanism starts as optional from the second half of 2027, only for business-to-business transactions, with no date set for it to become mandatory. Tests with payment institutions start on October 15, 2026. Even while optional, it is worth preparing the link between invoice and payment: that is what will be required once it becomes mandatory.

Can my Delphi system issue invoices with IBS and CBS?

It may. The language is not the problem: Delphi generates XML and calls web services like any other. What decides is whether the source code exists, whether the invoicing component gets updates for the reform’s technical notes and whether the tax rules are concentrated. With that in order, adapting is feasible. Without it, a calculation and invoicing layer next to the system solves the problem without rewriting the rest.

Is it worth switching to an off-the-shelf ERP?

It is when the company’s processes fit the ERP without heavy customization and the current system already holds the business back elsewhere. The risk lies in the company-specific rules the old system handled and the ERP does not: map them before signing. And switching systems in the middle of the tax transition means running two big projects at once.

How do we migrate data without losing history?

Migrate in waves (master data, open documents, closed history), check by totals (revenue per month, balance per customer) and keep the origin identifier on every record. Old history does not need to be fully converted: it can stay queryable in read-only mode, as long as it remains accessible for the period the law requires tax documents to be kept.

Do Simples Nacional companies need to worry too?

Yes, on a different calendar. According to the Federal Revenue Service, CBS and IBS obligations apply to Simples Nacional companies from January 1, 2027, and the national-standard NFS-e becomes mandatory for micro and small Simples companies from November 1, 2026. There is also the option to pay IBS and CBS under the regular regime, which is the accountant’s call, but the system has to support that choice.