Invoice approval as a ready-made computational model

Inflow: roughly 1,200 invoices a month, about 60 on a working day, with a peak factor towards month end.

The decisive finding: the sum of processing times is 20 to 30 minutes per invoice, while actual lead time is eight to twelve working days. Roughly three orders of magnitude separate the two, and that gap consists almost entirely of waiting — mostly in front of business approval.

The reason is structural and has nothing to do with negligence: approving is not a full-time job but a side task for fourteen people. That produces very high variation (ten minutes or six days) and no cover during absence — two properties that together create the waiting time.

1. Volume per working day. Invoices received last year ÷ working days. Accounts payable or an ERP report has it.
2. Peak factor. How many invoices arrive on the busiest day compared with a normal one? Usually month end; a factor of 1.5 to 2 is common. Without it you are computing a process that is never under load.
3. Accounting capacity. People × productive hours per day. Rule of thumb: FTE share × 7 hours, not × 8 — meetings, queries and interruptions are not processing time.
4. Number of approvers. How many people give business approval? This number drives variation more than any other.
5. Approval rhythm. How often does an approver look at their tray on average — daily, twice a week, irregularly? Enter it as a processing range, not as the duration of the approval itself.
6. Fully loaded rates per role. Gross salary × 1.5 to 1.8, divided by roughly 1,500 productive hours a year. A €50,000 position therefore costs about €53 an hour, not the naive €24 from salary ÷ 2,080 hours. With the naive rate your statement in money becomes attackable later.

Cross-check before you compute: count the invoices waiting today and divide by daily throughput (Little's Law). If that lands near your known lead time, the model is usable. A large deviation means a queue is missing — usually a query to the supplier or a second approval tier above a value threshold.

Lever 1 — document capture (OCR) for data entry. Shortens entry considerably. Compute it, then watch what happens to approval: it now receives the full volume instead of a throttled one and becomes the constraint itself. Lead time falls far less than entry time does. This effect is the most common reason an automation business case fails to materialise.

Lever 2 — a value threshold for business approval. Invoices below a threshold skip individual approval, with a sample check afterwards. That takes volume away from approval rather than time — and therefore acts where the waiting is created.

Lever 3 — cover arrangements and a shared tray. Not approving faster, but reducing variation: named cover during absence, one shared tray per department instead of personal trays. Waiting time grows with the square of variation — halve it and its contribution quarters.

Lever 4 — daily payment run instead of twice weekly. The cheapest lever of all, usually a setting. Removes roughly one day on average.

Compute all four separately and rank by effect per effort. In almost every model of this kind, lever 2 or 3 beats lever 1 — and lever 1 is the one the market sells.

The full evaluation of this example is in the article Invoice approval: why OCR does not halve lead time.

After saving the baseline, changing one lever and running a second time, the comparison produces:

• Lead time before/after as P50 and P90 — a commitment is made against the P90, not against the median.
• Utilisation per step on the peak day and the new constraint after the measure.
• Annual staff cost effect as a range, from volumes, durations and fully loaded rates.
• The assumption list — every estimated input, stated. The sentence "queries to the supplier are not modelled" takes the sting out of the sharpest question before it is asked.

That is exported as two PDFs: a proposal for the decision maker and documentation for traceability — with your letterhead if you have set one.

• Quotation process — from enquiry to quotation sent. The case where lead time acts directly on revenue rather than on cost.
• Invoice approval — this page.
• Complaint handling — the constraint almost always sits in the query, not in the processing.
• Employee onboarding — many participants, low volume, high variation; the case where appointment chains determine lead time.
• IT ticket — prioritisation and escalation, with classic queueing behaviour.

Every template opens from the welcome window via View templates. The first time round it is worth opening one before starting your own model — otherwise people build too finely.