Tax GL Mapping
The engine has worked out how much tax applies. Tax GL Mapping answers the last question: which account does it post to? It is the routing table that connects each tax to your chart of accounts — turning a calculated tax amount into a real ledger entry.
This matters more than it sounds, because the same tax can post to different accounts depending on the situation. UK VAT you collect on a sale is a liability you owe HMRC; the identical VAT you pay on a purchase is an asset you reclaim. One tax, two accounts — and the mapping is what tells them apart.
Access you'll need. Creating and editing tax GL mappings 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.
The four-part key
A mapping resolves an account from a combination of four things. Together they form the key the posting engine looks up:
| Dimension | Question it answers | Values |
|---|---|---|
| Entity | Whose books? (or org-wide default) | An entity, or blank = default for all |
| Tax Type | Which tax? | e.g. UK VAT, Brazil ICMS |
| Side | Selling or buying? | Sales / Purchase, plus Sales Deduction for embedded (por dentro) taxes and Purchase Cost, which is reserved and unused by any shipped pack |
| Is Recoverable | (Purchase only) reclaimable? | Yes → asset · No → expense |
So the engine asks, in effect: “For this entity, the VAT tax type, on the purchase side, where it’s recoverable — which GL account?” That precise question has one answer: the mapped account.
The fields — with UK & Brazil values
Every field, what it does, and real seed values — a UK VAT purchase mapping beside a Brazil ICMS purchase mapping (both recoverable, so both route to an asset):
| Field | Type | Required | What it’s for | 🇬🇧 UK VAT (Purchase) | 🇧🇷 Brazil ICMS (Purchase) |
|---|---|---|---|---|---|
| Tax Type | Lookup | Yes | The tax this routes | GB-VAT-STD | BR-ICMS |
| Side | Picklist (Sales / Purchase / Sales Deduction / Purchase Cost) | Yes | Output (sales) vs input (purchase); the two extra values route embedded taxes (see below) | Purchase | Purchase |
| Is Recoverable | Checkbox | No | Purchase only — asset vs expense | Yes | Yes |
| GL Account | Lookup | Yes (when active) | The account that receives the posting | 1511-VAT-ITC-GB | 1523-ICMS-ITC-BR |
| Entity | Lookup | No | Blank = org-wide default; set = override | — (default) | — (default) |
| Is Active | Checkbox | No | Off → engine ignores this mapping | Yes | Yes |
| Seed Key | Text (system) | No | Used by the seed for upsert — don’t edit | system | system |
| Notes | Long Text | No | Why this account, policy reference | … | … |
The recoverable split — one tax, two accounts
This is the feature that makes the mapping more than a lookup. Because Side and Is Recoverable are part of the key, the same Tax Type routes to different accounts depending on how it’s used. UK VAT is the cleanest illustration:
| Tax Type | Side | Recoverable | Posts to | Account kind |
|---|---|---|---|---|
GB-VAT-STD | Sales | — | 2311-VAT-GB — VAT Payable | Liability (you owe HMRC) |
GB-VAT-STD | Purchase | Yes | 1511-VAT-ITC-GB — VAT Input Tax Recoverable | Asset (you reclaim) |
Where a tax is not recoverable on the purchase side (Canada PST, Brazil cumulative PIS), the mapping points at an expense account instead — the tax becomes a real cost rather than a reclaimable asset. The Is Recoverable flag on the Tax Type is what flows through to pick the right purchase mapping.
4911-ICMS-SALES-BR). At posting the
embedded tax debits that deduction account, so gross revenue is shown in full and net revenue
is reduced — the Brazilian DRE / IFRS 15 presentation. Purchase Cost
is the purchase-side counterpart (reserved). Additive taxes never use these two values.
Entity override vs org-wide default
The Entity field gives you two levels. A mapping with no entity is the org-wide default — it applies to every entity. A mapping with an entity is an override that wins for that entity only. The engine always prefers the entity-specific match, then falls back to the default.
2311-VAT-GB — used by every entity.Override: UK VAT (Sales), Entity = Reda UK Retail Ltd →
2311-VAT-RETAIL — that one entity posts VAT to its own account; everyone else still uses the default.
The seed creates the org-wide defaults (with a system Seed Key); administrators add entity overrides as needed.
In practice: how posting uses the mapping
When you post an invoice, after the tax engine has written its Source Line Tax rows, the posting engine does this for the tax lines:
The worked outcomes for our two countries:
| Transaction | Tax line(s) posted |
|---|---|
| 🇬🇧 UK sale £1,000 + VAT | CR 2311-VAT-GB £200 (output VAT liability) |
| 🇬🇧 UK purchase £1,000 + VAT | DR 1511-VAT-ITC-GB £200 (recoverable asset) |
| 🇧🇷 Brazil interstate sale | One credit each to ICMS, IPI, PIS, COFINS, DIFAL, FCP payable accounts |
| 🇧🇷 Brazil purchase (recoverable taxes) | DR each to its ITC asset account (ICMS, IPI, PIS, COFINS credits) |
Real data: UK and Brazil mappings
🇬🇧 United Kingdom
| Tax Type | Side | Recoverable | GL Account |
|---|---|---|---|
GB-VAT-STD | Sales | No | 2311-VAT-GB — VAT Payable |
GB-VAT-STD | Purchase | Yes | 1511-VAT-ITC-GB — VAT Input Tax Recoverable |
| … same pair for Reduced and Zero rates; Exempt has a Sales mapping only | |||
🇧🇷 Brazil — the recoverable split across six taxes
| Tax Type | Sales → account | Purchase → account |
|---|---|---|
BR-ICMS | 2331-ICMS-BR Payable | 1523-ICMS-ITC-BR Input Credit |
BR-IPI | 2334-IPI-BR Payable | 1524-IPI-ITC-BR Input Credit |
BR-PIS-NC | 2335-PIS-BR Payable | 1521-PIS-ITC-BR Input Credit |
BR-COFINS-NC | 2336-COFINS-BR Payable | 1522-COFINS-ITC-BR Input Credit |
BR-DIFAL | 2332-DIFAL-BR Payable | none — not recoverable |
BR-FCP | 2333-FCP-BR Payable | none — not recoverable |
Notice ICMS, IPI, PIS, and COFINS each have both a sales payable and a purchase input-credit account — the recoverable split in full. DIFAL and FCP are non-recoverable surcharges, so they map on the sales side only.
Guardrails & setup
- GL Account is required on active mappings — a validation rule blocks an active mapping with no account (it would fail at post time anyway).
- Two mappings per tax, per entity — one Sales, one Purchase. Recoverable taxes need the purchase mapping pointed at an ITC asset; non-recoverable at an expense.
- Seeded defaults, then override. The Tax Seeding Wizard creates org-wide defaults wired to seeded tax accounts. Re-point them at your own chart of accounts, or add entity overrides.
- Changing an account? Deactivate the old mapping and create a new active one — this preserves the audit trail of where tax used to post.
Where to go next
- Tax Types — the taxes each mapping routes.
- Tax Rules — rules that produce the tax to post.
- How Tax Calculates on a Document — where mapping is applied.
- Source Line Tax (Audit Records) — the posted rows behind the mapping.
Frequently asked questions
A tax on the document has no mapping for that entity, side, and recoverability. Create the missing Tax GL Mapping — the error names the exact Tax Type and whether it was the Sales or Purchase (recoverable/not) combination. This is by design: the engine refuses to guess where tax should land.
Because the same tax behaves differently by side. Output VAT on a sale is a liability; input VAT on a purchase is an asset (if recoverable) or an expense (if not). Each of those is a different account, so each is its own mapping — keyed by Side and Is Recoverable.
Yes. Leave the org-wide default in place, and add an entity-specific mapping for the company that needs its own account. The engine uses the entity override where it exists and the default everywhere else.
No — it only applies to Purchase mappings (input tax: reclaim as an asset, or absorb as an expense). Output tax you collect on a sale is always a liability you owe, so recoverability doesn’t apply on the sales side.
Was this article helpful?