Tax Calculation Components
A Tax Calculation Component is an optional, advanced add-on to a Tax Rule — a child record that customises how the rule’s base is computed, in steps. It exists for the rare cases where a tax base is too unusual to express with the rule’s built-in modifiers.
The headline you should take away first: most rules need none. By default, a rule’s base is just the line amount, and the calculation modifiers on the rule itself — freight, discount, base reduction, MVA markup, por-dentro, depends-on-prior — already handle the complex regimes REDA ships. Components are a precision tool for the exceptions.
Access you'll need. Setting up components 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.
When you’d use one
Two component behaviours are worth building on today:
- A base that should be capped at a maximum amount (Base Cap) — for taxes that apply only up to a ceiling.
- A step that applies a different rate than the parent rule (Rate Override) — when several steps of one rule need their own percentages.
If your need is covered by the rule-level modifiers (the usual case), use those — they’re simpler and that’s what the standard packs rely on.
The fields
A component is a child of one Tax Rule (master-detail). Its fields define one step in the base calculation:
| Field | Type | Required | What it’s for |
|---|---|---|---|
| Tax Rule | Master-Detail | Yes | The rule this step belongs to |
| Sequence | Number | Yes | Order of this step within the rule’s chain |
| Base Formula | Picklist | Yes | Line Amount · Prior Rule Output · Line Amount Minus Prior Rule Output · Freight Only · Custom Expression |
| Prior Rule | Lookup (Tax Rule) | If formula uses a prior | The rule whose output feeds this step |
| Rate Override | Percent | No | Use a different rate than the parent rule for this step |
| Base Cap | Currency | No | Clamp the base to a maximum |
| Description | Text Area | No | What this step computes and why |
| Is Active | Checkbox | No | Off → the step is skipped |
How the engine runs a chain
When a rule has active components, the engine walks them in Sequence order and they take over the rule’s base calculation. Along the way:
- Base Cap clamps. If a step’s running base exceeds its Base Cap, the base is cut to the cap before the rate applies.
- Rate Override wins — last one standing. Any step can override the rule’s Rate; if several steps carry overrides, the latest in the sequence is the one used.
- Inactive steps are skipped silently — which is what makes deactivation a safe way to test a chain.
The result then flows through the normal pipeline — rounding, audit rows, GL posting — exactly as if the rule had computed the base itself. Two validation rules keep chains honest, with these exact messages:
| The message | What it means |
|---|---|
| “Prior Rule Reference is required when Base Formula is set to "Prior Rule Output" or "Line Amount Minus Prior Rule Output". Select the rule whose output feeds this component’s base calculation.” | A prior-rule formula must name its source rule — though remember the callout above: route this pattern through the Tax Rule’s Depends On Prior Rule instead. |
| “Rate Override must be between 0 and 100. Enter the rate as a percentage (e.g., 15 for 15%).” | Overrides are percentages, not fractions — 15 means 15%. |
How Brazil’s complexity is handled without components
It’s worth seeing this explicitly, because Brazil is exactly the kind of regime you’d expect to need components — and it doesn’t. Each piece of its interstate cascade maps to a rule-level field:
| Brazil mechanism | Handled by (on the Tax Rule) |
|---|---|
| ICMS embedded in price (por dentro) | Tax Included in Price flag |
| Substituição Tributária markup | MVA % |
| DIFAL differential | Its own per-state rules (flat differential rates), gated by Buyer Contributor Scope; the Depends On Prior Rule + Sequence mechanism is available for net-of-prior-tax variants |
| Partial base exemption | Base Reduction % |
| Freight in the ICMS base | Include Freight |
So the entire six-tax São Paulo → Rio cascade runs on rule fields alone. A component would only enter the picture for a bespoke base a future client needs that none of these express.
Setup
- Start with rule-level modifiers. Try to express the base with the Tax Rule’s own fields first — it’s simpler and matches how the shipped packs work.
- Add components only for capped or multi-rate bases. Create them as children of the rule, ordered by Sequence, each with a Base Formula.
- Route prior-rule dependencies through the rule — the Tax Rule’s Depends On Prior Rule field, not a component formula (see the callout above).
- Deactivate to test. Unchecking Is Active skips a step without deleting it — handy when validating a chain.
- Verify with the preview. The invoice form’s live tax preview runs the same math as posting — enter a draft line and confirm the chain produces the base you expect before going live.
Where to go next
- Tax Rules — the parent record components extend.
- How Tax Calculates on a Document — components running in a calculation.
- Brazil (ICMS, IPI, PIS/COFINS) — layered bases that need components.
- Source Line Tax (Audit Records) — the per-tax rows components produce.
Frequently asked questions
No. Brazil’s shipped rules — ICMS por-dentro, MVA, DIFAL, FCP, IPI, PIS, COFINS — are all built from rule-level fields, with no calculation components. You’d only add a component for a custom base requirement those fields can’t express.
The rule’s modifiers (freight, discount, base reduction, MVA, depends-on-prior, por-dentro) are quick switches on the rule itself — the everyday tools. A component is a separate child record that builds the base in explicit steps, for formulas the switches can’t capture. Components are the advanced fallback.
Yes — the Rate Override field lets a step apply a different rate than the parent rule. Most chains don’t need it; leave it blank to use the rule’s rate.
Was this article helpful?