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 e-invoice should have, somewhere, an e-invoice from the party who did, and pairing them off would show that each one has.

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 job runs off every finalisation — not a schedule, provided your tenant subscribes it — 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 already carries the skip flag. Nothing removes a row except a successful match, which needs the other half, or you pushing it to history, so in practice this register only grows. The one kind of skipped sale it never holds is one you skipped later from a pool row.

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 its application programming interface, 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. So unless your own integration is posting the platform’s e-invoices in, nothing ever arrives on that side, and 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. Open the skipped documents line on your monthly report — the one you read first every month — and take the documents behind it rather than its total, which adds purchases and credit notes in with your sales. Keep the sales documents of that channel’s branch, set its returns and credit notes against its invoices, and compare the result with the platform’s own settlement or tax statement for the same period. Those two should describe the same sales, 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