An invoice reader correctly captures the supplier's address, date, line descriptions and tax labels. It misreads the amount payable. If those fields are averaged into one accuracy percentage, the result may still look impressive while the payment proposal is wrong.
The test should follow the consequence of an error. An incorrect reference can delay matching. An incorrect currency or revised total can change a payment. A correctly extracted bank account can still be fraudulent. These are different failure modes, and they need different expected outcomes.
There are at least four separate questions. Did the system read the document accurately? Did it identify the right invoice and version? Did the proposed accounting or tax treatment receive the necessary review? Is the payment authorised to the right verified recipient?
An extraction test answers the first question and can test parts of the second. It does not establish that the purchase occurred, that the supplier is genuine or that the invoice qualifies for a tax claim. Keep these boundaries visible in the test sheet.
For a GST-registered Singapore business, IRAS's input-tax conditions include appropriate documentary support, such as a valid tax invoice or qualifying simplified tax invoice for ordinary local purchases, alongside other eligibility conditions. Capturing the printed GST amount does not establish those conditions or determine the claim period.
The Singapore Police Force also warns businesses to verify changes to suppliers' payment details through additional checks or a different medium. A bank account printed clearly on an invoice is therefore not permission to update the supplier's approved payment instructions.
Ask the accounts-payable lead to classify the fields by what an error could cause in this particular workflow. Use consequence labels rather than pretending that a universal numerical weight exists.
| Field or relationship | Example failure | Expected protective outcome |
|---|---|---|
| Currency and payable amount | Decimal or currency misread | No unreviewed payment proposal using the wrong value |
| Supplier and invoice identity | Similar number assigned to another entity | Identity conflict remains visible for resolution |
| Revision relationship | Earlier total used after corrected invoice arrives | Superseded version cannot remain the active proposal |
| Tax evidence | Printed amount accepted without the required support | Tax review stays separate and unresolved evidence is flagged |
| Bank instructions | New account copied from the document | Supplier-change verification route, without automatic activation |
| Order or delivery reference | Missing character prevents matching | Specific correction request linked to the source |
A field can have more than one consequence. An invoice date might influence matching and period review. The classification should reflect actual use, not how prominent the field looks on the page.
Also test relationships between fields. Every line may be read correctly while the system mistakes a subtotal for the payable total or treats a credit note as a new invoice. Arithmetic checks help, but a document can be internally consistent and still be the wrong version.
CURIOUSRUBIK INVOICE TESTING / SINGAPORE Judge each field by its protective route Retain the source-document reference beside each test and assigned reviewer. Field / relationship Expected protective route Reviewer role Currency / total No unreviewed wrong-value proposal Accounts payable Supplier identity Resolve the entity conflict Accounts payable Revision Keep superseded version inactive Billing owner Tax evidence Separate eligibility assessment Tax reviewer Bank instructions Separate verification; no auto-update Supplier-control owner Reference Specific correction linked to source Buyer / requester SET EXPECTED VALUES AND ROUTES BEFORE TESTING · PRESERVE AMBIGUITY curiousrubik.com
Suppose a hypothetical trial checks 20 invoices with 10 selected fields on each. Of 200 field values, 198 are correct: 99% under that simple measure. The two errors are both payable totals on different invoices.
The same results therefore include amount errors on two of the 20 invoices, or 10% of the invoices in this invented set. Neither number is a forecast or benchmark. They describe different denominators, and the aggregate field score hides the concentration of consequential errors.
Now add an important distinction. If both wrong totals were routed to a reviewer and corrected before any authorised downstream action, the extraction still made two errors, but the controlled workflow handled them. If both were accepted without referral, the test has two unsafe acceptances under its defined control objective.
Record both. Do not count a corrected case as an error-free extraction, and do not count every referral as a business failure. The evaluation needs to show the quality of the initial reading, the routing decision, the final accepted record and the effort required to get there.
CURIOUSRUBIK INVOICE TESTING / SINGAPORE A high field score can hide wrong totals Hypothetical synthetic example · 20 invoices × 10 selected fields = 200 fields. 99% 198 / 200 fields correct 10% 2 / 20 invoices with amount errors Alternative outcomes for those same two errors: Caught + referred Correct before authorised action Unsafe acceptance Wrong totals accepted without referral Correction does not erase the original extraction error. DIFFERENT DENOMINATORS · NO PRODUCTION FORECAST OR ACCURACY BENCHMARK curiousrubik.com
A clean document collection is insufficient. Add a sequence in which an invoice is received, a corrected version follows and the original is resent later. The expected result should preserve the document history, identify the current reviewed version and avoid creating a second payable from the resend.
Include a correction that changes only a reference and another that changes the total. The business may handle them differently. The test owner should define when review must restart and which previous decisions remain usable.
Try the same invoice as a scan and as an electronic document. Include a credit note with a similar number, a multi-page invoice with the total on the last page, a missing page and a low-quality image. Use lawful, suitably protected test material or synthetic documents; do not copy live supplier information into an unapproved testing service.
Set the expected answer before evaluating the extraction. A qualified person should establish the correct field values and expected exception route from the source. Where the source itself is ambiguous, “needs clarification” can be the correct answer. Forcing a single invented value would reward guessing.
A deliberately challenging set helps reveal failure modes, but it does not estimate their frequency in ordinary business. A sample of real operating work can help estimate the actual mix, provided its selection and limitations are understood.
Report these separately. “Handled all five revision-conflict tests correctly” is useful evidence about those five cases. It is not a production accuracy guarantee. Conversely, a favourable average from ordinary invoices does not excuse a known failure in a consequential edge case.
Track review effort by case type. A referral requiring a short comparison differs from one requiring a supplier query. Count unanswered cases and rework as well as completed ones, so the trial cannot look faster merely by leaving difficult invoices outside the result.
The accounts-payable lead owns the test outcome. Tax questions go to the tax reviewer, bank-change questions to the supplier-control owner, and unresolved commercial facts to the buyer or authorised requester. One general reviewer should not be expected to settle every type of uncertainty.
A test may support use on a limited set of stable invoice types while showing that revised documents need a separate route. That is a legitimate result. Expanding scope should require new evidence, rather than assuming that one successful layout represents every supplier.
Keep payment release as a separate authorised step. The extraction can prepare fields and show their source, but it should not convert a document-reading score into approval to pay or permission to change bank details.
After changes to extraction rules, document formats or routing, rerun the cases that previously exposed a material failure. Preserve the expected results and test version. Otherwise, an improvement to one field may quietly reintroduce an old revision error.
Before accepting the next accuracy report, ask for the invoices with wrong totals, identities, currencies or revision states. Then ask what the workflow did with them. Those cases will tell you more about readiness than a single percentage beside a green tick.
