The challenge
Store tills, the web storefront and the wholesale system each reported different revenue for the same week. Finance reconciled by hand in spreadsheets, so the monthly board pack was always three weeks stale and nobody fully trusted it.
Our approach
We landed all three sources into a warehouse with incremental ELT, modelled the business definitions once in dbt so “revenue” meant one thing everywhere, and added tests that fail the pipeline when row counts or margins drift outside expected bounds. Dashboards were rebuilt on the modelled layer rather than on raw extracts.
The outcome
Reporting moved from a three-week manual close to a next-morning refresh, and the definitions behind every number are now readable in version control rather than living in one analyst’s spreadsheet.
Why this approach
The retailer’s problem was not missing data — it was three systems each telling a different truth. So the work started with definitions, not dashboards: “revenue” was modelled once, in version control, where finance and engineering could both read it. Every dashboard built on that layer inherits the same answer, which is what actually ends the weekly argument about whose export is right.
Real-time was considered and rejected. The decisions this platform serves are daily and weekly ones, and streaming infrastructure would have added cost and fragility for a freshness nobody needed. Batch, tested and monitored, was the honest fit — with pipeline tests that fail loudly when a source drifts, because trust in numbers is easier to keep than to win back.
If you are facing something similar
If your board pack takes weeks to assemble and still gets challenged in the meeting, the fix is rarely another BI tool — it is a modelled layer both sides trust. Our data engineering service starts with one end-to-end slice so you see a working answer in weeks, and the cost estimator gives an indicative range for that first phase.