How to build a business case for travel payment automation

Once you've decided travel payment automation is worth exploring, the next question is how to make the case internally. A business case needs two things: a credible baseline of what the current process is actually costing, and a realistic projection of the value automation would deliver. Most internal cases fail at the first step: the baseline is incomplete, and the value case looks weaker than it should.

This article gives you the framework for both, plus how to structure the case for a CFO or board that will push back on optimistic numbers. If you're not yet sure how virtual card automation works, start with our guide to travel supplier payment automation; once the case is approved, the step-by-step implementation guide covers what a rollout involves. And finally, please note that all calculations here are illustrative. The methodology is what matters; the numbers are yours to fill in.

Why the cost baseline is where most business cases fail

The instinct when building a business case is to start with the projected benefits. That instinct leads to trouble, because benefits projected without a measured baseline are difficult to defend and easy to dismiss.

The stronger approach is to start by documenting what the current process is actually costing. That means measuring staff time, error rates, FX losses, reconciliation burden, and missed interchange income before a single projected saving is written down. When the cost baseline is robust, the value of automation is not a claim. It is the gap between a documented current state and a defined future state.

Building your cost baseline

Staff time and manual processing costs

Start by measuring the time cost of the current payment process. How long does it take to process one supplier payment from start to finish: generating the payment, processing it, and filing the record? Multiply that by monthly transaction volume and by the hourly cost of the finance team member handling it.

This gives you the direct processing cost. Add to it the time spent on payment-related queries: chasing suppliers for invoices, responding to payment confirmation requests, resolving disputes. These are real costs that often sit outside the standard payment processing measure.

For example: if processing one payment takes 15 minutes and the business processes 1,000 payments per month, that is 250 hours of finance team time per month on payment processing alone. At a fully loaded cost of £40 per hour, that is £10,000 per month (or £120,000 per year)

Error correction and reconciliation overhead

Error correction is consistently underestimated in payment process cost analyses. Measure the frequency of payment errors (wrong amounts, wrong suppliers, missed payments) and the time required to identify and correct each one. In manual processes with multiple data entry points, error rates of 2–5% of transactions are common.

Reconciliation overhead is the time spent matching settlement records against booking records, identifying variances, and investigating discrepancies. In multi-currency environments this is amplified: each currency pair adds its own reconciliation layer. Track the hours per month and value them at the finance team rate.

FX losses and settlement timing costs

FX losses in travel supplier payments come in two forms: the conversion spread on each currency transaction, and the working capital cost of settlement timing mismatches. The spread is relatively visible. The timing cost is not.

To estimate timing cost: identify the average gap between booking confirmation and payment settlement for your supplier base. For each day of that gap where the exchange rate could move, there is a potential exposure. Aggregate this across your monthly currency payment volume to get a sense of the scale. This is a directional estimate rather than a precise figure: your treasury or finance team can refine it.

Interchange revenue you are not yet capturing

For businesses that use virtual cards for some but not all supplier payments, there is a calculable interchange income gap. The calculation starts with the volume of payments currently going by bank transfer that could, in principle, go by virtual card. Apply the interchange rate range applicable to your programme.

This is income that exists in the payment flow but is not being captured. In the business case, it appears as an opportunity cost of the current process rather than a projected saving from automation, which is a more credible framing.

Projecting the value of automation

Once the cost baseline is documented, the value of automation is the portion of that baseline that automation removes or reduces. For each cost component in the baseline, define what happens to it under the automated process:

• Staff time on payment processing: reduces significantly for each transaction that is issued and settled automatically. Some overhead remains for programme management and exception handling.
• Error correction: reduces in proportion to the error rate improvement. Automated processing eliminates manual data entry errors. Programme-level errors still require investigation.
• Reconciliation overhead: reduces substantially. Automated matching removes most of the manual matching workload. Variances still require human review.
• FX settlement timing cost: reduces when settlement becomes faster and more consistent.
• Interchange income gap: closed progressively as supplier coverage is extended. This is an addition to the revenue line, not just a cost reduction.

The projected annual value of automation is the sum of these reductions and additions, net of the ongoing cost of the automated programme. Label every projection as illustrative. The methodology is what makes the case credible, not the size of the numbers.

Accounting for switching costs

Switching costs are one-time, not ongoing. The business case should present them as an investment with a defined payback period rather than as a comparison against the current annual run-rate cost.

The main switching cost components are: integration development (either in-house or through a provider implementation team), onboarding and configuration time, internal project management resource, staff training and process change communication, and the cost of running parallel processes during the transition period.

A payback period is calculated by dividing the total switching cost by the projected annual net benefit. If the switching cost is recovered within 12–18 months, the case is strong. If it takes longer, the case may still be sound depending on the risk profile and strategic value. But it needs more careful framing.

Structuring the case for a CFO or board

The most effective structure for presenting a payment automation business case is: current state cost (documented and sourced), future state cost (projected with methodology), one-time switching investment, payback period, and ongoing annual benefit.

CFOs and boards are sceptical of optimistic projections and comfortable with conservative ones that have strong data behind them. Do not inflate the benefit case. If the numbers support the investment at 50% of the projected benefit, say so. A conservative case that holds up under scrutiny is more persuasive than an optimistic one that cannot be defended.

The risk section matters too. What could go wrong? Integration taking longer than planned, supplier adoption being slower than expected, reconciliation output needing adjustment post go-live. Acknowledging these and explaining how they are managed is a sign of a well-constructed case, not a weakness.

Ready to start building the case? Explore Modulr's travel payments solutions to discover how we could support your specific payment volume and supplier mix.

This article is for informational purposes only and should not be construed as financial, legal, or regulatory advice.

TL;DR

A strong business case for travel payment automation starts with a documented cost baseline: staff time, error correction, FX losses, reconciliation overhead, and missed interchange income. The value of automation is the gap between that baseline and the automated future state. All projections should be labelled as illustrative. Switching costs should be framed as a one-time investment with a defined payback period.

FAQs

What costs should be included in the baseline for a travel payment automation business case?

The baseline should include: staff time spent on manual payment processing and reconciliation, error correction costs when payments are wrong or late, FX losses from unmanaged currency conversion, reconciliation overhead across multiple currencies, and interchange income that is currently not being captured because payments go by bank transfer rather than virtual card. Missing any of these understates the value of automation.

How do I calculate the finance team time cost of manual payment processing?

Start by tracking the time spent per transaction: how long it takes to generate a payment, process it, and match the settlement record against the booking. Multiply by transaction volume and by the cost of the finance team hours involved. Then account for error correction separately. This is often a significant additional cost that is not captured in standard time-per-transaction estimates.

Are the ROI figures in this guide guaranteed?

No. All calculations in this article are illustrative. They show the methodology for building the business case, not the specific savings your business will achieve. The actual value of automation depends on your payment volume, supplier mix, current error rate, and programme configuration. Use the framework to build your own numbers from your own baseline data.

What switching costs should I include in the business case?

Switching costs include integration development time and cost, onboarding fees, internal project management resource, staff training, and the cost of running parallel processes during the transition period. These are one-time costs, not ongoing. Frame them as an investment with a defined payback period rather than as a comparison to the ongoing run-rate cost of the current process.

What does a CFO or board want to see in a payment automation business case?

A CFO or board typically wants to see: a credible cost baseline with documented sources, a projected annual benefit with a clear methodology, a one-time switching cost with a defined payback period, and an honest assessment of implementation risk. Avoid projections that cannot be substantiated. A conservative case with strong data is more persuasive than an optimistic one that cannot be defended.