Source Line Tax (Audit Records)
A Source Line Tax record is the engine’s receipt: one row for every tax that fired, on every invoice line. It captures exactly which rule applied, at what rate, on what base, for how much — the tax-side audit trail behind every number on your returns.
If Accounting Transactions are the atoms of your ledger, Source Line Tax records are the atoms of your tax. They’re created automatically by the engine, never by hand, and once written they don’t change — which is precisely what makes them trustworthy for an audit.
Access you'll need. These are system-generated, immutable audit records. Any REDA Financials permission set can view them (limited to the records your role can see); none are created or edited by hand.
Engine-managed and immutable
Source Line Tax records are locked. Only the tax engine creates them; users can’t add, edit, or delete one directly — an attempt is refused with a clear message. This isn’t bureaucracy; it protects a chain of consistency:
- The tax row drives the line’s tax total…
- …which drives the invoice total…
- …which must match the tax posted to the ledger.
If anyone could hand-edit a tax row, the line total would say one thing and the ledger another. So the rule is simple: to change the tax, change the document and re-post — the engine rewrites the rows.
What each row captures
| Field | What it records |
|---|---|
| Tax Type & Tax Rule | Which tax, and the exact rule that fired |
| Tax Rate | The rate applied — snapshotted from the rule at calculation time |
| Tax Base | The amount the rate was applied to (after freight, discount, reductions, MVA — Brazil’s ICMS-ST markup value…) |
| Tax Amount | The tax itself: Base × Rate |
| Sequence | The rule’s order in the cascade (preserves the firing order) |
| Is Recoverable / Is Withheld / Tax Included in Price | Behaviour flags snapshotted for posting and reporting |
| Remittance Jurisdiction Code | Reserved for identifying the authority the tax is owed to — the engine currently leaves it blank |
| Accounting Period | The period, for grouping input/output tax on returns |
| Source links | The document and line it came from — a Sales Invoice, Purchase Invoice, or Journal Entry line |
Each row links to exactly one source line — a Sales Invoice Line, Purchase Invoice Line, or Journal Entry Line (a validation rule enforces the “exactly one parent” shape), and the parent document lookups fill in automatically.
How the rows become the invoice total
You rarely look at a raw tax row — you see its effect on the invoice. The chain is automatic:
So when the engine writes or clears tax rows, the line and header totals update themselves. Two refinements keep the totals honest: embedded (por dentro) tax rows are excluded from the roll-up — they sit inside the price, so adding them again would overstate the receivable — and for credit lines the tax is carried as negative, so the totals reduce correctly. In multi-currency operations the totals stay in the document’s own currency — the roll-up is built to avoid silently converting to a reporting currency.
Reading the rows: UK vs Brazil
| 🇬🇧 UK sale £1,000 | 🇧🇷 Brazil interstate sale | |
|---|---|---|
| Rows on the line | 1 | 6 |
| What you see | VAT · 20% · base £1,000 · £200 | ICMS, IPI, PIS, COFINS, DIFAL, FCP — each with its rate, base, and amount |
| Use | One line on the VAT return | Each tax reconciles to its own GL account and return |
The Brazilian rows are where the engine’s detail pays off: six taxes, six audit rows, six reconcilable amounts — impossible to represent with a single tax field on the line, which is exactly why Source Line Tax is a separate record.
Corrections and reversals
When you correct a posted invoice (move to Draft, edit, re-post), the engine clears the old tax rows and writes fresh ones — so the rows always match the current document. When a document is voided or reversed, the tax unwinds alongside the ledger, keeping the tax sub-ledger and the GL in lock-step. You never reconcile a tax row by hand; you act on the document and the engine keeps the rows honest.
Where to see them
Source Line Tax rows appear as a related list on the invoice and feed the tax totals you see on the document and its PDF. For period reporting, they’re grouped by tax type and accounting period to produce output-tax and input-tax figures for returns. You read them through those reports far more often than one at a time.
Where to go next
- How Tax Calculates on a Document — the calculation that writes these records.
- Tax Rules — the rule each record points back to.
- Tax GL Mapping — how each line routes to an account.
- Sales Invoice Tax — the same tax seen on an invoice.
Frequently asked questions
Not on the tax row — it’s engine-managed and locked. Fix the cause on the document (the product’s profile, the rule, the rate, the registration) and re-post; the engine recalculates and rewrites the rows. This keeps the line total, the invoice total, and the ledger perfectly aligned.
Because six rules fired. Each tax (ICMS, IPI, PIS, COFINS, DIFAL, FCP) gets its own row so it can carry its own rate, base, recoverability, and GL account — and reconcile independently. A single tax field couldn’t hold all that.
No — the rate is snapshotted when the row is created. A historical invoice keeps the rate that applied on its date. New invoices use the new rate. That’s what makes the rows reliable evidence.
As negative tax — the rows carry the tax with the opposite sign so the credit reduces your tax totals correctly, both on the document and in your period figures.
Was this article helpful?