The Tax tab on a customer is not where tax comes from — transcript

Presentation 4 of 5 in Customers, suppliers and staff are one record · about 13 minutes · for the whole-system operator — you run the books.

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever at GadgetSphere sets up customers and suppliers and has looked at the Tax tab wondering whether filling it in changes anything. In about thirteen minutes you will know exactly what that tab stores, the one place it is ever read, why the rate printed on it can be out of date, and where a line’s tax really comes from.

Step 1 — Look at a tab that reads like a setting

After this step you will know what the tab offers. It holds one row per country, and the country list is fixed at four — Malaysia, Singapore, Thailand, Indonesia. Each row carries a tax type, a tax code, a rate, and a choice of tax included or tax excluded. A second row for a country you already have is refused. Everything about it reads like the place you tell BigLedger how to tax this customer. That is a reasonable thing to assume from the screen, and it is very nearly wrong.

Screen: Customer Maintenance, the Tax tab, showing Country, Tax Type, Tax Code, Tax Rate and Tax Option

Reference: Supplier — Tax tab

Step 2 — Notice the rate you cannot type

After this step you will know where that rate came from. The Tax Rate box is read-only and disabled — you have never typed in it. It is filled the instant you choose a tax code, by copying that code’s filing rate out of Tax Configuration into the form. Then the whole row, rate included, is saved as a block of stored text on the entity. That copy never refreshes. Change the rate afterwards in Tax Configuration and this tab still shows the old figure, with nothing on screen to say the two have parted company.

Reference: Customer Maintenance — Edit customer: the Tax tab

Step 3 — Find the one path that reads it

After this step you will know exactly who consumes this. When you add a line to a sales invoice or a purchase order, the price picker asks the item for a pricing scheme for this customer or supplier. If the item returns none at all, the picker falls back to building one out of this stored row — its tax code, its frozen rate, its tax type — and if you choose that scheme, all three are stamped onto the line. That is the entire readership. No posting routine, no e-invoice payload and no report ever looks at this row.

Reference: Customer Maintenance — Edit customer: the Tax tab

Step 4 — Compare the three doors onto the same row

After this step you will know why this tab behaves differently depending on where you opened it. On a Malaysian record the customer screen offers only the three output tax types and the supplier screen only the three input types — a deliberate guard that stops you attaching a sales code to somebody you buy from. The shared Entity Maintenance tab edits the very same row and applies neither, so both sides are offered. It also has a missing null check: on any tax code with no withholding type, choosing a tax type throws, and the tax code list stays empty. Since withholding codes are configured on one tenant, that is almost every code.

Reference: Entity Maintenance — Edit — other tabs

Step 5 — Ask how much this is actually used

After this step you will know how much weight to give the tab. We counted the stored rows across all ninety tenant databases. There are three of them, held by fewer than three tenants, out of fifty-six million entity extension rows in total. The controls in the same count make that meaningful: nine thousand three hundred tax registration numbers across fifty-eight tenants, and eight point six million category rows across seventy-eight. So this is not a tab nobody has got round to. It is a tab the platform has been running without.

Reference: Supplier — Tax tab

Step 6 — Go to where tax actually comes from

After this step you will know where to spend the effort. A document line’s tax code and rate come from the item and the pricing scheme that matched it, and behind those from the tax code in Tax Configuration, which carries two rate columns that are not the same field. If a line charged the wrong rate, this tab is not the cause and correcting it is not the cure. Fill the tab if you want the record of what a counterparty is registered for in each country; do not fill it expecting a document to obey it.

Reference: Tax Configuration — Lifecycle and effects

How the steps fit together

    flowchart TD
  s1["Step 1 — Look at a tab that reads like a setting"]
  s2["Step 2 — Notice the rate you cannot type"]
  s3["Step 3 — Find the one path that reads it"]
  s4["Step 4 — Compare the three doors onto the same row"]
  s5["Step 5 — Ask how much this is actually used"]
  s6["Step 6 — Go to where tax actually comes from"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

1. You change a tax code's rate in Tax Configuration. What happens to the rate showing on a customer's Tax tab? It updates, because the tab reads the code live
Nothing — the rate was copied into stored text when the code was chosen and never refreshes
The row is invalidated and must be re-entered

2. Which path ever reads a customer's Tax tab row? Every sales invoice line, before the item is consulted
Only the pricing-scheme picker, as a fallback when the item returns no pricing scheme at all
The e-invoice payload builder

3. Why can the same Tax tab offer different tax types depending on the applet you opened it from? Because each applet has its own tax codes
Because the customer and supplier screens restrict the Malaysian list to output and input types, and the shared entity screen restricts nothing
Because the country list differs between them

4. Across all 90 tenant databases, how many of these stored tax rows exist? Millions — it is filled as a matter of course
Three, held by fewer than three tenants
None at all; the tab cannot save

Answer key

Nothing — the rate was copied into stored text when the code was chosen and never refreshes — Customer Maintenance — Edit customer: the Tax tab
Only the pricing-scheme picker, as a fallback when the item returns no pricing scheme at all — Customer Maintenance — Edit customer: the Tax tab
Because the customer and supplier screens restrict the Malaysian list to output and input types, and the shared entity screen restricts nothing — Supplier — Tax tab
Three, held by fewer than three tenants — Supplier — Tax tab

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Next: Merging repoints, it does not marry · Back to the series · Play this as a presentation

Last updated on September 18, 2026

The Tax tab on a customer is not where tax comes from Merging repoints, it does not marry