Proving a tax setup from the only place that can prove it — 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 at GadgetSphere is setting up tax for a new company or has inherited one and does not trust it. In about fourteen minutes you will know the order to do it in, and the one check at the end that is worth more than all the screens put together.

Step 1 — Put the accounts in before the codes

After this step you will avoid the failure that catches everyone first. A tax code has no account on it. The account a tax amount lands in comes from the company’s default GL code links for output tax and input tax, set on the company, each pointing at a GL code and a subledger. Do that before you create a single tax code. If the link is missing, or exists with an empty subledger, the tax line of every journal is dropped with no error and the document then fails to finalise with a debits and credits do not balance message. That message names nothing about tax, which is why it costs an afternoon.

Reference: Tax Configuration — Before you can use it

Step 2 — Create the codes, and mind what delete means

After this step you will not paint yourself into a corner. Create the tax codes you need with whole-percent rates. Two things to know before you type. Delete is a soft delete: the row stays in the table with a deleted status, and the unique constraint still covers the code string, so you can never create that code again. And inactive does not take a code out of circulation — it only hides it from this listing. So choose code strings you can live with, and expect to work around the ones somebody deleted before you arrived.

Reference: Tax Configuration — Troubleshooting

Step 3 — Switch the items on, then check the tick rather than the code

After this step you will know which item question actually matters. Set the tax codes on the items that need them, and tick Tax Applicable, because without the tick none of the codes applies. When you check your work afterwards, check the tick. An export showing that every item carries an output tax code proves nothing, because most items on this platform carry a code with the gate shut. The two are separate fields and only one of them is load-bearing.

Reference: Doc Item Maintenance — Tax tab

Step 4 — Accept what the setup screens cannot tell you

After this step you will stop treating a clean configuration as a result. The Tax Configuration listing shows the codes you meant to create, and tells you nothing about which documents used them. The item screen shows a rate that is a copy, possibly an old one, of a column that documents do not read. The E-Invoice tab shows a taxable type that will be recomputed before it is sent. Each screen is honest about its own record and silent about the next one. Four copies of a rate and a derived tax type mean the setup and the outcome are genuinely different questions.

Reference: Tax Configuration — Lifecycle and effects

Step 5 — Run the check that does prove it

After this step you will have a test that closes the loop. Raise one real sales document for a taxed item, finalise it, let it go to the regulator, and then read the submitted line in the e-invoice admin applet. Look at three things on that line: the rate, the tax amount and the taxable type. If the rate is the one you configured, the amount is the rate times the net, and the type is sales tax rather than not applicable, the whole chain works — accounts, code, tick, rate and derivation. If the type says not applicable, the amount was zero and you know exactly which link to go back to.

Reference: My E-Invoice Admin Applet — Screens and menus

Step 6 — Treat acceptance as the weakest evidence you have

After this step you will know why you cannot wait to be told. An accepted e-invoice means the submission was well formed and passed the checks in force that day. It is not a statement that the content is right, and the platform has had codes accepted for months and then rejected when the regulator tightened a rule. Everything in this series is quiet by design: nothing is refused, nothing is pooled, no warning appears. So the habit worth building is not a monthly rejection review. It is reading a handful of submitted lines after any change to tax setup, and comparing them with what you intended.

Reference: E-Invoice Validation Rules & Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Put the accounts in before the codes"]
  s2["Step 2 — Create the codes, and mind what delete means"]
  s3["Step 3 — Switch the items on, then check the tick rather than the code"]
  s4["Step 4 — Accept what the setup screens cannot tell you"]
  s5["Step 5 — Run the check that does prove it"]
  s6["Step 6 — Treat acceptance as the weakest evidence you have"]
  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.

Back to the series · Play this as a presentation