What you are reconciling, and what you are not

Play this lesson as slides — one slide per step, with the same narration. The full text of every step is on this page.

This lesson is for you if you run the books at GadgetSphere and somebody has started asking whether the purchases in your ledger have supplier e-invoices behind them. Before you open a single screen, it is worth about nine minutes settling what this job actually is, because two other jobs share its vocabulary and one of them is not even in the same module. By the end you will know what the reconciliation proves, what it cannot prove, and why none of it moves a cent in your accounts.

Step 1 — Name the question you are answering

After this step you can say in one sentence what the whole exercise is for. Sooner or later somebody asks you to prove that every purchase sitting in your books has a validated supplier e-invoice behind it. That is the question. GadgetSphere buys from around one thousand two hundred suppliers, and about twenty authorised distributors account for the overwhelming majority of what it spends. That shape is what makes the job possible at all: you check the big suppliers properly, and you spot-check the long tail. If you go into this expecting to verify twelve hundred relationships every month, you will give up in week one and the answer will still be no.

Reference: Incoming Supplier E-Invoices — Meet GadgetSphere

Step 2 — Accept that none of this touches your accounts

After this step you will stop looking for a ledger effect that is not there. Pairing a supplier’s e-invoice with your purchase document posts nothing. It does not change the document’s status, does not touch tax, does not create a journal line, and does not move a supplier balance. The whole applet never posts to the general ledger at all. A pair is a record that you checked, and it is reversible with one button. Two things follow. You cannot break your accounts on these screens, so explore freely. And matching is not a substitute for approving and posting the purchase invoice properly — that is a separate job, in a separate applet, and it still has to happen.

Reference: Incoming Supplier E-Invoices — Step 3: Pair a supplier document with your purchase document

Step 3 — Tell a matching queue from a submission queue

After this step a screen full of untouched rows will stop worrying you. You already know submission queues from your own e-invoicing: a document sits there on its way to LHDN and it moves on its own, and a row that has not moved for days is a problem. A matching queue is the opposite kind of thing. It holds a row that is waiting for a counterpart to turn up, and if no counterpart ever turns up, it waits forever. That is the normal, expected state, not a fault and not a backlog you caused. Read the word queue here as worklist, and you will treat these screens correctly from the first day.

Reference: Incoming Supplier E-Invoices — What you need to know first

Step 4 — Tell it from three-way matching

After this step you will not go looking for purchase orders on these screens. Comparing a purchase order against a goods received note against a supplier invoice is three-way matching, it is a purchasing job, and it lives in the purchasing guides. What you are doing here is narrower and it is a tax job: pairing your purchase document with your supplier’s e-invoice, as two records of the same transaction for the Inland Revenue Board — LHDN. Same supplier, same money, entirely different question. There is in fact a second console in BigLedger that does compare delivery orders and goods receipts against supplier invoices, and it is a separate subject with separate screens. Lesson six tells you which one your suppliers land in.

Reference: Incoming Supplier E-Invoices — What you need to know first

Step 5 — Set your expectations before you open anything

After this step you will not spend a month waiting for a screen to fill. BigLedger does not show you the e-invoices your suppliers filed with the Inland Revenue Board. Incoming matching only ever sees documents that reached BigLedger through a delivery channel, and most of your suppliers are not in that group: they file with the board, then send you an ordinary PDF or a piece of paper, exactly as before. For those, BigLedger holds no record of the supplier’s e-invoice at all, and no configuration on your side changes that. The manual check later in this course is not a fallback for a few awkward cases. For most businesses it is the main event.

Reference: Incoming Supplier E-Invoices

Step 6 — Get the three prerequisites in place

After this step you can start the next lesson without being blocked halfway through it. Three things. First, you can open the My E-Invoice Admin Applet and its left menu shows both External Reception and Reconciliation, Purchase — if either group is missing, an applet setting is hiding it and whoever administers the applet can restore it. Second, last month’s purchase invoices are finalised, because a purchase document still in draft has entered no part of the e-invoice pipeline and will appear nowhere. Third, your supplier records carry a tax number wherever the supplier has one. That third item decides far more than it looks like it should, and the next lesson shows you why.

Reference: Incoming Supplier E-Invoices — Before you start

How the steps fit together

    flowchart TD
  s1["Step 1 — Name the question you are answering"]
  s2["Step 2 — Accept that none of this touches your accounts"]
  s3["Step 3 — Tell a matching queue from a submission queue"]
  s4["Step 4 — Tell it from three-way matching"]
  s5["Step 5 — Set your expectations before you open anything"]
  s6["Step 6 — Get the three prerequisites in place"]
  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.

Next lesson: The list of purchases that should have one · Back to the course