Most Financial Analysis Cannot Be Templated. Here Is What That Costs

The recurring monthly pack is the visible part of a finance team's work. The larger share is triggered by something unexpected, follows from the specifics of whatever happened, and cannot be templated by definition, because templating requires knowing the question in advance.

In our discovery conversations with mid-market finance leaders, roughly 80% of analytical work was described as on-request rather than templated. That figure is self-reported by the CFOs we interviewed rather than measured, so treat it as directional. The pattern was consistent enough that we built a company around it.

What makes work templatable

A template encodes a question you already know how to ask. Monthly revenue by segment. Headcount against plan. Cash position by entity. The question is stable, the shape of the answer is stable, and the work is genuinely repeatable, so it should be automated, and modern FP&A platforms automate it well.

Ad-hoc analysis fails every one of those conditions. The question arises from something that just happened. The shape of the answer depends on what you find partway through. And the next instance will be a different question about a different part of the business.

Consider a real sequence. Gross margin falls two points. That triggers a decomposition by product line, which shows the decline is concentrated in one product. That triggers a look at that product's input costs, which are flat, so it is a pricing question, which means pulling discount data from the CRM and joining it to the ledger by customer. Four analyses, each determined by the result of the last. No template survives step two.

Where the hours actually go

The instinct is that analysis is the expensive part. In practice, assembly is.

For a typical ad-hoc request, the time splits roughly like this:

Step	Share of time
Working out what the question actually is	10%
Locating and exporting the data	25%
Reconciling systems that disagree	25%
Shaping the data into an analysable form	20%
The analysis itself	10%
Presenting it	10%

Roughly seventy per cent is plumbing. That proportion is why the work feels so disproportionate to the insight it produces, and it is also the good news: plumbing does not require judgement.

Why it stays invisible

Ad-hoc analysis appears in no budget. There is no line item, no requisition, no project code. The hours come out of salaries already being paid, so the cost never registers as spend, only as work that did not get done.

This has a specific organisational consequence. Because the cost is invisible, it never gets managed. Nobody tracks ad-hoc request volume the way they track ticket volume in support. Nobody measures time-to-answer. A workload consuming a meaningful share of the most expensive people in the finance function operates with no instrumentation at all.

The first useful step for most teams is simply counting. Log every ad-hoc request for one month: who asked, what they wanted, how long it took including rework. The total is almost always larger than anyone expected.

Why the obvious fixes do not work

Better reporting

Some ad-hoc requests are really just missing reports, and building those removes them permanently. That is worth doing, and it reduces volume.

But it does not touch genuinely novel questions, and it can increase them. Better visibility surfaces more anomalies, and every anomaly worth seeing is an anomaly worth investigating. Teams often find that improving their reporting increases ad-hoc load in the short term.

Hiring

An analyst adds capacity. They do not immediately add speed, because ad-hoc work requires business context: knowing which numbers can be trusted, which customer is an exception, why last March is not comparable. That takes months to acquire, and until then a new analyst can execute but not interpret.

There is also a matching problem: headcount is a fixed cost and ad-hoc demand is variable. You staff for the average and are underwater in the weeks that matter.

General-purpose AI

Every finance leader we have spoken to has tried it. The blocker was consistently verification rather than capability. A language model generates arithmetic as text rather than computing it, and it fills gaps in company-specific context with plausible assumptions it does not disclose.

One CFO described an AI spreadsheet agent that failed to understand the requirements and produced incorrect calculations. Another was building his own cash forecast against his ERP's API and found it too brittle to rely on. These are technically sophisticated buyers who tried and stopped, which is a stronger signal than a market that has not tried at all.

What automation should actually mean here

The mistake is assuming automation means templating. It does not, and it cannot: you cannot template a question nobody predicted.

What can be automated is the seventy per cent that is plumbing:

• Data lives in one place, continuously, rather than being exported per question.
• Systems that disagree are reconciled once, as a rule, rather than every time.
• Metric definitions and business exceptions are captured once and applied automatically to every subsequent analysis.
• The shaping step happens on demand rather than by hand.

The analytical judgement stays with a person. What changes is that a novel question costs minutes of assembly rather than days, which changes which questions get asked at all.

The second-order effect

The direct cost of ad-hoc analysis is hours. The larger cost is the questions nobody asks.

Once a team learns that a particular question takes three days, people stop asking it. The question does not go away: the decision it would have informed simply gets made on a worse basis, or on instinct. In most finance functions this is the biggest cost of the four, and the only one that never appears anywhere.

Reducing the cost of an answer does not just save time on the questions you currently ask. It changes the set of questions that are worth asking, which is a different and larger effect.

Why the 20% is the part that gets automated

The templatable fifth of financial analysis has a property that makes it irresistible to software: it is knowable in advance. A monthly P&L, a budget-versus-actual, a cash summary: someone can specify them once, and a product can be built against the specification.

The other four-fifths cannot be specified in advance, because the question arrives in response to something that just happened. That is not a gap in the market so much as a structural property of the work, and it explains why finance teams can own capable software and still spend their month in Excel.

What the untemplatable work looks like

• A board member asks why one region missed, and the answer needs revenue joined to the CRM by segment.
• A lender wants a downside case with two specific customers removed.
• Someone proposes three hires and wants the cash impact by month, at a start date that has not been decided.
• Margin moved and nobody yet knows whether it is price, mix, or a reclassification.
• A large customer is renegotiating and you need concentration exposure recut by contract value rather than revenue.

None of these were on a report. All of them are ordinary. Each one requires locating data across systems, reconciling it, and building something new, and each is urgent, because somebody is waiting.

Where the time actually goes

The instinct is that the analysis is the slow part. Instrument it and the split is usually the opposite: roughly 70% of elapsed time is assembly: locating the data, exporting it, reconciling systems that disagree, normalising identifiers, and rebuilding last period's comparison, and the analytical step is often the shortest.

This matters for what you buy. A tool that makes the analysis faster is optimising the smaller half. A tool that removes assembly is optimising the larger one, and the two are frequently sold with the same words.

Measuring it in your own function

Two weeks of logging settles the argument. For every ad-hoc request, record who asked, who answered, how long it took, how many systems it touched, and whether the answer led to a decision.

Three things usually fall out. First, the volume is higher than anyone estimated, because the work is distributed and invisible. Second, the senior people handle the hard ones: the CFO or VP Finance personally, because those questions require knowing the business rather than knowing the spreadsheet. Third, there is a queue of questions that were never asked because the answer would have taken three days.

That third number never appears in a budget, and in most finance functions it is the largest of the three.

What this means for what you buy

If most of the work cannot be specified in advance, then a product specified in advance can only ever address the smaller share of it. That is not an argument against reporting platforms: the templatable fifth is real, recurring, and genuinely worth automating.

It is an argument for being precise about which fifth you are buying, and for measuring the other four-fifths before assuming a better report will absorb them.