An ROI figure for accounts payable automation is only as good as its inputs, and the difference between a case that survives scrutiny and one that does not is whether those inputs were measured in your own team or borrowed from an industry report. Five numbers, gathered in an afternoon, produce arithmetic nobody can argue with.
The three that size the cost
Monthly invoice volume. Median minutes from an invoice arriving to it being approved, timed through ten invoices rather than estimated. And the fully loaded hourly cost of the people doing that work, meaning salary plus employer costs divided by worked hours. Multiplied together these give your current spend on the mechanical part.
The one that caps the saving
The share of invoices arriving with both a purchase order and a recorded goods receipt. An invoice with nothing to match against needs a person regardless of software, so the saving applies only to the matchable share. Omitting this input is the single commonest way an ROI figure gets overstated and then challenged.
The one that makes it net
The software cost per month, including implementation amortised over a sensible period. Subtracting it turns a gross saving into a net figure, which is the number the decision actually turns on. A calculation that reports gross saving is answering a question nobody asked.
Questions people ask about accounts payable automation roi
What if the ROI is marginal?
Then the free upstream improvements are the project, and they may make the software case later. That is useful information, not a failure.
Should we include exception handling time?
Measure it separately, since it is what automation touches least. Blending it hides that and inflates the apparent saving.
How conservative should we be?
Cap the saving at your measured coverage and state the assumption. Conservative figures survive questions; optimistic ones invite them.