Ask an accounts payable team what takes the time and you will hear about the volume of invoices. Watch them work for a day and you will see something else. In construction and in any other trade billed in stages, a great deal of the effort is not spent checking new work at all. It is spent re-establishing where the last invoice left off.
This is a structural consequence of how staged contracts are usually settled. Under German construction contract terms, and under many equivalents elsewhere, a contractor bills cumulatively: each interim invoice restates the entire scope delivered so far, line by line, with the previous payments deducted at the end. The invoice you receive in September is not a statement of what happened in September. It is a restatement of the whole job, with September folded in somewhere.
Where the hours go
Consider what a checker has to do with such a document. The bill of quantities may run to several hundred positions. For each one, the quantity now claimed has to be compared against what was claimed last time, and against what was actually approved last time — because the two are frequently not the same. Corrections applied in the previous round do not propagate automatically into the contractor's next invoice. They have to be carried forward by hand, position by position, before any judgement about the current period can begin.
Only after that transcription is complete does the work that anyone would recognise as checking start: are the measurements plausible, do the quantities match the site records, is this position covered by the contract or is it a variation in disguise, are the rates the agreed ones.
The first half of the work is not verification. It is reconstruction of a state that was already known and simply not carried across.
Two things follow from this, and they point in opposite directions.
The bad news for automation enthusiasts
The genuinely difficult part of invoice checking — deciding whether a claimed quantity is justified by what was built — is a judgement grounded in site knowledge, contract interpretation and, frequently, an argument with the contractor. No document model resolves that. Vendors who imply otherwise are selling the easy half and describing it as the whole.
The good news, which is larger
The transcription half is a different animal entirely. Carrying forward approved values, aligning this invoice's positions against the previous one, flagging where a position has appeared, disappeared, changed rate or jumped in quantity — that is mechanical comparison of structured data. It is precisely the kind of work that software has been able to do reliably for years, and that current document-reading models have made accessible even where the input arrives as a scanned PDF rather than a clean data file.
The prize, then, is not a machine that approves invoices. It is a machine that hands the checker a document in which the previous state is already carried forward, the differences are already highlighted, and the questionable positions are already at the top. The human still decides. They simply start at the point where deciding is the only thing left to do.
What to look at first
- How much of your checking time is spent on positions that were already settled in the previous round?
- Do corrections from one round reliably reach the next invoice, or are they re-applied by hand every time?
- Does the contract genuinely require cumulative billing, or is it habit that nobody has revisited?
- What arrives in a structured format today, and what only exists as paper or as a picture of paper?
The question worth asking before any of this
There is a more uncomfortable question underneath, and it is worth asking before a single euro goes towards software. Why is the billing cumulative in the first place?
Sometimes the answer is contractual and settled. Often it turns out that nobody currently employed can say where the requirement came from, and that it has simply been inherited. Where that is the case, the cheapest improvement available is not a document model. It is a change to the billing specification in the next tender — which costs nothing and removes the work rather than accelerating it.
That is not the answer a procurement technology consultant is supposed to give. It is nonetheless the one that has repeatedly produced the largest saving, and it is the reason I insist on describing the process in detail before discussing tools at all.
A note on evidence. The pattern described here is structural and shows up wherever staged billing meets manual verification. Figures from any specific organisation belong to that organisation, and none are reproduced here.