The Invoice Check Build Standard
How to build an automated subcontractor invoice check properly, written so you can build it yourself. Four checks in a fixed order, four queues, and the six rules that decide whether anyone still trusts it in six months.
Does the work of
- Accounts Payable Officer
- Finance Administrator
- Project Accountant
Most people who need this can build it. A competent bookkeeper with AI tools, or a developer with a week, will get something running. What separates the ones still running in two years from the ones quietly abandoned is not the model or the language. It is the order of the checks, what happens to an exception, and whether anyone can tell that it ran. That is what this specifies.
In short
- What this is
- An open build standard for an automated invoice-versus-purchase-order check. Implement it in whatever you like.
- Who it is for
- Anyone building this themselves, and any AI agent asked to build it. It is written to be followed literally.
- The core rule
- The check proposes, a person disposes. Nothing in this specification pays an invoice.
- The hard parts
- Matching to the right PO, progressive claims, finding the variation approval, and deciding what close enough means. Section 6 names them so you can scope them in.
- Why we publish it
- A check built to a shared standard can be audited, handed over and trusted. One built ad hoc leaves when its author does.
Want the whole thing by email?
This paper, plus the rest of the library. One click to stop them.
1. What this standard covers
One workflow: a supplier or subcontractor invoice arrives, and something decides whether it agrees with what was agreed. It covers the comparison and the exception. It does not cover paying anyone, and it deliberately stops short of that.
The standard assumes two connections and nothing else. An inbox, because invoices arrive as email attachments from people outside your systems, and that is the whole reason this work is manual. And an accounting package holding the other half of the comparison: the purchase orders, the bills, the contacts, the job codes. In Australian construction that is usually Xero or MYOB.
Why the work sits here
Everything an accounting package automates is inside one company’s boundary: its ledger, its bank feed, its payroll. Everything still done by hand crosses a boundary. The supplier is a separate company, using different software, under no obligation to match your format. That is why this work is stable rather than a gap waiting for the next release, and why the fix is to check across the seam rather than to try to close it.
2. The four checks, in order
Run them in this order and stop at the first failure. The order is part of the specification: it moves from the cheapest and most objective comparison to the most contested, so the exception a person reads is the earliest thing that went wrong rather than the last one detected.
| # | Check | Against | Passes when | On failure |
|---|---|---|---|---|
| 1 | Rate | The purchase order, subcontract or schedule of rates | Unit rate on the invoice equals the agreed rate | Flag with both rates and the difference in dollars |
| 2 | Quantity or progress | What has been marked complete, and what was claimed previously | Claimed quantity is available and not already claimed | Flag with the cumulative position, not just this claim |
| 3 | Variation | The written approval record | Every line outside the original scope has an approval reference | Flag as unapproved scope. Never infer approval from an email tone |
| 4 | Contract sum | The contract total plus approved variations | Cumulative claimed stays inside the adjusted sum | Flag as overrun before payment, not at practical completion |
Check 3 is the one that matters and the one most builds skip. Rate and quantity are arithmetic. Whether a variation was ever approved is a question about a document that may not exist, and it is where the money actually goes. A check that validates rates and totals but accepts any line item presented to it is checking the easy half.
If there is no purchase order to compare against, do not guess. That invoice belongs in the fourth queue with the question “which job is this?” attached, not in the first with an inferred match.
3. The four queues
Every invoice ends in exactly one of four states. Build these as four lists a person can open, not as a status column nobody reads.
Queue 1
Needs a decision
Mismatches the machine found and cannot resolve
Sorted by dollars at risk. If this is long, the build has failed
Queue 2
Waiting on someone
Queried invoices, POs with no invoice, certificates about to expire
Every row carries a next-chase date and a drafted message
Queue 3
Done, and reversible
Everything that matched cleanly and was drafted without a question
Visible and undoable. This is what earns trust in week eight
Queue 4
Blocked by nature
New subcontractor setup, variation with no written approval, payment authorisation
Work the machine should not attempt, kept apart from work it failed
The third queue is the one people leave out, and it is the one that decides adoption. If the clean matches are invisible, nobody can tell the difference between a system that checked forty invoices and found three problems, and a system that silently did nothing. For the first month the operator will read that list line by line. By the second they will check the count. That progression only happens if you build the list.
4. The exception record
An exception is not a notification. It is a record, and it needs enough on it that a person can decide without opening anything else:
- What arrived — invoice number, supplier, amount, and a link to the source document
- What was expected — the PO or contract reference and its figure
- The difference — stated in dollars, not as a percentage or a similarity score
- Which check failed — and therefore which checks were never run
- Confidence — and what it is based on, so a person can discount it
- The date, kept — the record survives the decision
Keep the source document attached to the record. In an industry that gets audited, a decision without the evidence that informed it is worth very little eighteen months later.
5. Six rules that keep it trustworthy
Propose, never commit.
Draft the bill, draft the query, propose the payment batch. A person clicks. Nothing in this standard moves money, and that is not a limitation to relax in version two.
Never auto-approve, only ever flag.
A check that is confidently wrong is worse than no check, because the operator stops looking. “Nothing to flag” has to be honest, not a guess.
Silence is a finding.
The hardest thing a person does here is notice what did not arrive: the invoice never sent, the certificate quietly expired, the PO with no claim against it. Drive the second queue from expected-versus-actual, not from what turned up.
Every automatic action is visible and reversible.
If you cannot show what it did and undo it, you cannot ask anyone to rely on it.
Fixed checks, no free-text prompt.
If an operator has to phrase the question, two runs will not agree and neither will be reproducible. The value is that it happens identically every time.
Escalate ambiguity, never resolve it.
A partial match, an unreadable scan, a supplier you have never seen. These belong to a person. Guessing here is how the whole thing loses credibility in one bad month.
6. The parts that are harder than they look
A first version comes together quickly. These are the things that take the rest of the time, listed so you can scope them in rather than discover them one at a time. If you are stuck on one of these, you have not done anything wrong — this is where the work actually is.
Matching the invoice to the right purchase order
Suppliers do not quote your PO number, or they quote it wrong, or one invoice spans three POs, or the PO was raised after the work. Matching on supplier plus amount plus date gets you most of the way and then produces a confident wrong answer. Decide early what you will do with a partial match, because it is the most common case and it is not a match.
Reading a line item that was never structured
“Variation 3 — additional works as discussed” against a PO line reading “Supply and install, stage 2”. Totals compare cleanly; descriptions do not. This is where extraction stops helping and judgement starts, and it is the reason the check escalates instead of guessing.
Finding the variation approval
Check 3 assumes there is a written record. Often the approval is in a text message, or on a site instruction nobody scanned, or it was verbal. You cannot automate your way past a document that does not exist — what you can do is make its absence visible, which is frequently the most valuable output of the whole build.
Progressive claims and retention
A claim is usually cumulative, so the check is not invoice-versus-PO but this-claim-plus-everything-previously-claimed versus the adjusted contract sum, less retention. Get this wrong and every claim after the first looks like an overcharge.
Credit notes and part-payments
They break the assumption that one invoice equals one decision, and they are usually the first thing that makes a working check start producing noise.
Deciding what “close enough” means
Rounding, GST treatment, a $2 freight difference. Too tight and the exception queue fills with nothing; too loose and it misses the thing you built it for. This threshold is a business decision, not a technical one, and it should be written down where the operator can see it.
None of these is a reason to stop. They are the reason a build takes longer than the first demo suggests, and knowing them in advance is most of the difference between a check that survives contact with a real month and one that gets switched off.
7. What breaks after it works
A self-built check usually works when it is built, because the person who built it is also the person running it and they carry what it does not cover in their head. The failures come later, and they are consistent enough to design against:
- It leaves when they do. A prompt library in someone’s chat history, a spreadsheet of their formulas, an inbox rule under their login. None of that gets handed over.
- Nobody knows whether it ran. A check performed when someone remembers, phrased how they phrased it that day, with no record that two runs agreed.
- It degrades quietly. Rates change, a supplier changes their invoice layout, a new PO format appears. It keeps returning “nothing to flag” and everyone believes it.
- It cannot be audited. No dated record of what was compared against what.
None of these is a reason not to build it yourself. They are the things to design against if you do. Rules 3, 4 and 6 above exist specifically because of them, and following this standard is what makes a self-built check survivable by the next person in the seat.
8. Conformance checklist
A build conforms to this standard if all of the following are true. Use it on your own implementation, or on one an AI built for you.
- The four checks run in the specified order and stop at the first failure.
- An invoice with no matching purchase order is escalated, never matched by inference.
- Variation approval is checked against a written record, not assumed.
- Every invoice lands in exactly one of the four queues.
- Clean matches are visible in a list, not silently absorbed.
- Every exception carries the difference in dollars and the source document.
- Nothing in the system pays, approves or releases a payment without a person.
- The record of a check survives the decision it informed.
- The tolerance thresholds are written down somewhere the operator can read them.
- It runs on an account the business owns, not a personal login, and someone other than the builder can explain what it does.
Build it yourself, or have it built
This standard is free to implement and we would rather it was followed than owned. If you build it, the conformance checklist above is the thing to hold your build to, and you are welcome to it whether we ever speak.
Three points where people tend to want a hand, none of which require starting over:
- Before you start— scoping which of section 6 applies to how your business actually claims, so the build is costed honestly.
- When it is stuck— usually PO matching, progressive claims or the tolerance threshold. These are the same problems everywhere and they have known answers.
- When the person who built it has gone— taking over something that already runs, documenting it against this standard, and keeping it running.