How e-invoicing changes PO, GRN and three-way matching

Three-way matching reconciles three documents before an invoice is paid: the purchase order (what was ordered), the goods-receipt note or GRN (what was received), and the supplier invoice (what is being charged). When all three agree within tolerance, payment is released. E-invoicing does not remove this control — it changes the nature of the third document.

Under e-invoicing, the supplier invoice is a structured, validated data record rather than a formatted page. It carries defined fields — seller and buyer identification, tax registration data, line items, quantities, unit amounts, tax treatment and the unique identifier returned at validation. In principle this is good news for matching: structured data can be compared field by field against the PO and GRN automatically, instead of a person reading a PDF and typing numbers into a system.

The catch is that matching now depends on the data lining up. If the PO and GRN are themselves loose — free-text line descriptions, no consistent item references, quantities recorded differently — then a precise, structured e-invoice has nothing precise to match against. E-invoicing raises the bar on the quality of your own order and receipt data.

Effective matching under e-invoicing is a field-mapping exercise: each element of the e-invoice needs a counterpart in the purchase order and the goods-receipt record so that agreement can be checked automatically.

E-invoicing also introduces timing that paper never had. A submitted e-invoice can be rejected at validation, and adjustments happen through defined cancellation windows, credit notes and debit notes rather than by quietly editing a document. For matching, that means a rejected or cancelled e-invoice is a live event: your process has to notice it, hold the match open, and reconcile the eventual corrected document — within whatever windows LHDN defines, which change and should be checked against current guidance.

Workflows built around paper and PDF matching struggle with all of this. A process where someone prints an invoice, ticks it against a PO by hand and files it cannot react to a validation rejection, cannot reliably tie a later credit note to the original, and cannot compare structured fields at scale. The manual approach also degrades exactly where volume is highest — the routine and tail purchases that generate the most documents.

The fix is structured order data end to end: a purchase order with consistent item references, a goods-receipt record captured against those references, and an e-invoice whose fields map cleanly to both. Buying through one managed channel is a direct way to get there, because the PO, receipt and invoice data all originate in a consistent structure. Lapasar supplies goods as a supplier of record with structured, order-linked invoice data and delivery via owned fleet and warehouses across Peninsular Malaysia; it does not validate or file e-invoices with LHDN, and compliance responsibility remains with the taxpayer. This page is educational, not tax advice — confirm specifics with your tax adviser.

Before e-invoicing, a buyer's finance clerk received a PDF invoice, opened the matching PO on screen, checked the goods-receipt note, and ticked the three off by eye before releasing payment. Small discrepancies were resolved by phone or email, and a correction meant a supplier reissued a fresh PDF. It worked, slowly, and it did not scale — and it left no structured record that a machine could verify.

After moving indirect and tail spend onto one managed channel, the same buyer's purchase orders carry consistent item references, goods receipts are captured against those references, and the supplier of record issues structured, order-linked e-invoice data. Matching becomes a field comparison the system performs, with genuine mismatches raised as exceptions. A later adjustment arrives as a credit note that references the original order and reconciles automatically. Throughout, the organisation keeps compliance responsibility and confirms its treatment with its tax adviser.

E-invoicing keeps three-way matching but changes the invoice into structured, validated data whose fields must map to the purchase order and goods-receipt note. Done well, that makes matching automatable; done on loose PO and GRN data, it exposes how unmatched your own records really are.

Rejection windows, cancellations and credit or debit notes add timing that paper workflows cannot handle, so structured order data end to end — PO, receipt and e-invoice sharing consistent references — is the practical fix. This page is educational; matching-relevant rules and windows are set by LHDN and change, so check current guidance and consult your tax adviser.