How to build the internal business case for AI automation (with a one-page template)

Someone on r/Accounting wrote the sentence that starts this whole problem. They had just joined a nonprofit doing every accounting function by hand and wanted to fix it, but they were stuck: "I need some data that shows how costly it is that we are on this completely paper-driven model." That is the artefact almost nobody hands them. This is it. The two ways these estimates get laughed out of the room are made-up percentages and hidden ongoing costs, and the template below avoids both.

Because they lead with a vendor's ROI figure instead of the company's own numbers. The category is full of unsourced claims like 30 to 200 per cent ROI and save 40 per cent of labour, and any decision-maker who has been around a while discounts them on sight. A number you cannot show the working for is worse than no number. The fix is to build the case entirely from your own measured inputs and clearly-labelled assumptions. Nobody argues with here are the four numbers, here are the two assumptions, change them if you disagree. That is also exactly how the buildAutomation payback calculator is built: every figure is driven by the assumptions you enter, and it says so on the page. There is a second reason cases get rejected. The person who understands the problem best is usually not the person who controls the budget. As one operator put it on r/automation, the person who knows the process best is always a non-technical person; the knowledge is there, the interface isn't. The one-page template is that interface. It turns lived frustration into a number a CFO can sign off.

Four inputs. No more. First, people: how many staff touch this process each week, counting the humans doing data entry, chasing, and re-typing the same job into a second system, not the departments. Second, hours each, per week: the honest number, not the guess. If you do not know it, do not invent it, measure it first. Third, loaded hourly rate: not the bare wage, but wage plus on-costs (superannuation, leave loading, WorkCover, payroll tax, plus the desk and software the person sits behind). A rough loaded rate is the base wage times 1.25 to 1.4, so a forty-dollar-an-hour bookkeeper costs the business roughly fifty to fifty-six dollars an hour. Fourth, automatable share: the proportion of those hours that is genuinely repetitive, rule-based work, not the judgement calls. The buildAutomation calculator defaults this to 60 per cent because that is the repetitive share we typically find when we map admin work, but you should change it if your process is different. Then multiply: weekly hours reclaimable = people times hours each times automatable share; annual hours = weekly hours times 48 working weeks; annual staff-time cost = annual hours times loaded rate. Worked example, using the calculator's own defaults: four staff, six admin hours each per week, a fifty-five-dollar loaded rate, 60 per cent automatable. That is 4 x 6 x 0.60 = 14.4 hours reclaimable every week, 691 hours a year, worth about 38,000 dollars a year in staff time spent on work a machine could do. This is what the r/Entrepreneur poster meant with the phrase that sticks: expensive people doing data entry work.

Measure it, do not guess it. The best method in the research came from r/Entrepreneur: have your team leads track everything for two weeks, every task, then sort it by whether it actually requires a human brain or not. In that operator's experience, about a third of what senior people do is completely mechanical, the same template and inputs and output every time. Two weeks of a simple time log beats any assumption, and it makes your case bulletproof because the hours are measured, not claimed. It also tends to reveal the hours are higher than anyone guessed.

Manual processes fail in a second way that pure time-saving misses: mistakes. A miskeyed invoice, a wrong GL code, a payment applied to the wrong job. Each one costs time to find and fix, and sometimes hard money. Cost it the same assumption-driven way: annual rework cost = errors per month times time to fix each in hours times loaded rate times 12, plus any hard cost per error such as a clawed-back claim, a re-issued invoice, a late-payment penalty, or a lost customer. You will not have exact figures, and that is fine. State the assumption: we estimate roughly eight keying errors a month, twenty minutes each to trace and fix. Even a conservative rework number often adds ten to twenty per cent on top of the pure time cost, and it speaks to risk, which is the language finance and compliance actually respond to. It also counters the quiet objection that we cope fine. Coping has a cost, and this is where it hides.

