Dimensional P&L
By department, location, entity, project, service line, or customer cohort — the request that most often triggers an ERP search and most often does not require one.
Services
Most reporting problems are not visualisation problems. The chart is fine. The argument is about whether the number is right, which definition of revenue it used, and why it does not match the close — and no dashboard tool answers any of that.
Tell us the question you cannot answer today. We will show you what it takes.
The situation
Ordered by how often companies ask for them and cannot produce them.
By department, location, entity, project, service line, or customer cohort — the request that most often triggers an ERP search and most often does not require one.
By product, channel, engagement, or client, after loaded labour, landed cost, fees, returns, and write-offs. Almost always different from the assumed figure.
Thirteen-week cash, DSO and DPO by customer and vendor, and the collection pattern behind them rather than a single average.
The recurring pack, produced automatically from reconciled data with commentary drafted, rather than rebuilt monthly from four exports.
Budget to actual, bookings to revenue, period to period — decomposed into contributing parts rather than reported as a delta with a note.
Every figure traceable to the records behind it. A report you cannot drill into is a report that gets questioned and cannot defend itself.
When two reports disagree, the cause is almost never arithmetic. It is that one includes intercompany and the other does not, or one uses booking date and the other invoice date, or one consolidates the dormant entity.
So every report we build carries its definitions with it: what is included, what is excluded, which date basis, which entities, how currency is translated. Written on the report, not in a document nobody opens. It is the single change that most reduces the time spent arguing about numbers.
A report built on an extract that does not tie to the ledger will eventually disagree with the close, and at that point it is discarded regardless of how useful it was.
Ours are built on data that reconciles to the trial balance nightly, so the report and the close cannot diverge silently. That constraint is why we do the integration work first and why we will decline to build reporting on a source we have not reconciled.
The first thing anybody does with an unexpected number is ask what is in it. A report that cannot answer that gets escalated to whoever built it, who then investigates manually, which is the exact work the report was meant to remove.
Every figure drills to the transactions behind it — through the aggregation, into the subledger, down to the document. That is a property of the data model rather than of the reporting tool, which is why it is hard to retrofit onto a warehouse extract.
Most companies have too many reports and too little reporting. Fifty dashboards, six of which are opened, and the important question answered in a spreadsheet anyway.
We usually recommend building fewer, making them drillable, and retiring the ones with no recent viewers. A report nobody opens is maintenance cost with no offsetting benefit, and every one of them dilutes trust in the ones that matter.
Where to start
Not from a report request. What decision does this inform, who makes it, and how often — which frequently changes what should be built.
Written, agreed by finance, attached to the report. This is where existing disagreements get resolved rather than inherited.
Tied to the trial balance, drillable to transactions, with the definitions displayed on the report itself.
Delivered where people already work, with usage tracked so unread reports get retired rather than maintained indefinitely.
Questions
We will show you what it takes to answer it in a way that survives being questioned.