A written case for AP automation is read by somebody whose job is to ask where each number came from. Splitting the benefits into what you can compute from your own data and what you can only describe is what makes the case survive that reading, and it is the difference between an approved proposal and one sent back for more work.
Computable: labour on the matchable share
Volume, times median minutes per invoice, times fully loaded hourly cost, applied only to the invoices that could clear without a person. The restriction is what makes it credible. Claiming a saving on invoices that will still need somebody is exactly the overreach that invites a challenge and loses the room.
Describable: speed, control and the record
Terms met reliably, accruals less speculative, an approval trail that outlives a departure, visible exception ageing, and a defence against duplicate payment and diverted funds. All real and none easily priced without inventing something. Stated as capabilities they strengthen the case; stated as dollars they invite an argument about the dollars.
What to state as a limit
That the touchless share is capped by your measured purchase-order and receipt coverage, and that raising it requires a change in another department. Naming that limit is what makes the rest of the case believable, and it also gets the upstream work resourced rather than assumed.
Questions people ask about benefits of ap automation
Can industry averages appear at all?
As context in a sentence, never as the basis of a calculation. The first question about an average is whether it applies here.
What if the numbers are marginal?
Then the free upstream improvements are the project. They may make the software case later, and that is a useful outcome too.
Who should the case be written for?
Whoever will ask the hardest question, which is usually where the number came from. Write for them and everybody else is satisfied.