Most RPA business cases fail to get approved not because the technology is wrong, but because the financial argument is incomplete. Operations teams describe what the bot will do. Finance needs to know what the organization will gain, what it will spend, when it will break even, and what happens if the project is delayed or cancelled. Those are four distinct questions, and most submissions answer only the first one in detail. This post provides a structured methodology for building an RPA business case that addresses all four — with enough specificity to survive a CFO review.

Why most RPA business cases are rejected at the finance stage

The most common failure pattern we see is a business case built by an operations team that has already decided to automate and is now working backward to justify the decision. The narrative leads with the technology, the savings estimate uses base salary only, the implementation cost is a single vendor quote, and the risk section is a brief paragraph reassuring the reader that the project will be managed carefully. Finance teams recognize this structure immediately. It signals that the author has not done the financial work.

A second common failure is scope mismatch. The process selected for the first business case is often one that the operations team finds personally frustrating rather than one that produces the highest financial return. Frustration is a legitimate signal, but it is not a financial argument. The process that is most annoying to the team running it is frequently not the process that costs the organization the most money when done manually.

The third failure is omitting the counterfactual. A business case that presents only the cost of automating, without presenting the cost of not automating, leaves the reader with no urgency. If the status quo has no quantified cost, delay is always the rational choice.

Step one: Process selection using a scored prioritization matrix

Before any financial modelling, the process must be selected on principled criteria. The selection decision should be documented and included in the business case appendix — it demonstrates analytical rigor and preempts the question of why this process was chosen over alternatives.

Evaluate candidate processes against six criteria, scored on a one-to-five scale:

• Volume: Number of transactions per month. Higher volume multiplies the value of any per-transaction time saving.
• Rule-based determinism: Can every decision in the process be expressed as an explicit if-then rule, without human judgment? Processes requiring interpretation score lower.
• Stability: How frequently does the underlying system, form, or logic change? Highly volatile processes generate ongoing maintenance cost that erodes ROI.
• Current error rate: What percentage of manual transactions produce an error requiring rework or correction? Higher error rates increase the value of automation.
• Downstream cost of error: What is the financial consequence of each error — rework labour, regulatory penalty, customer impact, audit finding? This is separate from error rate and is frequently the largest value driver.
• Data accessibility: Is the process input and output data available in structured, digital form, or does it require OCR, email parsing, or physical document handling? Higher accessibility reduces implementation complexity and cost.

Processes scoring above 22 out of 30 are strong first-automation candidates. The prioritization matrix should be shown in the business case, with scores justified briefly for each criterion. This prevents the perception that the process was selected arbitrarily.

Step two: Building the fully-loaded FTE cost baseline

The labour cost baseline is where most business cases introduce their most significant error. Base salary is not cost. In Canadian mid-market organizations, the fully-loaded cost of an employee — including statutory benefits, vacation, group benefits, employer payroll taxes, allocated occupancy, HR overhead, and management time — typically runs between 1.25x and 1.45x of base salary, depending on role level and benefit structure. Your finance team knows this number precisely. Using base salary signals that the operations team has not consulted with HR or finance in building the model.

The correct approach is to request the fully-loaded cost rate from your finance or HR business partner before building the model. If that number is unavailable, use 1.35x as a conservative multiplier and document the assumption explicitly.

Beyond the fully-loaded hourly rate, the time calculation itself must be defensible. Do not estimate time from memory. Conduct a structured time study over a minimum of two weeks, logging actual transaction time including setup, system navigation, verification, and exception handling. In our experience, initial estimates of process time are understated by 20 to 40 percent because staff do not intuitively count the time spent on exceptions, which are infrequent but time-intensive.

The FTE cost baseline should present three numbers: annual labour cost for the process at current volume, projected labour cost at forecast volume in year two and year three, and the cost of exception-handling labour separately itemized. This structure demonstrates that the model accounts for growth and that it distinguishes between routine and non-routine work.

Step three: Quantifying the value of error reduction

