The tax on the line is not the price's tax — transcript

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 has to explain a tax rate on an invoice that nobody can find on any screen. In about twelve minutes you will know the five candidates the line editor works through, in the order it works through them, and which one your tenant is really using — which is very often not the one everybody assumes.

Step 1 — Accept that the price row is third in the queue

After this step you will stop assuming the price supplied the tax. When the price picker builds its list it decides a tax code, rate and type for each row by taking the first of five things that is present. First the entity branch’s output tax code on the document. Then the customer’s own Tax tab. Then the price row’s own tax code. Then the item header’s. Then the company’s default output tax code. And if none of the five is present, a blank code and a rate of zero. The price row you spent an afternoon filling in is third in that queue, behind two things most people do not know are in it.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 2 — Find out whether your prices carry tax at all

After this step you will know whether that third candidate is even in play on your tenant. Across all ninety tenant databases, the price row’s own output tax code is set on about four point one million rows in forty-six tenants, blank on four point three million in sixty-two, and null on three point four million in thirty-five. So for roughly a third of all prices on the platform there is something in that third position to be overruled, and for the rest there is nothing and the queue simply moves on to the item. That is the first thing to establish before you argue about precedence: whether the row you are looking at has a tax code on it at all.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 3 — Meet the two candidates ahead of it

After this step you will know where to look before the price. The first candidate is the entity branch on the document — the delivery or billing branch of the counterparty, which carries its own output tax code, and which almost nobody thinks of as a tax setting. The second is the customer’s Tax tab, which stores a frozen copy of a tax code, type and rate as an extension on the customer record. Across the entire production estate that customer Tax tab has been filled in three times. But where it is filled in, it beats the price and it beats the item, and nothing on the invoice says so.

Reference: Customer Maintenance — Edit customer: the Tax tab

Step 4 — Understand the last resort, which reads a different column

After this step you will know why the fallback rate can differ from the one on a document. When the first four candidates are all absent, the picker goes to the company’s default output tax code and reads that tax code record live — and it takes the code’s filing rate. A tax code carries two rate columns: the transaction rate a document line normally takes, and the filing rate every master-data screen caches. They are identical on every row in every tenant today, so this is a thing to know rather than a thing to fix. It matters the day somebody sets them apart, because the company fallback and an ordinary line would then disagree by design.

Reference: Tax Configuration

Step 5 — Diagnose a wrong rate in the right order

After this step you will have a procedure instead of a guess. Start at the line and read the tax code it actually carries. Then work the queue downward, not upward: does the document’s entity branch have an output tax code; does the customer record have a Tax tab entry; does this price row carry a code; does the item; and finally, does the company have a default. The first one you find that is filled in is your answer, and the screens after it are irrelevant however wrong they look. The commonest wasted hour on this surface is spent correcting the item’s tax code when the branch or the customer was supplying the value all along.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 6 — Carry the rule into e-invoice

After this step you will know why this matters beyond the invoice total. The taxable type BigLedger reports to the regulator is not taken from a field anybody sets on the item. It is derived from the line’s tax amount: a line with no tax goes out as not applicable, a line with tax as sales tax, and only a deliberately chosen code in a narrow range survives untouched. So the rate this cascade produced decides what the regulator is told. A wrong tax rate on a line is therefore never only a wrong total — it is also a wrong classification, and it is fixed by finding which of the five candidates supplied the rate.

Reference: Tax Configuration

How the steps fit together

    flowchart TD
  A{"Entity branch<br/>output tax code?"} -->|yes| W["Line's tax code, rate, type"]
  A -->|no| B{"Customer Tax tab?"}
  B -->|yes| W
  B -->|no| C{"Price row's<br/>own tax code?"}
  C -->|yes| W
  C -->|no| D{"Item header?"}
  D -->|yes| W
  D -->|no| E{"Company default<br/>output tax code?"}
  E -->|"yes — filing rate, read live"| W
  E -->|no| F["Blank code, rate 0"]
  W --> G["Tax amount on the line"]
  G --> H["E-invoice taxable type,<br/>derived from that amount"]
  

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.

Next: A price row remembers the item as it was · Back to the series · Play this as a presentation