The finance manager walks into the office with the third version of the monthly report. The boss glances at it twice and says, “This isn’t what I wanted.” The engineer feels wronged: every field was built cell by cell from the Excel file finance handed over. Finance feels wronged too: every single number reconciles. None of the three did anything wrong. But this report has been in revision for two months, money and time keep burning, and the boss still can’t see what he wants to see.
I’m Johnny Yang, founder of Brightstream Technology. In seven years of running the company, I’ve led the team through 252+ system projects across 32+ industries. On almost every one, the first wave of change requests after go-live was about reports. And most of the back-and-forth was decided the moment the requirement was written.
Reports keep getting reworked mostly not because the people building them don’t know how. It’s because the requirement described what the report should look like, not what it’s for. A report requirement needs four things spelled out first: who this report helps make what decision, how often it gets looked at, how each number is defined, and which action on the floor produces that number. Layout comes last. You also need to separate three kinds of changes. Changing presentation is cheapest. Changing a definition requires finance and sales to agree first. Asking for data the system doesn’t have at all is the most expensive, because that isn’t changing a report, it’s changing a process. Figure out which one you’re asking for, and the report stops getting rebuilt.
Not knowing what you want until you see the report is normal
Start from the boss’s side. Nobody can imagine a report out of thin air. Seeing the first version and only then realizing what’s missing is human nature. The company keeps changing too. Last year you cared about revenue, this year about gross margin, next year maybe accounts receivable. Reports are supposed to change with it.
So “the report will change” isn’t the problem. I’ve seen plenty of owners so afraid of endless revisions that they ask for nothing at all. Three years after go-live, the management meeting still runs on Excel that finance assembles by hand. That’s even more wasteful.
What actually burns money is every change going back to square one. Version one goes to the boss, and the boss says it’s wrong. Version two rearranges things, and it’s still wrong. Version three adds ten columns, and the boss says it’s too cluttered. Not one of those three revisions dealt with the real problem, because from start to finish nobody wrote down what this report is actually supposed to answer. The builder can only guess. Guess wrong, start over.
Constant report changes are really three different problems
When the boss says “this report needs a tweak,” it sounds like one thing. Behind it may be three completely different jobs, with very different costs in money and time.
Changing presentation: columns, order, totals, charts
Add a subtotal column, group dates by week, swap a table for a bar chart, make it readable on a phone. The data is all there and the definitions haven’t changed. It’s just laid out differently. This is the cheapest kind, usually handled within a few days.
At Brightstream, during the maintenance period, adjustments to UI/UX, fields, and report presentation within the written feature list aren’t billed separately, because that’s part of “keeping the same thing running well.”
Changing definitions: same word, everyone calculates it differently
“How much revenue did we do last month?” Sales means order value. Finance means invoiced amount. The warehouse is thinking of shipped value. All three numbers are right, and none of them match. Gross margin is the same. Is cost the standard cost, the latest purchase price, or the weighted average? Do returns get deducted in the month of the return, or back in the month of the original shipment?
These changes aren’t necessarily hard on the engineering side. What’s hard is that the company has to decide internally first. Without a decided definition, the engineer builds version A and sales is unhappy, then switches to version B and finance is unhappy. And it goes back and forth like that.
Changing the data source: the number you want isn’t in the system
The boss wants to see “gross margin brought in by each salesperson,” but orders don’t record which salesperson took them. He wants “actual labor hours per work order,” but the floor doesn’t report time at all. He wants “days from inquiry to closed deal,” but inquiries all happen in LINE and never enter the system.
This is no longer a report problem. To get that number, someone on the floor has to record one more piece of data at some step. That may mean changing forms, changing processes, training staff, and then waiting for data to accumulate before anything shows up. It’s the most expensive of the three, and the one most often mistaken for “just a quick report change.”
| Change type | Common examples | What it touches | Time | Who’s involved |
|---|---|---|---|---|
| Presentation | Add subtotals, change charts, change sort order | Only the report itself | Usually a few days | Requester + engineer |
| Definition | Revenue by order or by invoice, which cost basis for gross margin | The report’s calculation rules | Depends on how fast you decide internally | Finance manager makes the call |
| Data source | Gross margin by salesperson, labor hours by work order | Forms, processes, staff habits | Weeks or more, plus time for data to accumulate | Owner, floor managers, engineer |
Next time the boss says “tweak this report,” spend one minute figuring out which kind it is. Presentation: just request it. Definition: hold an internal meeting first. Data source: treat it as a new requirement and evaluate whether it’s worth it.
Before writing a report requirement, answer these five questions
Whether a vendor builds it, internal IT builds it, or you pull it yourself with a tool, write these five answers down clearly and the first version will be close to what you want.
First: who does this report help make what decision? One report, one decision. A “monthly gross margin by customer” report helps the boss decide which customers need a price increase and which to take less work from. A “weekly AR aging” report helps finance decide whom to chase first this week. If a report can’t name the decision it supports, it’s probably just nice to look at.
Second: how often, and where, does it get looked at? A glance on a phone every morning and a monthly projection in the conference room are two completely different designs. The first must be short, fast, and show anomalies at a glance. The second can be detailed, but needs drill-down.
Third: how is each number defined? Write each number’s calculation as one sentence, for example “Revenue = invoices issued in the month, excluding tax, minus allowances in the month.” One person signs off on that sentence, usually the finance manager, and every report after that calculates by it.
Fourth: which action on the floor produces this number? Gross margin needs cost, and cost comes from purchase receipts. Sales by rep needs a salesperson field, and that field comes from the moment the order is taken. Trace it back once and you’ll know immediately whether this report is a presentation change or a data source change.
Fifth: what happens when there’s an anomaly? Below what gross margin does it turn red? Once it’s red, who handles it? If everyone looks at an off number and just says “huh,” the report is missing its last piece.
Put these five answers on one requirement sheet and it looks roughly like this:
| Field | Example: monthly gross margin by customer |
|---|---|
| Audience | Owner, sales manager |
| Decision it supports | Which customers get price or payment-term changes next quarter |
| Frequency and venue | Before the 5th of each month, projected in the management meeting |
| Definitions | Revenue = invoiced amount excluding tax; cost = weighted average cost at time of shipment |
| Data sources | Sales slips, purchase receipts, customer master file |
| Anomaly threshold | Flag red when a customer’s gross margin falls below half the company average |
| Action after review | Sales manager proposes how to handle that customer within one week of the meeting |
Then add one more thing: an answer you’ve calculated by hand. Take last month’s data and have finance calculate two or three customers’ numbers by hand, using the definitions you just wrote. When the report is done, the first thing you do is compare the system’s numbers against the hand-calculated ones. If they match, the definitions and data sources are fine. If they don’t, you find the gap before go-live, not when the boss stumps you on the spot in the management meeting.
That hand-calculated answer is also your acceptance criteria. A lot of report disputes come down to “I feel it’s wrong, but I can’t say where.” With numbers calculated in advance, right or wrong is no longer a feeling. It’s something you can check cell by cell. The engineer will thank you too, because he finally knows what “done right” looks like.
For how to actually calculate gross margin by customer, I covered the method in Which customer is actually losing you money. Read that first to settle your definitions, then write the report requirement.
Why “just pull every field” wastes the most money
Plenty of owners, burned by revisions, say: “Then just put all the data in and I’ll filter it myself.” Forty columns in one report, on the theory that it’ll never need changing again.
It usually goes the other way. The more columns, the more each one needs a definition and needs to reconcile, so maintenance costs climb. The screen fills with numbers, and the three that matter get buried. The data volume grows, and the report runs slower and slower. In the end the boss still has finance put together a separate “short version.” You’ve built it twice.
My advice is to split reports by purpose. For exploration, give people with access a raw detail export and let finance or analysts dig through it in Excel. For decisions, use a fixed format, fixed definitions, and only three to five numbers, and look at the same report in every meeting. When exploration turns up a number worth watching every day, promote it to a decision report. You’ll end up with fewer reports, but every one of them gets looked at.
If what you actually want is a screen that tells you how the company is doing every time you open it, that’s a dashboard design question. I broke down what belongs on it and what doesn’t in What owners need isn’t an ERP, it’s a business dashboard they can read.
Once the requirement is written, how do you keep changes from piling up?
No matter how well the requirement is written, you’ll still want changes after go-live. The difference is whether the changes follow rules.
Before changing anything, write one sentence on why. Not “I want to add a column,” but “last month two customers had negative gross margin and the report didn’t show why, so we need to add return amounts.” Changes with a reason you can write down are usually right. The ones you can’t explain are mostly whims.
Batch each month’s changes. If everyone fires one off whenever it occurs to them, the engineer keeps getting interrupted and testing never gets done properly. Collect them once a month, prioritize, then change and verify them together.
Log definition changes. Once revenue switches from “order taken” to “invoiced,” old and new reports can’t be compared directly. Write down what day it changed and what changed. Otherwise, six months later, someone compares old and new numbers and it’s another argument.
I covered the change rules for requirements that keep shifting during development in What to do when requirements keep changing mid-build. Report changes follow the same logic.
How do you tell if a report is worth keeping?
Building a report doesn’t mean it’s useful. Three months after go-live, run every report through three questions:
- Has anyone opened it in the past three months? Many systems log when reports are opened. If yours doesn’t, ask around.
- Was there a single meeting where a decision was made because of this report? If nobody can name one, it’s “nice to look at, but useless.”
- If it were switched off tomorrow, who would be the first to ask about it? If nobody would ask, switch it off.
Clearing out reports nobody reads doesn’t just save maintenance. It reminds everyone that reports exist to make decisions, not to prove how impressive the system is. For which numbers an owner should actually watch after go-live, see ERP three months after go-live: 8 numbers the owner should check. Once your fixed reports are stable, the next step is having them delivered to you automatically on a schedule. How to do that is in Weekly report automation.
FAQ
How much does a custom-built report cost?
First figure out which kind of change it is. Presentation changes are usually small jobs, and if they fall within maintenance scope, many vendors won’t bill separately. Definition changes mostly cost internal meeting time. Adding a data source amounts to changing a process and should be evaluated as a new requirement. Classify first, then talk price, so you don’t end up buying a process overhaul at the price of a report.
Should a vendor build the report, or should we pull it ourselves with a BI tool?
Decision reports that are fixed, viewed every time, and need unified definitions should be built into the system, so everyone sees the same number. One-off analyses and questions you look up when they occur to you are faster with an export plus Excel or a BI tool. Having both is normal. What matters is that each decision report has only one version.
The system report doesn’t match the accounting books. Is the system wrong?
Usually the system isn’t wrong. The definitions are different. The most common causes are different revenue recognition timing, tax-inclusive versus tax-exclusive amounts, and returns and allowances deducted in different months. Write each side’s calculation as one sentence and put them side by side. You’ll usually find the gap in ten minutes. Then decide which one is authoritative.
Should the owner write the report requirement, or finance?
The owner states what decision it supports. Finance signs off on how the numbers are defined. Floor managers confirm where the data comes from. Each of the three owns one part, and only then is the requirement sheet complete. When only one of them writes it, a part is usually missing, and it gets patched in at version two and version three.
Specify what the report is for, not what it looks like
In the end, reports keep changing because the requirement handed over a picture instead of a decision to be made. Write down first who this report helps decide what, how each number is calculated, and which action the data comes from, and the first version will be close to what you want. When you change it later, you’ll know whether you’re changing presentation, a definition, or a process.
If you have a report that’s been through several versions and still isn’t right, and you’re not sure which layer the problem is stuck at, bring that report to a free 30-minute diagnostic with me. We’ll look at what it’s actually missing.
