Ad Hoc Reporting in FP&A: When the Same Quick Question Keeps Coming Back
The request usually starts with “quick question.”
Can we see gross margin by customer? Can we split that by region? What did the last six weeks look like? Can you add headcount? And maybe bookings?
By lunch, the quick question has its own workbook.
Ad hoc analysis is part of FP&A. Management should be able to ask questions that were not anticipated when the monthly reporting pack was designed.
But when the same kinds of “one-off” requests keep coming back, I stop treating them as interruptions.
Repeated ad hoc reporting is often management telling Finance what the regular reporting process forgot to answer.
The request is usually more useful than the requested report
A CFO asking for revenue by customer may not actually want another customer revenue report.
They may be worried about concentration.
A CEO asking for weekly payroll may be worried about the pace of hiring.
A business leader asking for three versions of margin may be trying to understand whether growth is getting less profitable.
If Finance responds only to the literal request, we can produce a technically correct spreadsheet and miss the question underneath it.
I like asking what decision or concern triggered the request. Not as a bureaucratic intake form. Just enough to understand what management is trying to see.
That usually makes the analysis smaller, not larger.
There are good ad hoc requests
Some questions should be ad hoc.
An acquisition opportunity appears. A large customer changes behavior. A competitor changes pricing. A product launch misses. The CEO wants to know what happens if a hiring plan moves by a quarter.
Those are new questions created by new information.
Finance should be good at answering them.
The problem is when the “ad hoc” queue contains the same questions every month.
Why did services margin fall?
Which departments are driving the hiring variance?
How much cash is committed over the next eight weeks?
What changed in the forecast?
If management repeatedly asks for information after receiving the normal reporting, the reporting may be complete without being useful.
That is a different problem.
Keep a request log for a while
This sounds more formal than it needs to be.
For a month or two, write down the meaningful questions that arrive outside the normal reporting cycle.
Who asked? What did they want to know? What data was needed? How long did it take? Has the question appeared before?
Patterns show up quickly.
You may discover that five “different” requests are really one missing view of customer profitability. Or that every forecast cycle produces a scramble around hiring because the headcount forecast does not show timing changes clearly.
You may also discover that a report nobody asks about consumes six hours every month.
Finance has a strange habit of protecting scheduled work from unscheduled work, even when the unscheduled work is telling us what people actually value.
Do not automate a question you do not understand
Repeated requests naturally create pressure to automate.
Sometimes that is exactly right.
But I would not turn the third version of a report into a dashboard until I understood why the first two versions failed.
Otherwise Finance can automate the wrong answer with impressive efficiency.
The sequence I prefer is simple: understand the question, stabilize the definition, make sure the underlying data can support it, then decide whether it belongs in recurring reporting.
This is also where software versus Excel conversations get confused. A reporting problem does not become a systems problem just because somebody had to copy and paste.
The regular pack should absorb the questions that matter
A useful management reporting pack is not frozen.
If leadership consistently asks the same question after the meeting, I would rather improve the pack than admire its consistency.
That does not mean adding every requested table.
Sometimes the right answer is replacing three pages with one better view.
Sometimes it is moving a metric to the front because it has become important.
Sometimes it is removing a report that has become corporate wallpaper.
The goal is not to eliminate questions. A good finance meeting should create questions.
The goal is to stop making management ask Finance to reconstruct the same basic context every month before the useful conversation can begin.
Ad hoc work needs a cost
Not necessarily a financial charge. A visible tradeoff.
If an analysis will take two days, something else is moving.
This is especially important for small FP&A teams, where a senior analyst can lose half a week to a request that sounded like a pivot table.
I do not think Finance needs to become defensive about this. “We can do that. It will push the forecast review to Thursday. Which is more important?” is a perfectly reasonable operating conversation.
It also teaches the organization that analytical capacity is capacity.
There is no magical reserve team living behind the spreadsheet tabs.
The best outcome is not fewer requests
I would be more worried about a finance team that never gets ad hoc questions.
It can mean the reporting is extraordinary.
It can also mean the business stopped asking Finance.
The useful signal is the mix.
New questions should keep arriving because the business keeps changing. Old questions should gradually migrate into better reporting, better definitions or better access to information.
If the same “quick question” arrives for the sixth month in a row, I would not blame the requester.
At that point, it is probably part of the reporting process.
We just have not admitted it yet.
“Quick” describes the question, not necessarily the work
This distinction has saved me a lot of frustration.
A question can take ten seconds to ask and two days to answer.
“Can you show profitability by customer?” sounds simple until Finance discovers revenue is by customer, labor is by department, support cost is not allocated, and nobody has agreed whether implementation belongs in gross margin.
The request is still reasonable.
The data model simply was not waiting for it.
I like being transparent about that.
Not defensive. Not theatrical.
Just clear that analytical effort exists even when the final output is one chart.
I separate decision questions from curiosity questions
Both can be valuable.
But they do not deserve identical priority.
“What happens to cash if we delay these hires?” is attached to a decision.
“Can we see revenue by day of week for the last four years?” might be interesting, but I want to know what we plan to do with the answer.
I am not hostile to curiosity. Some of the best analysis begins there.
I just want the team to understand whether a request affects a decision, tests a concern, explores an idea or satisfies curiosity.
That context changes how much precision and time I would invest.
The first version should often be smaller
FP&A people have a dangerous tendency to hear a question and immediately imagine the complete analytical product.
Customer profitability request?
Great. We will build a fully allocated profitability model with cohort trends, segmentation and an interactive dashboard.
Or we could spend an hour testing whether the concern is real.
I like a small first answer when the question is still being formed.
Show the directional data. See what management notices. Then deepen the analysis where it matters.
This reduces wasted work and often improves the final question.
The first analysis is sometimes reconnaissance.
Repeated requests are product feedback for Finance
I think of the recurring reporting package as a product.
Management uses it. Their questions are feedback.
If everyone asks for the same missing view, the product is telling us something.
Maybe the reporting pack needs to change. Maybe a dashboard needs a new dimension. Maybe the metric definition is unclear. Maybe managers need self-service access to a stable dataset.
The answer is not automatically “add another page.”
Sometimes the best response is removing three existing pages nobody uses and replacing them with the one view people keep requesting.
Reports should earn their square footage too.
Definitions are where ad hoc analysis quietly gets expensive
Gross margin by customer sounds straightforward until someone asks what counts as customer-level cost.
Active customer sounds straightforward until Sales, Finance and Product have three definitions.
Bookings sounds straightforward until renewals, expansions and cancellations enter the conversation.
A lot of “analysis time” is actually definition time.
I do not see that as wasted work.
Stable definitions are infrastructure.
Once Finance resolves them, the next question gets easier.
But I want to capture the decision instead of re-litigating the definition every time someone opens a new workbook.
Self-service works only after the data is trustworthy
There is a natural response to too many ad hoc requests: give everyone a dashboard.
I like self-service when the underlying data, definitions and permissions are mature enough to support it.
I do not like giving thirty people a powerful reporting tool and then spending the next quarter explaining why they produced thirty different revenue numbers.
Self-service does not eliminate governance.
It moves some of the analytical work closer to the user.
That is valuable only if people can interpret what they are seeing.
A dashboard is not a substitute for shared definitions.
Ad hoc requests can expose missing dimensions in the data
If management repeatedly asks for profitability by product, region, customer segment or channel and Finance cannot answer without manual work, that may be a data-design problem.
The question is telling us which dimensions the business actually uses to make decisions.
I would rather learn that from real management demand than build a giant data model because someone said we might need it someday.
Repeated questions reveal where additional structure has value.
That is useful information for Finance, Accounting and data teams.
Protect senior FP&A time from becoming a report factory
Ad hoc work often lands on the people most capable of answering it.
That makes sense once.
It becomes a problem when a senior finance person spends every week manually rebuilding recurring cuts of data.
If a request is valuable and recurring, I want to make the process cheaper over time.
Automate the stable part. Document the definition. Delegate production where appropriate. Keep senior attention on interpretation and decisions.
The goal is not to protect people from work.
It is to stop paying for the same discovery repeatedly.
Urgency needs a definition too
Everything becomes urgent when there is no cost to calling it urgent.
I like asking when the answer is actually needed and what decision occurs then.
Sometimes “ASAP” means the CFO has a board call in two hours.
Fair enough.
Sometimes it means somebody would enjoy looking at it today.
Also fair enough, but different.
Small teams especially need a visible way to trade priorities.
If this analysis moves to the front, what moves back?
That is not Finance being difficult.
That is capacity management.
Some questions should stay ad hoc forever
Not every useful analysis deserves recurring production.
An acquisition model may be used once. A pricing scenario may answer a specific decision. A customer issue may disappear after it is resolved.
I do not want to automate every question simply because it mattered once.
Recurring reporting should contain recurring information needs.
Ad hoc analysis should remain available for the weird, new and important things businesses keep doing.
The goal is not to eliminate one-off work.
It is to keep one-off work from secretly becoming recurring work without anyone redesigning the process.
I pay attention to what nobody asks for
This is the other half of the request log.
If Finance spends hours producing a report and nobody references it, asks about it or uses it in a decision, I get curious.
Maybe the report is so clear no questions are necessary.
Possible.
Maybe it has become corporate wallpaper.
Also possible.
Recurring reports survive through inertia remarkably well.
Ad hoc demand gives us a useful contrast: here is what management actively wants to understand versus what Finance automatically produces.
I think both sides deserve review.
A healthy FP&A team should still get interrupted
I do not want to engineer every surprise out of Finance.
Businesses change too quickly for that.
A new competitor appears. A customer changes behavior. A product misses. A deal emerges. Leadership sees something strange and asks Finance to investigate.
Good.
That means Finance is part of the conversation.
What I want is a team with enough operating rhythm and enough spare analytical capacity to respond without blowing up every recurring process.
The objective is not fewer questions.
It is better questions, fewer repeated discoveries, and a reporting system that learns from what management keeps asking.
If the same “quick question” appears for the sixth month in a row, it is no longer ad hoc.
It is a requirement wearing casual clothes.









At what point does an ad hoc request stop being ad hoc? If the same question shows up three months in a row, I’m probably building it into the process.