Error rate value is the component most consistently underrepresented in RPA business cases, and it is the component that most frequently determines whether a marginal case becomes approvable.

To quantify error value, you need four inputs: the current error rate (errors per hundred transactions), the average labour time to detect and correct an error, the fully-loaded cost rate of the staff performing rework, and the downstream financial consequence of errors that are not caught before they create an external impact.

That fourth input — downstream consequence — requires category-specific thinking. In accounts payable, undetected errors produce duplicate payments, missed early-payment discounts, and vendor relationship damage. In order processing, errors produce fulfilment failures, customer credits, and potential churn. In compliance reporting, errors produce regulatory findings, remediation costs, and in regulated industries, potential fines. In HR data management, errors produce payroll corrections and, in worst-case scenarios, tax filing amendments.

For each error category, build a simple expected-value calculation: error rate multiplied by transaction volume multiplied by average cost per error. Sum across categories. In organizations we work with, this calculation produces a number that is frequently between 30 and 80 percent of the pure labour saving — a material addition to the ROI case that most business cases leave on the table.

Step four: A transparent implementation cost breakdown

Single-line implementation cost estimates do not survive finance review. The implementation cost section must itemize costs by category, distinguish one-time from recurring costs, and identify which costs are internal (staff time) versus external (vendor and consulting fees).

The ranges above reflect typical mid-market deployments of a single attended or unattended bot on a moderately complex process. Multi-bot deployments or processes involving legacy systems with no API access will sit at the higher end. Present your specific vendor quotes against these ranges to demonstrate market awareness.

One cost that organizations consistently omit is the ongoing maintenance budget. RPA bots are not fire-and-forget deployments. When the underlying application changes — a UI update, a field rename, a new mandatory field — the bot breaks. In our experience, a well-maintained bot on a stable process requires between 8 and 15 hours of maintenance labour per year at minimum. Budget for this explicitly. Finance will ask about it, and an answer of “the vendor handles it” is not sufficient unless it is written into the contract at a specified rate.

Step five: Payback period and three-year NPV

Present both payback period and three-year net present value. Payback period is the metric finance uses to make the initial go-or-no-go decision. Three-year NPV is the metric used to rank competing projects in a constrained capital budget.

Payback period is calculated as total one-time implementation cost divided by net monthly benefit (monthly labour saving plus monthly error-reduction value, minus monthly recurring licensing and maintenance cost). State the result in months, not fractions of a year. “14 months” is a concrete statement. “1.17 years” is not.

For three-year NPV, use your organization’s standard discount rate. If you do not know it, use 8 percent as a reasonable mid-market proxy and document the assumption. Apply volume growth to the benefit calculation in years two and three if the organization has a credible growth forecast for the process in question. Do not apply growth assumptions to cost savings without applying them to implementation maintenance cost as well — inconsistent growth assumptions are a red flag for finance reviewers.

Step six: The risk section finance actually needs

Most business case risk sections describe implementation risks — project delays, vendor performance, technical complexity. Finance already knows these exist. What they need from a risk section is two things: a quantification of the probability-weighted downside on the investment, and a quantification of the risk of not proceeding.

For investment risk, take your conservative case scenario and calculate the worst-case payback period. If the worst-case payback is still within 24 months, say so explicitly. If it is not, identify which cost or benefit assumption drives the exceedance and explain what controls reduce that risk.

For the cost of inaction, quantify what the status quo costs the organization over the same three-year window. This is the sum of the labour cost baseline, the expected error cost, and any growth in those costs at forecast volume. In most cases where the base-case ROI is positive, the cost of three years of inaction materially exceeds the worst-case implementation cost. Presenting this number reframes the decision from “should we spend money on automation” to “should we accept a certain loss to avoid an uncertain investment.”

Name the specific risks that are realistic for your process, and for each one, specify the mitigation and the residual risk. Four to six risks, each with a one-line mitigation and an estimated probability, is the appropriate level of detail. A list of twenty generic risks with no probabilities is not a risk section — it is a disclaimer.