This is the line most vendors blur, so make it the clearest part of your page. There are two ways to buy the fix, and they have completely different shapes. Option one, rent it from an agency: a done-for-you agency charges a monthly retainer, effectively forever. On r/automation one operator described replacing a 3,000-dollar-a-month retainer with a workflow that ran on about fifty dollars a month in credits. The retainer's real product is not the workflow, it is your dependency on them. At 1,500 dollars a month, that is 54,000 dollars over three years, and you still would not own it. Option two, build it once and own it: a one-time build cost, then a small ongoing running cost, usually tens of dollars a month in API and tool credits, not thousands. This is the buildAutomation model, training two or three of your own staff to build and own the automation, so there is no retainer and no single point of failure when a consultant leaves. Your page needs both a one-time line and an ongoing line. Never fold them together. A CFO wants to see the capital cost separately from the run-rate.

Payback period is the one number that closes the case. It is the one-time build cost divided by the annual saving, expressed in months: payback period = one-time build cost divided by (annual staff-time saved plus annual rework saved), times twelve. Using the worked example, an annual saving of about 38,000 dollars in reclaimed time; divide the one-time build cost by that 38,000 dollar saving and multiply by twelve to get the payback in months, using the scoped quote from a buildAutomation conversation as the build-cost figure rather than a guess. A build that pays for itself inside twelve months is an easy yes. Inside six months, it is negligence not to. Two honesty rules keep this credible. First, only count hours you will actually redeploy. Reclaiming fourteen hours a week is a real saving only if those people move to higher-value work, like the analysis the r/Accounting poster had zero bandwidth for, or you genuinely need fewer hours. Say which. Second, run the calculator live in front of the decision-maker and let them change the assumptions. When they move the automatable share from 60 to 40 per cent and the case still holds, you have won.

Yes, the widely-cited figure is that around 95 per cent of enterprise generative-AI pilots deliver no measurable return, from the MIT NANDA study reported in August 2025 via Forbes and Fortune. Put it in your business case before someone else does, then answer it, because the reason it is true is the reason your case is different. The pilots that fail are the ones bought as technology looking for a use. The ones that pay back start from a single measured process cost, the one on your page, and they are owned by someone inside the business who notices when they break. That is the entire logic of the payback calculation: you are not betting on AI, you are removing a specific, quantified, repetitive cost. A business case built on your own four numbers is on the right side of that 95 per cent by construction. Source: MIT NANDA study via Forbes and Fortune, August 2025.

Everything above, on one page. Copy the headings and prompts straight into a doc. BUSINESS CASE: name the process, for example Invoice entry and reconciliation. Prepared by name and date. 1. The problem, in one sentence: what manual process, and what it stops us doing, for example we hand-key every invoice so there is zero bandwidth for month-end analysis. 2. Current annual cost: people doing this weekly; hours each per week measured over two weeks; loaded hourly rate (wage times 1.3); automatable share as a stated assumption; weekly hours reclaimable = people times hours times share; annual staff-time cost = weekly times 48 times rate. 3. Error and rework cost: estimated errors per month; time to fix each and hard cost each; annual rework cost = errors times fix-time times rate times 12, plus hard costs. 4. Total annual cost of the status quo = section 2 plus section 3. 5. Cost of the fix: one-time build cost; ongoing running cost in credits and tools per month; alternative for comparison, an agency retainer per month totalled over three years. 6. Payback: payback period = one-time build cost divided by total annual saving, times twelve; three-year net = annual saving times three, minus build plus three years running. 7. Who owns it: the two named staff who will build and maintain this in-house so it survives. 8. Australian offset if eligible: if the build qualifies as experimental development and turnover is under twenty million Australian dollars, the R&D Tax Incentive is a 43.5 per cent refundable offset that reduces the effective build cost; confirm eligibility with your accountant. Source: ato.gov.au. 9. The one risk we are naming: the honest counter-argument, for example reclaimed hours only pay back if we redeploy them; address it, do not hide it.