One number, one definition, one place it comes from.
Business reporting is less about charts than about agreement. A number is only useful once everybody accepts what it counts, it comes from one place rather than four, and the way it was produced can be repeated next month without anybody having to remember how. Most reporting problems are definition problems wearing a spreadsheet.
Personal reply from Andrew within one business day.
What is business reporting, really?
Business reporting is the practice of turning the records a business already keeps into a small number of figures that people agree on and act on.
The recognisable version of this problem is a workbook. It has been passed down through two or three people, it has a tab nobody opens, it contains at least one formula pointing at a cell that no longer exists, and exactly one person in the business understands it. Every month it is rebuilt from three exports, corrected by hand and sent out as a file. The trouble is not that the workbook is bad — it is often rather good. The trouble is that the business has a single source of truth for its numbers and it is a file on somebody’s desktop.
The first decision is what the number counts. Almost every reporting disagreement turns out to be definitional. Does sales this month mean orders taken, goods dispatched or invoices raised? Does it include freight, and does it include the credit note issued the following month against it? None of those is the correct answer and all of them are correct for some question. The failure is not choosing wrongly; it is having two figures in circulation, each computed correctly under a different definition, with nothing anywhere saying which is which. Writing the definition beside the number is a small act with an unreasonable return.
The second decision is where the number comes from. A figure assembled from several exports is as old as the oldest of them, and nothing on the page admits it. The rule worth holding is that each figure has one named source system, is queried from that system rather than from a copy of it, and carries the time it was read. Where a figure genuinely has to combine two systems that is fine, but it needs the same treatment an integration gets: one owner per data type, and a reconciliation that confirms the two still agree.
The third decision is who acts on it, and how often. The cadence of a report should follow the cadence of the decision it supports, and most reports fail that test in the direction of being too frequent. A weekly report nobody can act on weekly trains its audience to skim, and a report people skim is worse than no report at all, because its existence is taken as evidence that somebody is watching. The useful question to ask of any proposed report is which decision changes as a result of it. If the answer does not arrive quickly, the figure is probably a tile on something somebody already has open, or nothing.
Where a report is being assembled by hand every month, the delivery half of the problem is a scheduling problem and belongs with workflow and process automation. Where the numbers come from two systems that disagree, the reporting work cannot honestly start until the question on systems and API integration is settled. Inside Accredo Saturn, custom reports and scheduled extracts are largely a matter of MaxBasic scripting and the OData interface — but the three decisions above are the whole of the work either way, which is why Saturn reporting is covered on this page rather than on one of its own.
Where does a number come from?
Five steps between a record being created and a figure being acted on. A wrong number is almost never an arithmetic error — it entered at one of these, and each one fails in its own way.
-
01
The record is created
Somebody enters an order, closes a job, posts an invoice. Whatever is captured here is the ceiling on what can ever be reported.
breaks here if: the field the report needs was optional and half of it is blank -
02
The definition is agreed
What the figure counts, in one sentence, recorded where the figure appears rather than in somebody’s memory.
breaks here if: two departments each hold a correct number and neither knows the other exists -
03
The query is written
One statement against the owning system, returning the rows the definition describes and no others.
breaks here if: a filter is convenient rather than correct and quietly drops a category -
04
It runs, and it arrives
Automatically, at a time chosen to sit after the events it counts, landing in whatever form suits the decision — a file, an email, a tile on a screen somebody already has open.
breaks here if: it runs before the period closes, or lands somewhere nobody looks -
05
It is checked
Compared against the report it replaces, line by line, until the two agree or the difference has been traced and accepted.
breaks here if: the check is skipped because the new figure looks about right
A query is a written-down definition, and that is its great virtue. Unlike a workbook assembled by hand, it does the same thing next month whether or not anybody remembers why it does it. It is also unforgiving in a particular way: a filter that was convenient rather than correct — excluding a status code that looked like noise, or restricting to a date field that turns out to be the wrong one of three — will keep excluding it, silently, every month, with no visible symptom and no error to investigate.
Step four is where the most embarrassing failures live, and they are almost always timing. A report that runs at eight in the morning counts a day that has not finished. A month-end report that runs on the first counts a month still receiving adjustments. Neither is bad arithmetic, and both produce figures that disagree with the ones produced a week later — which is the specific failure that destroys confidence in a reporting system. Not being wrong. Being inconsistent with itself, in a way nobody can account for. The same step carries a quieter failure alongside the timing one: a report that arrives somewhere nobody has agreed to look becomes decorative within about a month, and its continued arrival is then mistaken for evidence that somebody is watching.
Step five is not optional and it is the step that gets dropped. A replacement report is not correct because it is new, and it is not correct because it looks about right. It is correct when it has been run against the same period as the thing it replaces and the two either match or the difference has been traced to a definition change somebody consciously agreed to. That comparison is slow and boring and it is the entire basis on which anybody should be asked to trust the new number. It is also the last moment at which the old report can still be used as evidence — once it is switched off, the comparison is no longer available at any price.
How should a report actually be delivered?
Four routes. The second is the one worth exhausting first and the fourth is the one most often bought too early.
| The spreadsheet you have | Reports built into the system | A scheduled query | A dashboard or BI tool | |
|---|---|---|---|---|
| What it is | A workbook rebuilt from exports each period, corrected by hand and sent out. | The report writer, saved filters and scheduled outputs already inside the products you pay for. | One statement written against the owning system, run automatically and delivered as a file or an email. | A tool that connects to the data and presents it live, with filtering and drill-through. Power BI and its equivalents. |
| Where it wins | One-off questions, exploratory work, and anything that will be asked once and never again. | Almost always worth exhausting first. It is already paid for and it reads live data by definition. | Recurring figures, awkward definitions, and anything that has to combine two systems. | Where several people need to ask their own variations of the same question, often, without waiting. |
| What it costs | Nothing to build. A recurring morning, and one person who understands it. | Time to learn what the product already does. No licence and no new supplier. | A modest build, then very little. Somewhere to run, and credentials that get renewed. | Per-user licensing that grows with the audience, plus a model somebody has to maintain. |
| How it fails | Silently and permanently. A broken formula produces a number, not an error. | By being outgrown, when the report writer cannot express the definition you actually need. | At the edges: a change upstream, or a filter that was subtly wrong from the first run. | By proliferating. Twelve tiles nobody agreed on, two of which disagree with each other. |
| What it needs from you | Nothing new, and a plan for the week its author is away. | Willingness to accept the product’s shape rather than the workbook’s. | An agreed definition, in writing, and a named recipient for the output. | A short list of questions it must answer, and the discipline to refuse the rest. |
The second column is worth exhausting before anything is built, for the same reason it is worth exhausting on the automation page: it is already paid for, it reads live data, and because it is nobody’s project it never gets checked. A surprising number of monthly workbooks exist because a saved report inside the source system was one filter away from doing the job and nobody thought to look.
The fourth column is the one most often bought too early. A dashboard is an excellent way to let several people ask their own version of a question, and a poor way to answer a question nobody has agreed on yet. Where the definitions are unsettled a business intelligence tool does not settle them — it renders the disagreement in colour, at a per-user licence fee, and adds a second place where business logic lives. The order that avoids waste is to settle the definition, produce the figure reliably by the cheapest means that works, and let the demand for a dashboard prove itself before it is licensed.
The third column is the quiet workhorse of this list. A scheduled query is dull, portable and cheap to keep running, and because it is written down it can be read by somebody other than its author — which is the property the first column most conspicuously lacks, and the reason a business that loses one person can lose a report.
How does a reporting project run?
Three phases. The first produces a page of sentences and no software, and it is where most of the value is.
Agree what the number counts
- The figures that actually get used
- One written definition for each
- The owning system for each figure
- The decision each report supports
Two of the figures on the list usually turn out to be the same figure under different names, and one of them usually turns out to support no decision at all. Finding that out costs a conversation. Finding it out after three reports have been built costs considerably more than a conversation.
Write the query, not the spreadsheet
- One statement against the owning system
- Timing chosen to sit after the period
- Output shaped to the decision it serves
- The definition travelling with the figure
Carrying the definition next to the number costs one line and permanently removes the most common reporting argument. The timing choice deserves as much attention as the query itself, because a correct figure produced at the wrong moment is indistinguishable from an incorrect one.
Match it against what it replaces
- The same period, produced both ways
- Differences traced, not rounded away
- A named recipient for every output
- The old report retired deliberately
The old report is retired on a date somebody chooses, not by being quietly forgotten. Two versions of the same figure circulating indefinitely is the exact state this work exists to end, and leaving the previous one running out of politeness is the easiest way to arrive straight back at it.
- Figures with a written definitionexpected: all of them
- Reports produced without a personcounted
- Differences against the old reporttraced, not rounded
- Reports nobody opened last quarterworth deleting
The last measure is the one businesses are least keen to run, and the one that most reliably shortens a reporting list. A report nobody opens is not free: it occupies a schedule, it implies somebody is watching, and it will eventually be quoted by a person who assumed it was being maintained. No figures appear on this page, because the only meaningful ones are measured against your own current reporting, before anything about it is changed.
Not sure whether you need a new report or a settled definition? That is exactly what the free audit is for.
Book a free process auditWhen is a new report the wrong answer?
More often than a reporting brief assumes. Four situations cover most of them, and three of the four are cheaper to find now than after a build.
The definition is not settled. If two people in the business would answer what counts as a sale differently, building a report picks one of them silently and hands the choice the authority of software. The work to do first is a conversation and a sentence, not a query. This is the single most common reason a technically correct report ends up mistrusted.
The data to support it was never captured. A report can only count what somebody recorded. If the field was optional, or the category was introduced last year, or the distinction being asked about lives in a free-text note, no amount of query writing will produce it. The honest answer is that the capture has to change first and the report becomes useful a few months later — which is a considerably better answer than a chart with a plausible shape and nothing behind it.
No decision changes. Some reports are requested because a figure feels as though it ought to be watched, not because anything would be done differently at any value it might take. Those are worth naming as such. They can still be produced cheaply, as a tile on something somebody already has open, but they should not be a project and they should not be a scheduled email — because a scheduled email nobody acts on teaches its audience to ignore scheduled emails, including the one that matters.
The real problem is upstream. Where two systems disagree, a report showing both numbers side by side documents the problem rather than solving it. That is occasionally exactly what is wanted as a first step. But if the intention is to fix it, the work is an integration or a definitional agreement, and building a reconciliation report instead is a way of making the disagreement comfortable enough to live with indefinitely.
Questions about data and reporting.
What is the difference between a report and a dashboard?
A report answers a question agreed in advance, on a cadence, for a known audience. A dashboard lets people ask their own variations of a question whenever they like. The distinction matters because the two fail differently: a report fails by being ignored, and a dashboard fails by multiplying until two tiles disagree and nobody can say which is right. As a working rule, a figure earns a report when a specific decision depends on it at a specific time, and it earns a place on a dashboard when several people need to interrogate it at moments nobody can predict in advance.
Why do two reports of the same thing give different numbers?
Nearly always because they are answering slightly different questions and neither of them says so. The usual culprits are the date field — order date, dispatch date or invoice date — the treatment of credits and cancellations, whether freight and tax are included, and whether the two ran at different moments against a period that was still moving. The instinct is to hunt for the error, but usually neither figure is wrong. The fix is to write the definition beside each one and then decide which of the two questions the business actually wanted answered, which is a decision rather than a calculation.
Do we need Power BI or a similar tool?
It depends far more on the audience than on the data. Where several people need to interrogate the same figures from different angles, repeatedly, a business intelligence tool earns its licences quickly and is worth having. Where the requirement is a handful of numbers arriving reliably on a schedule, it adds a per-user cost, a model to maintain and a second place where business logic lives — and none of that makes the underlying definitions any more agreed than they were before. The sequence that avoids waste is to settle the definitions, produce the figures reliably by the cheapest means that works, and let the demand for a dashboard prove itself before anybody licenses one.
Can you report across two systems that do not talk to each other?
Yes, and it is worth being clear about what that does and does not fix. A report can read from both and present a combined figure, which is often genuinely useful and is sometimes the fastest way to make a divergence visible to people who did not believe it existed. What it does not do is make the two systems agree: the combined figure inherits both sets of inconsistencies and adds the question of which one to believe when they differ. Where the numbers need to agree rather than merely appear together, the underlying work is described on the systems and API integration page, and the reporting sits on top of it once that is settled.
Can a report be trusted if the underlying data is messy?
Only if the mess is understood and stated, which is a much lower bar than fixing it and a much higher bar than ignoring it. Real business data has abandoned categories, records entered before a rule existed, and a period where somebody used a field for something else entirely. A report built over that can still be genuinely useful, provided the query says what it excludes and the figure carries a note about the discontinuity. What is not defensible is smoothing it away — dropping the awkward rows quietly, or starting the series at the point the data got tidy without mentioning that is what happened. A figure with a stated limitation is worth more than a clean one whose limitations are undocumented.