Business metrics and reporting platform

The book holds about 900 properties and buys from 285 vendors. The numbers that describe the business sit in the ERP, in company card transactions, in fuel records and in month-end spreadsheets. Each source has its own timing and its own gaps. A figure moving month over month can mean the business changed, or it can mean a source stopped arriving, and the figure by itself does not separate those two. I specified a reporting surface where every metric carries its formula, its source, the vintage of the data behind it and its caveats, so a reader can tell which case they are looking at before they act on it.

I built a daily operations brief for leadership covering vendor scorecards, price anomaly flags, AP exceptions and AR aging. The reporting platform develops that work into pages a reader can investigate.

I defined the operating problem, specified the system, directed the build and reviewed the result. AI agents wrote most of the code under my review gates.

I specified the page subjects and metric definitions, including source dates, missing-data behavior and the thresholds a reader uses to investigate exceptions.

Fifteen pages in the September 7 deployment check. Sixteen layouts exist; fifteen are served and one is generated to a file only. By subject:

1. Overview, the headline figures with their vintages.
2. Money: revenue, margin, sold-work costs, receivables, card spending and a four-week ticket-revenue outlook, with the page’s stated limits.
3. Sales: pipeline, and contract survival by the year a contract started.
4. Operations: recorded field work and schedule history, time and payroll readiness, the four-week expectation, projected crew hours, and weeks that fall outside control limits.
5. Customers: the book of business and reachability gaps.
6. Fuel: current-period consumption and cost, fuel-type comparisons, reconciliation and truck economy. A combined metrics table and an explanation of variance accompany the outlook for the next three months.
7. Fuel by route.
8. Items and vendors: spend and exposure, catalog quality and vendor quality.
9. Data hygiene: 35 checks.
10. Spend and credit: the payment rails, top vendors over trailing twelve months, card transactions by month, a spend integrity check shown check by check, and possible duplicate payments shown pair by pair.
11. Forecasting: four series four weeks out, a model bench, how past projections actually scored, and season and trend per metric.
12. Paper invoices: bills and line items by month, who bills us most, the paper price beside the operator-entered price for diesel and regular, and every ingest verdict.
13. ERP audit: this week by domain, and findings run by run.
14. Estimating history: frozen, ending June 2026, aggregates only.
15. Data health: instruments, the watchdog strip, nightly card-pull completeness, and retrieval index gates.

One metric registry, in code. Every metric carries a formula, the source it reads, an owner, a granularity, the vintage of the data behind it, its caveats, a privacy flag, and, where one is set, a threshold with the authority who ruled it. Metrics marked private are withheld from published output.

Navigation built for answering a question. A “Find a business figure” search with a state filter runs over every metric that is not withheld, and each result links to that metric where it lives on its page. A “What needs a look” list orders exceptions ruled against a threshold first and figures that could not be computed second; metrics that were never graded are never judged. A metric with no value prints the words “no data” and the reason in the space the number would have occupied, so a blank never reads as a zero.

Evidence attached to every figure. A definition disclosure on each tile, an exact-value table beside every chart including projection ranges and missing points, and a methods disclosure at the page level. Printing expands the evidence and the definitions, then restores the reader’s state on screen.

The source record describes the wider components as follows. These rows are dated implementation records, not a new check of every running job:

A reader starts with a headline figure, opens its definition and checks the source date before following the supporting records. A spend question can lead through card charges, purchase orders, invoices and reconciliation exceptions. A duplicate-payment flag is a reason to investigate, not proof of the cause of an increase.

Coverage and data-health information qualify what the reader can conclude. Missing inputs produce a stated reason rather than a plausible zero. The monthly fuel workbook carries definitions with the exported values.

Every claim on this page is my own account of my own work.

Outcome not yet measured. No before-state was recorded, so there is no baseline to compare against, and the platform does not count its own use.

What I would measure, given a baseline and instrumentation:

• Time from a question being asked to an answer somebody will act on.
• Share of month-end figures that get revised after they are published.
• Share of flagged exceptions that turn out to be real when someone checks them.

None of those are running today.

If this resembles your problem, the first engagement on the consulting page is the workflow review: a paid review of the reporting you already run, and of where its figures disagree with each other.

Related work: ERP data checks, which is the hygiene page above as its own entry, and the account coverage and territory map, built for the same company off the same ERP mirror.