Most global S/4HANA programmes treat tax as a workstream to handle near the end. Localization gets a line in the plan, somewhere after integration and before cutover. That sequencing is where budgets break — not because the work is hard, but because the obligation is not a report to be produced. It is a condition the transaction must satisfy before it can complete.

And a multinational does not face one model. It faces three at once.

Latin America: the authority sits inside the transaction

In Brazil and its neighbours, the tax authority authorizes the document before the sale completes. The invoice is not a record of what happened; it is a request for permission, and the answer determines whether the business event is allowed to exist.

This is clearance. It means the fiscal rule is not a downstream reporting concern — it is a blocking dependency in the order-to-cash flow. If the determination is wrong, nothing ships.

Brazil is now adding IBS and CBS on top of a model that already runs at national scale, with a transition period in which old and new coexist. The architectural consequence is not “we need to add two taxes”. It is that the same document must carry two parallel tax logics and remain valid under both.

European Union: reporting, harmonizing on a deadline

The EU went the other way. ViDA — VAT in the Digital Age — was formally adopted by the Council in March 2025. From 1 July 2030, electronic invoicing and near real-time digital reporting become mandatory for intra-Community B2B transactions, on the EN 16931 standard.

The part that catches architects out is the second date. Member states that already ran domestic mandates before 2024 — Italy, France, Poland, Germany, Romania, Belgium — have until 2035 to converge on the European standard. So a European landscape has to run national models and the EU model in parallel for five years.

United States: no mandate, which is harder

There is no federal e-invoicing mandate and none announced. Adoption is driven by exchange networks and by what trading partners require, not by law.

That makes the US the hardest of the three to plan for, and it is usually the one treated as solved. There is no deadline to design against, so there is no forcing function — until a major customer asks for structured invoices and the answer has to be yes within a quarter.

What this means for the architecture

Three regimes, three clocks, one landscape. The temptation is to solve each one where it appears: a Brazilian enhancement here, a European report there, a flat-file bridge for the US customer who asked.

That produces three parallel workarounds instead of one architecture, and every one of them lives in the core.

The alternative rests on a single observation: mandates change faster than an ERP upgrade cycle. Any design that embeds country rules in core customizations is buying a rewrite every time a parliament votes. Peppol, PINT and EN 16931 exist precisely so that an interoperability layer can absorb that change instead.

So the rule we apply is narrow and unglamorous:

  • Determination logic that is commercially stable can live in the core.
  • Logic that is regulatory and volatile belongs outside it, in a layer built to be rewritten.
  • The boundary between them is an architecture decision, taken deliberately and early — not an accident of who happened to be on the project when the requirement arrived.

Compliance is not a constraint discovered late. It is architecture, and the programmes that treat it that way are the ones whose budgets hold.