How far the e-commerce reconciliation actually goes — 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 you if you have found the Reconciliation, Sales screens in the e-invoice applet and assumed they reconcile GadgetSphere Online’s marketplace sales against the e-invoices the platform issued. They are built to, and on your tenant today they will not. About twelve minutes, and the point is to save you the month you would otherwise spend waiting for a match that cannot happen.

Step 1 — Meet the two registers this screen pairs

After this step you will know what the screen is trying to do. It has two sides. One is your own sales documents — specifically, the ones you skipped, because those are exactly the sales somebody else reported. The other is the e-invoices that came in from the platform that reported them. The idea is elegant: every sale you deliberately did not report should have, somewhere, an e-invoice from the party who did, and pairing them off proves your marketplace revenue was reported once, by exactly one of you.

Reference: My E-Invoice Admin Applet — 7. Incoming e-invoices and reconciliation

Step 2 — Know which of the two fills itself

After this step you will know the half that works. A processor watches every finalisation and writes a row into the sales side whenever a document is finalised, belongs to a company enabled for e-invoicing, is a sales document type and carries the skip flag. It needs no schedule and no button. It also never removes anything by itself, so this register only grows. Measured across every production tenant, it holds roughly six hundred and forty thousand rows, with one tenant carrying about half of that on its own. Your skipped sales are all there.

Reference: My E-Invoice Admin Applet — 7. Incoming e-invoices and reconciliation

Step 3 — Know that nothing fetches the other half

After this step you will stop waiting. Rows on the incoming side are created in exactly two ways: something outside BigLedger posts them in through the API, or you push one back from a history list. There is no marketplace connector, no scheduled fetch and no call to LHDN that produces one. Measured across all ninety production tenants on the seventeenth of September, that register holds no rows at all — not few, none. So unless your own integration is posting the platform’s e-invoices in, the screen has one register full and the other permanently empty.

Reference: My E-Invoice Admin Applet — 7. Incoming e-invoices and reconciliation

Step 4 — Know the four keys, and the one that can never agree

After this step you will know what would happen even if the rows arrived. The matcher pairs on four values: reference number, transaction date, amount and the buyer’s identification number, and it applies each test only when the incoming row carries that value. Two things follow from the code. The sales-side row never carries a buyer identification number at all, so an incoming e-invoice that does carry one can never pair with anything. And the sales-side key is the document’s Reference field, not its document number — so your marketplace order identifier has to be in Reference or nothing will line up.

Reference: My E-Invoice Admin Applet — 7. Incoming e-invoices and reconciliation

Step 5 — Do not press Auto Match on the sales screen

After this step you will avoid an expensive misunderstanding. The Auto Match button on the sales-document queue calls the purchase-side matcher — the same call the purchase screen makes, not the e-commerce one. So a pass you start while looking at marketplace sales runs across your supplier reconciliation and can pair and clear rows you were still reviewing. Only the incoming e-commerce screen uses the e-commerce service. While you are at it, the Export button on all ten of these listings does nothing at all; use the grid’s own tool panel to get a listing out.

Reference: My E-Invoice Admin Applet — 7. Incoming e-invoices and reconciliation

Step 6 — Reconcile the way that actually works today

After this step you will have a method that proves the same thing without the screen. Take the skipped documents total from your monthly report — the figure you read first every month — and compare it with the platform’s own settlement or tax statement for the same period. Those two should describe the same revenue, and a difference is either a sale you skipped that the platform did not report, or one it reported that you did not skip. Both are worth finding. Keep the comparison in your month-end file and do not expect these ten screens to produce it for you.

Reference: E-Invoice Submission Mechanics — The discrepancy report: what “missing” means

How the steps fit together

    flowchart TD
  s1["Step 1 — Meet the two registers this screen pairs"]
  s2["Step 2 — Know which of the two fills itself"]
  s3["Step 3 — Know that nothing fetches the other half"]
  s4["Step 4 — Know the four keys, and the one that can never agree"]
  s5["Step 5 — Do not press Auto Match on the sales screen"]
  s6["Step 6 — Reconcile the way that actually works today"]
  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