How Many Custom Reports Does a Finance Automation Project Actually Need?
TL;DR: Finance automation projects routinely arrive at build phase with a reporting list two to three times longer than what is actually needed, because requirements are written as descriptions of existing spreadsheets rather than as questions to be answered. Mapping each requirement to the vendor’s standard report catalogue before signing typically collapses a list of nine or ten down to two or three genuine custom builds. A requirement only justifies a custom report when it needs a grain the standard set does not expose, joins data the platform does not hold, or must match an externally mandated layout. Everything else is filters, grouping and column selection — and replicating a legacy spreadsheet layout is a change management problem, not a reporting requirement.
Introduction
Reporting is the most reliably underestimated workstream in a finance automation implementation. Approval flows get designed in workshops, integrations get architected in detail, and reporting gets a line in the business requirements document that says something like “existing reports to be replicated.”
Then build phase arrives, the list is opened properly for the first time, and it contains nine or ten distinct reports. Some of them are already met by standard templates nobody looked at. Some are the same report requested twice by two departments using different names. A few are genuinely new. Nobody knows which is which, because the mapping exercise that would have told them was never scheduled.
What follows is usually a difficult conversation, and it is difficult for a structural reason rather than a commercial one: neither side established a shared definition of what counts as a report before the work started. This article covers how to run that scoping exercise properly. It is about requirements discipline, not about analytics design — for the operational cost of poor reporting once a system is live, see why manual financial reporting prevents data-driven decisions.
For requirements practice see the International Institute of Business Analysis, PMI’s project scoping resources and AICPA finance transformation guidance.
Why Do Reporting Requirements Get Underestimated?
Reporting requirements get underestimated because they are gathered in the customer’s existing vocabulary and specified last, which conceals both duplication and overlap with what the platform already provides.
A finance team asked to list its reporting needs will naturally describe the artefacts it currently produces. The answer is a list of spreadsheets: the weekly ageing file, the monthly accrual pack, the payment status tracker. Each is described by its filename and its columns. None is described by the question it answers.
That framing causes three predictable problems.
The same report gets counted several times
Payables reports an ageing view. Treasury reports an outstanding-commitment view. The controller reports an unpaid-invoice summary. These are frequently one report with three filter settings, but because each team named its own artefact, they enter the list as three requirements.
Layout gets mistaken for information
A requirement stated as “must look like our current file” is a formatting preference wearing the costume of a functional need. It may be a legitimate change management concern, but it is not evidence that the underlying information is unavailable.
Nobody has read the standard catalogue
Most platforms ship a substantial set of standard reports. Customers rarely review that catalogue during scoping, because at scoping time the system is abstract and the spreadsheets are concrete. So requirements are written as if the platform reports nothing out of the box.
| Dimension | Requirements written as artefacts | Requirements written as questions |
|---|---|---|
| Typical list length | Nine to twelve items | Two to four genuine custom builds |
| Duplication | High — same view named differently by each team | Removed during consolidation |
| Mapping to standard reports | Impossible, layouts do not match | Straightforward, information needs match |
| Discovered at | Build phase, under time pressure | Scoping, before contract signature |
| Typical outcome | Scope disagreement | Estimated and agreed work |
What Is the Difference Between a Standard and a Custom Report?
A standard report ships with the platform and is maintained by the vendor; a custom report is built to one customer’s specification and is maintained as a separate artefact. The distinction matters far beyond who pays for the build.
Standard reports are upgraded with the product. When the data model changes, the vendor updates them. They are tested across the whole customer base, so defects surface quickly and are fixed once. They are documented, and new team members can be trained on them using existing material.
Custom reports carry ongoing weight. Each is a distinct artefact that must be revalidated when the underlying schema changes, retested at each upgrade, and documented locally. A custom report is not a one-off cost — it is a small permanent liability, and that is the strongest argument for keeping the count low.
The definition problem
Before counting anything, both parties need a shared definition of what constitutes one report. This sounds pedantic and is the single most common source of later disagreement.
Is a dashboard combining four views one deliverable or four? If a report must be produced separately for three entities, is that one report with an entity filter or three reports? If the same data must be delivered both on screen and as a scheduled export, is that one or two? None of these has a universally correct answer. All of them need an answer written down before work starts.
How Do You Map Requirements to Standard Reports?
You map requirements by restating each one as the question it answers, then checking whether a standard report answers that question once filters, grouping and column selection are applied. Matching on information need rather than on layout is the entire technique.
The mapping workshop is short — usually a day for a mid-sized scope — and it needs the vendor’s full standard report catalogue in front of the room, including the fields, grain and filter options of each report.
The three-way classification
Each restated requirement lands in one of three buckets.
Met by standard. A standard report answers the question directly. No work required beyond training.
Met by a filtered or grouped view. A standard report answers the question once a saved filter, grouping or column selection is applied. This is configuration, not development, and it is where most of the list should land.
Genuinely custom. No standard report can answer the question at any configuration. This bucket should be small.
What to do about layout objections
When a requirement maps to a standard report but the consumer objects to the layout, the correct response is to test whether the objection survives the report actually being used. Frequently it does not — the objection was to an unfamiliar format, not to missing information.
Where the objection persists and the consumer is external, such as an auditor or a regulator expecting a mandated template, that is a legitimate custom requirement. Where the consumer is internal and the objection is preference, building a custom report to replicate a legacy spreadsheet preserves the constraints of the system being replaced. This is the same trap discussed in legacy ERP integration challenges.
Which Requirements Genuinely Justify a Custom Build?
Three conditions justify a custom build, and a requirement should satisfy at least one of them explicitly before it is accepted as custom.
Grain the standard set does not expose. The clearest case. A standard report may summarise at document level while the requirement needs line-item detail — a line-level breakdown across invoices, for instance, cannot be derived from a header-level report by filtering. Grain is a genuine structural gap.
Data the platform does not hold. If a report must combine platform data with figures from another system, it requires either a join the platform cannot perform or an export into a separate tool. Both are real work.
An externally mandated layout. Regulatory returns, statutory filings and audit templates have prescribed formats. The consumer cannot be retrained, because the consumer is not yours.
What does not justify a custom build
Familiarity, column ordering, preferred terminology, and “the previous system did it this way” are not structural gaps. Neither is a report that only one person will read once a quarter, where an export and a few minutes of manual work is cheaper than a permanent artefact.
Splitting by entity, department or period is almost always a filter rather than a report. A requirement for the same view across five business units is one report, and treating it as five is how lists inflate. Related design thinking appears in multi-entity AP automation.
| Requirement pattern | Classification | Reasoning |
|---|---|---|
| Same view needed per entity or department | Filter on one report | Entity is a dimension, not a separate report |
| Line-level detail where standard is header-level | Genuine custom | Grain gap cannot be filtered into existence |
| Must match a regulatory or audit template | Genuine custom | External consumer cannot be retrained |
| Combines platform data with another system’s data | Genuine custom | Requires a join the platform cannot perform |
| Must look like the legacy spreadsheet | Not custom | Change management issue, not information gap |
| Two teams requesting overlapping views | One report | Consolidate before submitting |
| Read once a quarter by one person | Not custom | Export and manual handling is cheaper |
How Should Reporting Be Written Into the Statement of Work?
Reporting belongs in the statement of work with four elements specified: the standard catalogue as a named appendix, the number of custom reports included, the definition of what counts as one report, and the process for handling anything beyond the allowance.
Naming the catalogue as an appendix is the most important and most often skipped. It converts “standard reports are included” from a claim into a list both parties have seen. Without it, every later disagreement becomes an argument about whether something should have been standard.
The definition of one report resolves the dashboard and multi-entity questions before they arise. The process for additions matters because reporting needs legitimately emerge during implementation, as users see real data for the first time. A scope that assumes the list is final at signature will be wrong; a scope that defines how additions are raised, estimated and agreed will hold.
Timing
Run the mapping workshop before signature, not after. Once the contract is signed, the mapping exercise stops being a joint design activity and becomes a negotiation about what was implied. The technical content is identical; the atmosphere is not.
How to Scope Reporting Requirements: A Step-by-Step Guide
Step 1 — Appoint a single reporting owner. One finance owner consolidates and deduplicates every request. Requests arriving directly from each team guarantee overlap.
Step 2 — Restate each request as a question. What question does this answer, and what decision does it drive? Requests that cannot survive this restatement usually should not survive at all.
Step 3 — Obtain the standard catalogue. Full list, with fields, grain and filter options for each report.
Step 4 — Run the mapping workshop. Classify every item as met by standard, met by a filtered view, or genuinely custom.
Step 5 — Challenge everything remaining. Each surviving item must fail on grain, data availability or mandated external layout. Familiarity is not a failure condition.
Step 6 — Specify what survives. Question, consumer, grain, filters, frequency, delivery format. A specification missing grain or frequency cannot be estimated.
Step 7 — Write it into the statement of work. Catalogue appendix, included count, definition of one report, process for additions.
How Peakflo Approaches Reporting Requirements
Peakflo ships a standard reporting set across accounts payable and travel and expense, and maps customer requirements against it during scoping rather than during build.
| Pain point covered in this article | Peakflo approach | What changes |
|---|---|---|
| Reporting specified last, in spreadsheet vocabulary | Requirements restated as questions during scoping | Duplication surfaces before it reaches a build estimate |
| Standard catalogue never reviewed by the customer | Catalogue shared and mapped item by item pre-signature | Customers see what they already have before requesting builds |
| Same view requested separately by several teams | Consolidation into one report with saved filters | List length falls without losing any information need |
| Entity or department splits counted as separate reports | Entity handled as a dimension on a single report | Multi-entity groups stop multiplying their report count |
| No shared definition of what counts as one report | Definition agreed and recorded before work starts | Dashboard and multi-view disputes do not arise |
| New needs emerging mid-implementation | Defined process for raising, estimating and agreeing additions | Emerging requirements are handled without renegotiation |
Reporting draws on the same data as the wider finance automation platform, with source data flowing through Peakflo’s ERP integrations. Explore the product tour or request a demo.
Our Verdict: Map Before You Build, and Define a Report Before You Count Them
Reporting scope disputes are almost never caused by bad faith on either side. They are caused by two parties counting different things, having never agreed what a report is, and discovering the discrepancy at the worst possible moment — in build phase, with a go-live date fixed.
The remedy costs about a day. Restate the requirements as questions, put the standard catalogue on the table, classify each item three ways, and write the definitions into the statement of work. Teams that do this typically find that most of what they asked for already exists, that several requests were the same request, and that the genuine custom list is short enough to build well rather than quickly. Broader implementation guidance is available from Deloitte’s finance transformation research and PwC’s finance function insights.
Best for:
- Organisations entering scoping for an AP, expense or procure-to-pay implementation
- Multi-entity groups whose report counts inflate through entity splits
- Finance teams that have collected requirements from several departments independently
- Projects where reporting is currently a single line in the requirements document
- Programmes that have already hit a reporting scope disagreement and need to reset
Not recommended if:
- Your implementation is genuinely small with one or two reporting consumers
- Reporting will be handled entirely in an external business intelligence tool fed by exports
- The platform under consideration ships no standard reports, in which case everything is custom by definition
- Requirements cannot be consolidated because no single finance owner can be appointed
Conclusion
The number of custom reports a finance automation project needs is almost always smaller than the number it asks for, and the gap is not caused by anyone being unreasonable. It is caused by requirements being written as descriptions of the artefacts a team already produces, at the one moment in the project when nobody has yet looked at what the new platform provides.
Restating requirements as questions is a small discipline with a disproportionate effect. It collapses duplicates, exposes filters masquerading as reports, and leaves a short list of genuine gaps that deserve a proper specification. Do that before signature, agree what counts as one report, and reporting stops being the workstream that surprises everyone in build phase.
Frequently Asked Questions
What is the difference between a standard report and a custom report?
A standard report ships with the platform, is maintained by the vendor and is upgraded automatically. A custom report is built to a specific customer specification, is maintained as a distinct artefact and must be revalidated whenever the underlying data model changes.
Why do reporting requirements get underestimated in finance automation projects?
Because reporting is specified last and in the customer’s existing vocabulary. Requirements are written as descriptions of current spreadsheets rather than as questions to be answered, so nobody discovers until build phase how many are genuinely new.
How many custom reports does a typical finance automation project need?
After proper mapping, most projects need far fewer than initially requested. A list of nine or ten requirements commonly reduces to two or three genuine custom builds once standard templates and filtered views are applied.
When should reporting requirements be gathered?
During scoping, before the statement of work is signed, and mapped against the vendor’s standard report catalogue at that point. Deferring the mapping to build phase is what turns reporting into a commercial dispute mid-project.
How do you map a reporting requirement to a standard report?
Restate the requirement as the question it answers and the decision it drives, then check whether a standard report answers that question with filters, grouping or column selection applied. Match on information need, not on layout.
What makes a reporting requirement genuinely need a custom build?
A custom build is justified when the report needs a grain the standard set does not expose, joins data the platform does not hold, or must match an externally mandated layout such as a regulatory return or audit template.
Is matching an existing spreadsheet layout a good reason for a custom report?
Usually not. Layout familiarity is a change management concern rather than an information requirement, and building custom reports to replicate legacy formatting preserves the constraints of the system being replaced.
Who should own the reporting requirement list?
A single named finance owner should consolidate and deduplicate all requests before they reach the vendor. Collecting requirements directly from every team produces overlapping variants of the same underlying report.
What should a report specification contain?
The question it answers, the decision it drives, its consumer, its grain, its filters, its refresh frequency and its delivery format. A specification without a stated grain and frequency cannot be estimated reliably.
How should reporting be written into a statement of work?
Name the standard catalogue as an appendix, state the number of custom reports included, define what counts as one report, and set the process and timing for anything beyond that allowance.
Do dashboards count as custom reports?
It depends on the definition agreed in the contract, which is exactly why it must be defined. A dashboard combining several views may be one deliverable or several, and leaving this ambiguous is a common source of scope disagreement.
What happens if reporting is left out of scope entirely?
The project delivers working transactional automation that finance cannot report on, and adoption stalls because users return to extracting data manually to rebuild the views they had before.