Understanding the Tax Engine

Tax is the most intricate part of any accounting system — and REDA’s tax engine is the most layered piece of this product. The good news: once you understand the shape of it, the rest of this category falls into place. This article is the map. It explains how the whole machine fits together so that every later article — jurisdictions, rules, calculation, withholding — slots into a picture you already hold in your head.

The single most important idea: REDA’s tax engine is data-driven. The rules of tax for the United Kingdom, the United States, Brazil, and India are not written into the software — they are configured as records. Adding a new country means creating jurisdiction, tax-type, and rule records. It never means changing code. The same engine that fires one rule for a UK sale fires six for a Brazilian one, with nothing different under the hood.

The big idea: a rulebook, and a calculation

Hold two things apart in your mind and everything else follows:

The four layers of the engine

The tax module is fourteen objects. That sounds like a lot until you see them grouped — they fall into three setup layers plus one runtime output. Each later article in this category lives in one of these layers, so this is the table to remember.

Layer 1 — Master Data (the vocabulary)

Configured once. These define the universe the rules draw on.

Layer 2 — The Rule Engine (the brain)

Layer 3 — Entity Configuration (your specifics)

Runtime output

The remaining three objects belong to withholding tax (a parallel engine): Withholding Tax Rule and its Withholding Tax Rate children, plus the WHT Transaction audit record. More on that below.

Where the engine gets “who” and “where”

The engine needs to know the seller, the buyer, and their locations. Those come from two records you already manage, each extended with two tax fields:

So a sale from your UK entity to a French customer has origin = GB, destination = FR — and the engine knows, without anyone choosing it, that this is an export. (The Entity also carries the withholding-tax configuration; see the WHT articles.)

How one calculation flows

When an invoice is posted, the engine runs a fixed six-step pipeline. You don’t need the internals yet — How Tax Calculates on a Document covers every step with numbers — but here is the shape:

The same engine, four countries

Nothing makes the design click like watching one engine handle wildly different tax regimes with no code change. We’ll use these four throughout the category.

🇬🇧 United Kingdom — one simple rule

Your UK entity sells £1,000 of standard-rated goods to a UK customer. One rule matches: VAT at 20%, added on top.

This is the simplest case, and the most common. With one catch-all rule and a flag on the product, you barely configure anything — covered in UK VAT.

🇺🇸 United States — nexus decides everything

US sales tax is destination-based, but only applies if your entity is registered (has nexus) in the buyer’s state. Same $1,000 sale, two outcomes:

That “zero tax, not an error” behaviour is deliberate — crossing into a new state is a normal business event. See US Sales Tax & Nexus.

🇧🇷 Brazil — six rules fire at once

An interstate sale from São Paulo to a consumer in Rio de Janeiro is the engine’s stress test. Six rules fire on a single line, in sequence — and three of them (ICMS, PIS, COFINS) are embedded inside the price (“por dentro”), not added on top:

The engine handles all of this through ordinary configuration — sequence, dependency links, and calculation components. Walked through in full in Brazil.

🇮🇳 India — the rules change with the route

Indian GST splits by whether the sale crosses a state line — and the engine derives that automatically from the two jurisdictions:

India also features TDS (withholding) on the purchase side — the bridge into the WHT articles. See India.

Real data: the UK rulebook, record by record

Enough theory — let’s look at the actual records. Everything below ships with REDA in the UK seed pack; running the Tax Seeding Wizard for “United Kingdom” creates exactly these. This is what one country’s entire rulebook looks like — and it’s small.

1 · Jurisdictions — the geography

Five records: the country, plus its four nations as children. VAT is UK-wide, so the rules sit at country level — but the hierarchy is there for the cases that need it (e.g. Northern Ireland’s Windsor Framework).

2 · Tax Types — the named taxes

The UK has one tax (VAT) with four treatments. Note Exempt is the only one where input VAT is not recoverable — that flag drives the GL routing later.

3 · Profiles — classifying the “what” and the “who”

Two independent dimensions. Tax Profiles classify the product; Party Tax Profiles classify the business.

4 · Tax Rules — the brain

Four rules, one per treatment. Each ties a tax type to a product tax profile at a rate, scoped to the UK. Notice how lean a rule is when a country is simple — most of the eight matching dimensions are left blank (= “match anything”).

5 · GL accounts & routing — where the tax lands

The seed also creates the tax GL accounts and the Tax GL Mapping records that route each tax to them. This is where the recoverable flag pays off: the same VAT type posts to a liability when you sell and to an asset when you buy.

6 · Putting it together — the £1,000 sale through these exact records

Now watch the engine walk this data for our UK sale of £1,000 of standard-rated goods to a VAT-registered UK customer:

The resulting journal:

Had this been a purchase of the same goods, that £200 would instead debit 1511-VAT-ITC-GB (VAT Input Tax Recoverable) — an asset you reclaim from HMRC — because the purchase mapping’s Is Recoverable flag is set to Yes. Same tax type, different account, decided by one flag. That’s the whole engine in miniature.

Real data: Brazil, where six rules fire at once

Now the opposite extreme — same engine, same kind of records, but Brazil’s seed pack is an order of magnitude bigger: 28 jurisdictions, 12 tax types, and 58 rules (versus the UK’s 5 / 4 / 4). And a single interstate sale fires six rules in sequence. The remarkable part: not one line of code differs from the UK. It’s all data.

The taxes in play

An interstate sale of manufactured goods touches six different taxes — three federal, three at state level:

The seller’s regime changes the rates

Brazil ships five Party Tax Profiles — and which one your entity carries genuinely changes the calculation. PIS and COFINS have two versions, and the engine picks based on the seller’s regime:

That’s the Seller Regime dimension on a Tax Rule doing its job — a Lucro Real company and a Lucro Presumido company selling the identical product pay different federal contributions, from the same rule set.

The six rules that fire — São Paulo → Rio de Janeiro

A Lucro Real manufacturer in São Paulo sells R$1,000 of goods to an end consumer in Rio de Janeiro (an interstate sale, fiscal operation BR-6101; DIFAL and FCP fire only when the buyer is a non-contributor — a consumer rather than an ICMS-registered business). The engine matches six rules and runs them in sequence order:

Illustrative amounts on the R$1,000 goods value — six Source Line Tax rows, each posting to its own account:

What you set up vs what’s automatic

Where to go next

Read this category in order — it follows the way you actually build:

• Foundations: Tax Jurisdictions → Tax Types → Tax GL Mapping → Fiscal Operations
• Classification: Party Tax Profiles → Tax Profiles → Product Fiscal Profiles
• Rules & calculation: Tax Rules → Calculation Components → Entity Tax Registration → How Tax Calculates → Source Line Tax
• Put it together: the country walkthroughs — UK, US, Brazil, India
• Withholding: Understanding Withholding Tax and its sub-articles

Frequently asked questions