The fastest way to lose an AP automation business case is to open with an industry average cost per invoice. The person deciding will ask where the number came from, whether it applies to your business, and why they should believe it, and the case never recovers. Five numbers, all of which you can gather from your own team in a day, make a case that is harder to argue with precisely because none of it was borrowed.
The five numbers
Monthly invoice volume. Median minutes from an invoice arriving to it being approved, timed rather than estimated. The fully loaded hourly cost of the people doing that work. The share of invoices that have a purchase order and a goods receipt behind them. And the annual cost of the software you are proposing. Everything else in the case is arithmetic on those five, which is what makes it defensible.
How to combine them without overclaiming
Volume times minutes times rate gives current spend. The purchase-order share caps what can clear untouched, so apply the saving only to that portion rather than to everything: claiming a saving on invoices that will still need a person is the mistake that gets a case rejected. Subtract the software cost. The result is deliberately conservative, and being conservative is what makes it credible.
What to put in the case that is not a number
State plainly what does not improve: judgement on exceptions, supplier disputes, and anything about invoices with no order behind them. State the risks: implementation time, the change in how approvals are done, and what happens if the provider disappears. A case that names its own limits is read as honest, and it is the one that gets approved.
Questions people ask about ap automation business case
Should I include soft benefits like control and audit trail?
Include them, but as capabilities rather than dollar figures. Inventing a value for an audit trail invites an argument about the invented number and distracts from the arithmetic that is solid.
What if the numbers do not justify it?
Then you have learned something valuable cheaply, and you probably have a process problem rather than a software problem. Low purchase-order coverage in particular is fixed by policy, not by purchase.
How conservative should the touchless assumption be?
No higher than your measured purchase-order and goods-receipt coverage, since an invoice with nothing to match against cannot clear on its own regardless of the software.