Tax on Sales Invoices
When you raise a sales invoice, you never type a tax figure — REDA works out the tax for you, line by line, from your setup. This article explains how tax behaves on a sale specifically: when it is calculated, what decides it, how "exclusive" and "inclusive" differ, the audit records it leaves behind, and where the tax lands when you post. It also clears up one point that surprises people — where withholding tax lives. For the inner workings of the tax engine itself (rules, rates, jurisdictions), this article links out to the Tax Management section rather than repeat them.
Access you'll need. Any REDA Financials permission set can view the tax on an invoice. Raising or posting the invoice that writes the tax requires the Accounts Receivable v2 permission set (AR clerks & managers) or Accounting Admin v2 (system administrators). The underlying tax rules and rates are configured separately in the Tax Management area.
What decides the tax on a sale
REDA doesn't guess. It reads five things about the invoice and resolves the correct tax from your configured tax rules:
| What REDA looks at | Its part in deciding the tax |
|---|---|
| The Entity (seller) | Its tax registrations and its own Tax Jurisdiction — the "from" of the sale |
| The Customer (buyer) | The Tax Jurisdiction on their account record — the "to". Comparing the seller's and buyer's jurisdictions decides the Fiscal Operation (a domestic sale, an export, and so on), which selects the applicable rules |
| Each line's Product | Through its Product Fiscal Profile → Tax Profile: which tax types and rates apply to that item |
| The line's Tax Profile (optional) | If set directly on a line, it takes priority over the product's profile — a per-line override |
| The Invoice Date | Picks the version of each tax rule that was in effect on that date |
You don't drive any of this at invoicing time — it's the payoff of setting up your tax rules, profiles and registrations once. Jurisdiction matching is hierarchy-aware on both sides: a rule written for a whole country applies to a customer in any of its states or cities. The How tax is calculated article walks the full resolution in depth.
When the tax is calculated
There are two moments, and it helps to know the difference:
| Moment | What happens |
|---|---|
| As you build the invoice (Draft) | The form shows a live preview of the tax in the Invoice Summary — recalculated every time you change a customer, product, quantity or price. This is a preview only; nothing is written yet. |
| When you post | The engine runs for real: it calculates each line's tax and writes the permanent Source Line Tax records, stamps each line's tax, and rolls it up to the invoice. Tax is recalculated fresh at every post. |
Exclusive or inclusive of tax
Each line carries a Tax Base setting that tells REDA whether the price you entered is before tax or already includes it:
- Exclusive of Tax (the default) — the price is pre-tax, and the tax is added on top. A £100 line at 20% becomes £100 + £20 = £120.
- Inclusive of Tax — the price already contains the tax, so REDA backs it out: the net is the price ÷ (1 + the rate). A £120 line at 20% becomes £100 net + £20 tax = the same £120.
The full worked comparison lives in Sales Invoice Lines. The key point for tax: with inclusive pricing the customer's total doesn't change — REDA simply splits the price you entered into net revenue and tax. (A third Tax Base choice, Tax Exempt, switches tax off for the line entirely — the engine is skipped and no tax records are written.)
The audit trail: Source Line Taxes
When the invoice posts, the engine writes a Source Line Tax record for each tax on each line — capturing the Tax Type, the rule that fired, the rate, the taxable base and the tax amount. They make the tax fully traceable: every figure on the invoice can be tied back to the line and the rule that produced it. A line with two taxes (for example a US state and city sales tax) gets two Source Line Tax records, and the line's tax is their sum.
You don't create or edit these — the engine owns them. For the full field-by-field picture, see Source Line Tax records, and for how they roll into the invoice totals, Sales Invoice Lines.
Where the tax lands when you post
On a sale, the tax you charge isn't your money — you're collecting it on behalf of the tax authority, so it posts as a liability (money you owe), separate from your revenue. Take a one-line invoice from Meridian Properties UK Ltd — £1,000 of consulting, exclusive, at 20% VAT. When it posts, the journal is:
| Account | Debit | Credit |
|---|---|---|
| Accounts Receivable (what the customer owes) | £1,200.00 | |
| Consulting Revenue | £1,000.00 | |
| VAT Payable (output tax — a liability) | £200.00 |
The customer owes the full £1,200; £1,000 is your revenue and £200 is tax you'll hand over to the authority. REDA decides which account the tax credits by looking up the Tax Type and the sales side in your Tax GL mapping — so VAT on a sale always lands in the output-tax account you mapped for it. The full set of journals (including cash-basis and the discount line) is in Posting a Sales Invoice.
Withholding tax is not on the invoice
One thing catches people out: withholding tax does not appear on the sales invoice. Where a customer is required to withhold a portion of your payment and remit it to the tax authority on your behalf, that's a payment-time event, not an invoice-time one. So the sales invoice always posts the gross amount receivable, exactly as above.
The withholding is recorded later, on the Cash Receipt, when the customer pays: they pay you the cash net of the withheld amount, and the withheld portion is captured on a Cash Receipt of type WHT Received — you enter the withheld amount yourself, from the customer's tax certificate (there is no rule engine on the sales side), and apply that receipt to the invoice to clear the rest of the receivable. That keeps the invoice clean and puts the withholding where it actually happens. See Withholding on a Cash Receipt and Sales-side withholding for the detail.
Where to go next
- Sales Invoice Lines — where line tax is applied.
- Creating a Sales Invoice — build the invoice.
- Posting a Sales Invoice — post tax to the ledger.
- Product Fiscal Profiles — profiles that drive tax.
Frequently asked questions
No — there's no tax field to type into. The engine calculates it from the customer, the products and your tax rules, and shows it live. If the tax looks wrong, the fix is in your tax setup (the profile or rule), not on the invoice.
Usually not. It means no tax rule applied — the item may be zero-rated or exempt, or the product hasn't been classified and its Apply Default Tax is off (so REDA deliberately leaves it at zero rather than guess). It can also mean your entity holds no active tax registration covering the customer's jurisdiction — no registration means no tax. Check the product's fiscal profile and the entity's tax registrations.
Not on the invoice — the invoice posts the gross amount. You record the withholding on a Cash Receipt of type WHT Received when they pay, entering the withheld amount from the customer's certificate.
On a draft, the tax you see is a live preview — it isn't written to the record yet. The tax (and its Source Line Tax records) is created when you post. So a draft can show a preview total while the stored tax is still zero until posting.
It compares the selling entity's jurisdiction with the customer's to derive the Fiscal Operation — domestic, export, and so on — which selects the right rules. An explicit Fiscal Operation can also be set on the invoice header, but that override is meant for Brazil (to set the CFOP code) — everywhere else, leave it blank and let REDA derive it.
Was this article helpful?