Automation rate
The automation rate measures the share of business transactions processed without manual intervention. The stricter variant is the straight-through processing rate: the share of transactions that run from receipt to posting with no human involvement at all. It is the more meaningful figure because it does not count partial automation.
Why the definition decides
Few metrics are calculated as differently. Does an invoice count as automated if it was captured automatically but approved manually? If the posting proposal survived, but someone confirmed it? Depending on the definition, the same process comes out at 30 or at 80 percent.
That is why the straight-through processing rate is the more usable figure: the share of transactions that were never touched by a human between receipt and posting. This number cannot be flattered, and it relates directly to the effort you are trying to reduce.
Realistic orders of magnitude
In accounts payable, what is achievable depends almost entirely on the purchase order rate. Where an order exists and a goods receipt has been booked, a high share runs through. Where no order exists, approval on the substance is a human decision – and then the constraint is not the technology but the organisation.
An uncomfortable consequence follows from that coupling: raising the automation rate means improving procurement discipline first. That is an organisational undertaking, not a software project.
Why 100 percent is not the goal
Part of the volume should be reviewed: special cases in account assignment, variances beyond tolerance, unusual amounts, new suppliers. A very high automation rate is therefore not purely a good sign – it can also mean the exception rules are too coarse and exceptions are running through unchecked. The sensible target is a high share among the transactions suited to it, not across all of them.
The metrics that belong with it
The automation rate alone is misleading. It becomes meaningful together with three further figures: cycle time from receipt to approval, the error and correction rate among automatically processed transactions, and the close completion day. A rising automation rate alongside a rising correction rate is not progress but a shift of effort to a later point.
Measure before the project
All of these belong measured once before an automation project starts. Without a baseline there is afterwards neither a way to prove the benefit nor a basis to decide whether the next step is worth taking.