Tax Rules
The Tax Rule is the brain of the engine. Everything before it — jurisdictions, tax types, profiles — is vocabulary. The rule is the sentence: “Apply this tax type at this rate when these conditions are all true.” When you post an invoice, the engine finds every rule whose conditions fit and runs them.
Two ideas make tax rules powerful, and both run counter to what people expect. First, many rules fire at once — there is no “first match wins.” A UK sale matches one rule; a Brazilian interstate sale matches six, and all six apply. Second, a rule’s conditions are mostly optional, and a blank condition means “match anything.” That’s what lets a simple country use lean rules while a complex one layers precise ones.
Access you'll need. Setting up and maintaining tax rules requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view them but not change them.
Anatomy: three groups of fields
A Tax Rule looks busy, but its fields fall into three clean groups. Only five are required — the rest are optional conditions and calculation tweaks.
| Group | Fields | Job |
|---|---|---|
| Identity & output | Code, Tax Type, Rate, Sequence, Description, Notes, Is Active | What tax, what rate, in what order |
| Matching conditions | Origin & Destination Jurisdiction, Tax Profile, Buyer & Seller Party Profile, Fiscal Operation, Seller Regime, Effective From / To | When does this rule fire? |
| Calculation modifiers | Include Freight, Subtract Discount, Base Reduction %, MVA %, Tax Included in Price, Depends On Prior Rule | How is the base computed? |
The matching conditions — null means “any”
A rule fires only when all of its set conditions are satisfied. Leave a condition blank and it stops being a filter — the rule matches any value there. This “null = wildcard” behaviour is the single most important thing to understand about rules.
| Condition | Matches when… | Blank means |
|---|---|---|
| Origin Jurisdiction | Seller’s location is this place or below it (ancestry) | Any origin |
| Destination Jurisdiction | Buyer’s location is this place or below it | Any destination |
| Tax Profile | The line’s product treatment equals this | Catch-all — fires only for products flagged “Apply Default Tax” (see below) |
| Party Tax Profile (Buyer) | The customer’s party profile equals this | Any buyer |
| Party Tax Profile (Seller) | Your entity’s party profile equals this | Any seller |
| Fiscal Operation | The derived operation equals this (interstate, export…) | Any operation |
| Seller Regime | Your entity’s regime matches (Lucro Real…) — read from the entity Party Tax Profile’s Tax Regime field, so renaming a profile never changes the math | Any = all regimes |
| Buyer Contributor Scope | The buyer’s contributor status matches (Contributor / Non-Contributor) — e.g. Brazil DIFAL/FCP fire only for non-contributor end consumers | Any = all buyers |
| Effective From / To | The invoice date falls in the window | (From blank = no start; To blank = no expiry) |
| Is Active | Checked | Unchecked = never fires |
Ancestry matching (Origin/Destination) is the same hierarchy trick from
Tax Jurisdictions: a rule set at GB
fires for a buyer anywhere in the UK, because GB is an ancestor of every
UK place. On top of these conditions, the engine also runs a separate
nexus check (is your entity registered where the buyer is?) before
any rule fires — see Entity Tax
Registration.
Sequence & dependencies — order matters
When several rules fire, the engine runs them in Sequence order (lowest first). For most taxes order is cosmetic, but for some it’s essential, because one tax is computed from another’s result. That’s what Depends On Prior Rule is for.
The rule self-reference is guarded: a rule can’t depend on itself, and the prior rule must be active (two validation rules enforce this).
How the base is computed
By default a rule’s tax is simply base × rate, where the base is the line amount. The calculation modifiers adjust that base for the cases that need it. Applied in this order:
| Modifier | Effect on the base | Used for |
|---|---|---|
| Include Freight | + freight on the line | Brazil (freight is taxable in the ICMS base) |
| Subtract Discount | − discount on the line | Discounts that reduce the taxable amount |
| Base Reduction (%) | × (1 − reduction%) | Partial base exemptions (some Brazil items) |
| MVA / Markup (%) | × (1 + MVA%) | Brazil ICMS Substituição Tributária markup |
| Depends On Prior Rule | − the prior rule’s amount | DIFAL differential |
| Tax Included in Price (por dentro) | Tax is embedded in the price — doesn’t add to the invoice total | Brazil ICMS |
The final amount is base × rate ÷ 100, rounded to two decimals (half-up). The full numeric walkthroughs — including Brazil’s por-dentro grossing-up — are in How Tax Calculates and the Brazil walkthrough.
Effective dating — rate history without losing the past
Rates change, and old invoices must keep their old rate. REDA handles this with Effective From / Effective To rather than a separate history object. To change a rate: set the old rule’s Effective To to the day before the change, and create a new rule with the new rate from the change date.
GB-VAT-STD-20 is effective from 4 Jan 2011 — the day
the rate rose to 20%. An invoice dated before then would match the older 17.5% rule
(with its own effective window); an invoice today matches the 20% rule. The engine
always picks the rule in force on the invoice date.
The fields — with UK & Brazil values
Every field, with the UK standard-VAT rule beside Brazil’s interstate ICMS rule:
| Field | Req | 🇬🇧 GB-VAT-STD-20 | 🇧🇷 BR-ICMS-6101-SP-TO-SE |
|---|---|---|---|
| Code | Yes | GB-VAT-STD-20 | BR-ICMS-6101-SP-TO-SE |
| Tax Type | Yes | GB-VAT-STD | BR-ICMS |
| Rate | Yes | 20% | 12% |
| Sequence | Yes | 10 | 10 |
| Effective From | Yes | 2011-01-04 | 2020-01-01 |
| Tax Profile | No | GB-STD-20 | BR-STD-GOODS |
| Destination Jurisdiction | No | GB | (blank — scoped by Fiscal Operation) |
| Fiscal Operation | No | (blank) | BR-6101 (interstate) |
| Seller Regime | No | Any | Any |
| Tax Included in Price (Por Dentro) | No | No | Yes (por dentro) |
| Origin / Buyer & Seller Profile / MVA / Base Reduction / Freight / Discount / Depends On | No | (all blank) | (set as Brazil law requires) |
The contrast is the lesson: the UK rule sets a handful of fields and leaves the rest blank (= any), so it matches broadly. The Brazil rule pins fiscal operation and the por-dentro flag, so it fires precisely on interstate sales and embeds in the price.
Real data: UK and Brazil rule sets
🇬🇧 United Kingdom — 4 rules, one per treatment
| Rule | Tax Type | Tax Profile | Rate | Seq |
|---|---|---|---|---|
GB-VAT-STD-20 | GB-VAT-STD | GB-STD-20 | 20% | 10 |
GB-VAT-RED-5 | GB-VAT-RED | GB-RED-5 | 5% | 10 |
GB-VAT-ZERO-0 | GB-VAT-ZERO | GB-ZERO | 0% | 10 |
GB-VAT-EX-0 | GB-VAT-EXEMPT | GB-EXEMPT | 0% | 10 |
One product, one rule fires (the one whose Tax Profile matches). No sequencing drama — they’re mutually exclusive by profile.
🇧🇷 Brazil — six rules on one interstate line
| Seq | Rule | Tax | Rate | Notable fields |
|---|---|---|---|---|
| 10 | BR-ICMS-6101-SP-TO-SE | ICMS | 12% | Tax Included in Price (por dentro); Fiscal Operation = BR-6101 |
| 20 | BR-IPI-STANDARD | IPI | 10% | Additive; Tax Profile = BR-IPI-GOODS |
| 30 | BR-PIS-LR-STDG | PIS | 1.65% | Seller Regime = Lucro Real; por dentro |
| 40 | BR-COFINS-LR-STDG | COFINS | 7.6% | Seller Regime = Lucro Real; por dentro |
| 50 | BR-DIFAL-RJ-STDG | DIFAL | 8% | Fiscal Operation = BR-6101; Destination = RJ; Buyer = Non-Contributor |
| 60 | BR-FCP-RJ-STDG | FCP | 2% | Fiscal Operation = BR-6101; Destination = RJ; Buyer = Non-Contributor |
Every dimension is doing work here: Fiscal Operation gates the interstate rules, Destination scopes DIFAL/FCP to Rio, Buyer Contributor Scope restricts DIFAL/FCP to consumer (non-contributor) sales, Seller Regime selects the Lucro Real PIS/COFINS, and Sequence orders the cascade. Change the seller to Lucro Presumido and the 0.65% / 3% rules take their place; sell to an ICMS-registered business instead of a consumer and DIFAL/FCP drop out, leaving four rules.
How matching runs at post time
You don’t trigger any of this — it happens automatically when an invoice posts — but here’s the sequence, so the field choices make sense:
Built-in guardrails
| Rule | What it enforces |
|---|---|
| Code uppercase / no spaces | Clean external-ID codes |
| Rate non-negative | Use 0 for zero-rated/exempt — never a negative rate |
| Effective date range | Effective To can’t be before Effective From — a rule can’t expire before it begins |
| Depends-not-self | A rule can’t depend on itself, and the prior rule must be active |
| Lookups active | The tax type, profiles, jurisdictions, and fiscal operation a rule points at must all be active |
Where to go next
- Tax Types — the tax a rule applies.
- Tax Calculation Components — advanced base customisation on a rule.
- How Tax Calculates on a Document — rules matched in a live calculation.
- Fiscal Operations — the transaction nature a rule reads.
- Source Line Tax (Audit Records) — the record each fired rule writes.
Frequently asked questions
Neither — both fire. The engine never stops at the first match; it applies every rule whose conditions are satisfied, in Sequence order. That’s deliberate: Brazil genuinely layers six taxes on one sale. If you only want one to apply, make their conditions mutually exclusive (as the UK rules are, by Tax Profile).
Work through the conditions: is it Active? Is the invoice date inside Effective From/To? Do the origin/destination jurisdictions match (by ancestry)? Does the line’s Tax Profile match (or is the rule’s blank)? Do the party profiles, fiscal operation, and seller regime match? And separately — does your entity have nexus in the buyer’s jurisdiction? A single unmet condition stops the rule.
Don’t edit the rate in place. Set the current rule’s Effective To to the day before the change, then create a new rule with the new rate effective from the change date. Old invoices keep the old rate; new ones get the new one.
Set a condition only when the rule should be restricted by it. Blank = “applies regardless.” Simple regimes (UK) leave almost everything blank; complex ones (Brazil) pin fiscal operation, destination, and seller regime to target precisely. Over-setting conditions is the usual reason a rule doesn’t fire when you expect it to.
Was this article helpful?