Every explanation of a clearance model is written from the seller's side. You generate an invoice, submit it to the tax authority, it validates, you get it back stamped, you send it on. Indonesia's Coretax works that way: an XML invoice goes to DJP, and what comes back carries a QR code and a tax invoice serial number that make it a valid document.
Now stand on the other side of the transaction, where a PDF has just arrived in accounts payable.
The consequence sits with the buyer
Without a valid QR code and serial number, that invoice is not valid for VAT deduction. Not "flagged for review" — not deductible. And the party who loses the credit is not the supplier who sent it. It is you.
That is the asymmetry worth sitting with. Clearance is presented as the tax authority taking responsibility for validating invoices, and in a sense it does. But it validates what the seller submitted. It makes no promise about the document that eventually reaches your AP inbox, which has typically travelled by email, through a portal, or as an attachment someone forwarded.
There is a second trap on the same side of the ledger: an invoice uploaded to Coretax after the 20th of the following month is not valid for VAT credit either. A supplier's late submission becomes your disallowed claim, and you will usually find out at reconciliation.
"Just scan the QR code"
That is the standard answer, and for one invoice it is a perfectly good one. The QR code exists precisely so the document can be checked against what DJP holds.
Apply it to a real AP function and it stops being an answer. A few thousand invoices a month, each needing a human to open a PDF, scan or key a code, wait for a response and compare fields — that is not a control, it is a wish. What happens in practice is that nobody checks, or somebody checks a sample, which catches a systematic problem eventually and an individual bad invoice never.
The result is a compliance model that is genuinely strong at the point of issue and largely unenforced at the point of receipt.
What the AP side actually needs
Stated plainly, the requirement is not complicated:
- Every inbound invoice checked against the tax authority's record, not against itself
- The check running automatically on receipt, not as a month-end exercise
- The fields that matter — the serial number, the parties, the amounts, the tax — compared rather than eyeballed
- A clear answer when something does not match, while there is still time to go back to the supplier
Which is a lookup, performed at scale, wired into the point where invoices arrive. The pieces exist: the QR code carries the data, DJP holds the record, and AP systems already have a receiving step where this would sit.
We are working on exactly this — programmatic validation of cleared Indonesian invoices at the AP receiving end, against the tax authority rather than against the document. It is in progress rather than finished, and we would rather say so than imply otherwise.
Why it generalises
Indonesia is the sharpest current example because Coretax reached full enforcement for essentially all VAT-registered taxpayers at the end of 2025. It is not the only one. Every clearance regime creates the same shape of gap: rigorous issuance, and a receiving side left to trust a PDF.
Malaysia's MyInvois returns a validated invoice with a QR code. Italy's SDI has worked on comparable lines for years. As ViDA pushes more of Europe toward reporting at source, the pattern spreads rather than recedes.
If you take one thing from this: when someone describes a clearance mandate, ask what happens on the receiving end. The answer is usually that nobody has thought about it, and the exposure is usually yours.
Indonesia and the rest of APAC → · Talk to us about AP-side validation →