One-page business case template structure

The executive summary page — the page a CFO actually reads — should contain the following sections in this order:

1. Process and scope: One sentence naming the process, the systems involved, and the current monthly transaction volume.
2. Current state cost: Annual fully-loaded labour cost plus annual error cost, with the methodology stated in a footnote.
3. Proposed solution: One sentence on the automation approach (attended vs. unattended, platform, hosting).
4. Implementation investment: Total one-time cost and annual recurring cost, itemized at the category level from the table above.
5. Annual benefit: Labour saving plus error reduction saving, separately stated.
6. Payback period: Stated in months, base case and conservative case.
7. Three-year NPV: Base case only on the summary page; full scenario analysis in the appendix.
8. Key risks and mitigations: Three bullet points, one line each.
9. Recommendation and ask: One sentence requesting specific approval of a specific budget amount to proceed to a defined next step.

Everything else — the process map, the time study data, the vendor evaluation, the detailed risk register, the scenario models — belongs in appendices. Finance should be able to approve the project from the one-page summary and verify assumptions in the appendices if they choose to. A business case that buries the financial conclusion on page twelve will not be read to page twelve.

Frequently asked questions

What transaction volume justifies an RPA business case?

There is no universal threshold, but in our experience, processes with fewer than 200 transactions per month rarely produce a payback period under 18 months at typical mid-market implementation costs. The exception is processes where the error-consequence value is unusually high — regulatory filings, financial close activities, or customer-facing transactions where a single error produces a material financial or reputational cost. If your process has low volume but high error consequence, build the case around error reduction rather than labour saving.

Should the business case commit to headcount reduction?

This is the question that makes most operations teams uncomfortable, and it is also the question finance is implicitly asking. The honest answer depends on what the freed capacity will actually be used for. If the FTE time saved will be redeployed to higher-value activities — and you can name what those activities are — say so explicitly. If headcount reduction is the actual plan, say that too. Business cases that claim labour saving but refuse to specify what happens to the labour are not credible. Finance will assign a lower probability of benefit realization to savings that have no clear mechanism for capture.

How should we handle processes that partially involve judgment or exceptions?

Automate the rule-based portion and design explicit exception-handling handoffs for the judgment-dependent portion. The business case should reflect only the automation of the rule-based transactions — typically 60 to 85 percent of volume — and should model the exception-handling labour separately. A common mistake is claiming automation of 100 percent of volume when 15 percent of transactions require human review. Finance will find this during due diligence, and it materially revises the benefit calculation.

What is the right level of detail for vendor cost estimates?

Get at least two vendor quotes at the statement-of-work level — not ROM estimates, but scoped proposals against a defined process specification. Use the higher quote as your implementation cost assumption and note the range. Single-vendor quotes suggest the analysis is not competitive. Estimates without a scope document suggest the vendor has not understood the process. Finance teams that have seen cost overruns on technology projects — which is most of them — will ask how the estimate was derived.

What happens if the project is approved and the bot underperforms?

Define your success metrics before go-live and include them in the business case. Specify the transaction volume the bot will handle, the error rate threshold it must maintain, the uptime requirement, and the timeline for reaching steady-state performance. Build a post-implementation review into the project plan at three months and twelve months. If the bot underperforms against defined metrics at three months, you need a decision point — remediate or exit — with a cost estimate for each path. Finance is more comfortable approving projects where the exit conditions are defined than projects where “we’ll figure it out if there are problems.”

How to Write an RPA Business Case That Finance Will Actually Approve

Most operations and IT leaders have experienced the frustration of an RPA initiative stalling at the finance approval stage despite a genuine business need. This post provides the specific financial methodology — process selection scoring, fully-loaded FTE costing, error-value quantification, transparent implementation cost breakdown, scenario-based payback analysis, and risk quantification — that transforms an advocacy document into an approvable investment proposal.