There is a particular kind of Monday morning meeting that commercial and finance leaders at mid-market companies know well. The prior week's trading results are discussed — in general terms, with caveats, with the caveat that the full picture won't be available until Wednesday or Thursday once the analyst has "pulled everything together." Decisions on promotional adjustments, pricing responses, or inventory reallocation are deferred accordingly.
This is not a technology problem. It is not a talent problem. It is an architecture problem — and it is one of the most consistent patterns we observe across mid-market organisations regardless of sector, geography, or technical sophistication.
The purpose of this piece is to explain precisely why it happens, what it costs, and what a system designed to eliminate it actually looks like in practice.
Why it takes four days
The four-day reporting cycle is almost never the result of laziness or incompetence. It is the predictable outcome of a data environment that was assembled incrementally rather than designed. Each individual decision that created it was rational in isolation. The cumulative result is a reporting process that is both slow and fragile.
The anatomy is consistent across organisations. Source systems — an ERP, a CRM, one or more retail partner portals, occasionally a 3PL or a DTC platform — each produce data on their own cadence, in their own format, with their own identifiers for products, customers, and transactions. None of these systems were designed to talk to each other.
In the absence of an integration layer, an analyst fills the gap. They log into each system, extract the relevant data, and bring it into a spreadsheet where the reconciliation begins. The first and most time-consuming task is usually identity resolution — matching a product in the ERP to the same product in the retail portal, which may use a different item number, a different description, or a different hierarchy. This mapping lives in a lookup table maintained by the analyst, updated manually, and understood by very few other people in the organisation.
"The mapping lives in a lookup table maintained by one analyst. When they are unavailable, the report is late. When they leave, the process breaks entirely."
Once the data is assembled and reconciled, the transformation work begins — calculating sell-through rates, gross-to-net adjustments, weekly comparisons, territory rollups. This logic lives in formula chains across multiple Excel tabs. It is not documented. It has accreted over years, with adjustments made each time the business added a channel, a brand, or a reporting requirement. The analyst who built it understands it. Their colleagues do not.
The result is a report that takes three to four days to produce, reflects data that is already several days stale, and is trusted conditionally — subject to the familiar qualification that "the numbers are directionally right but there may be some adjustments."
What this actually costs
The most visible cost is time — three to four analyst-days per week, every week. At a fully-loaded cost of a senior analyst, that is a meaningful figure annually for a process that produces no analytical value in itself. It is pure data plumbing, done manually.
The less visible cost is decision latency. A commercial team that receives last week's trading data on Thursday cannot act on it until the following week at the earliest. In practice, a promotional response to a competitor move, an inventory reallocation to address an emerging stockout, or a pricing adjustment in a specific channel — all of these decisions are delayed by the reporting cycle. The commercial opportunity cost of that latency is difficult to quantify precisely, but it is structural and it compounds over time.
There is also an organisational cost that is rarely discussed. When reporting is slow and conditional, commercial teams develop informal alternatives — personal relationships with retail account managers who provide early read data, ad-hoc requests to the analyst for specific figures, gut-feel judgments made in the absence of current numbers. These workarounds are rational responses to a broken system, but they produce inconsistent decisions and create accountability gaps that become visible only when something goes materially wrong.
- Weekly or monthly reports are produced by one or two individuals who own the process personally
- The same metric is quoted differently by Finance, Commercial, and Operations
- A new team member cannot produce the report without being trained by the person who built it
- Report distribution triggers a round of questions about specific line items that require manual follow-up
- Commercial decisions are routinely deferred pending "the full picture"
- The analyst who runs the reporting process is considered operationally irreplaceable
If four or more of the above are true, the problem is structural. Faster tools or additional headcount will not resolve it. The underlying architecture needs to change.
What a working system looks like
The goal is not to produce a faster version of the current process. It is to eliminate the manual process entirely and replace it with a system that produces accurate, current reporting automatically — available before the business day begins, requiring no analyst intervention to run.
This is a solved engineering problem. The components required are well-understood, the tooling is mature, and the implementation timeline for a mid-market organisation is typically measured in weeks rather than months. What makes it hard is not the technology — it is the upstream work of defining what the data should mean before writing a single line of code.
The integration layer
Every source system needs a reliable, automated extraction process. For cloud-based systems — a Salesforce CRM, a Shopify DTC platform, a NetSuite ERP — this is largely commodity work handled by tools like Fivetran or Airbyte. For systems with limited API access, custom extraction jobs are required but are rarely complex. The principle is simple: raw data from every source lands in a central warehouse — Snowflake, BigQuery, Databricks — on a defined schedule, without transformation, and without anyone pressing a button.
The raw layer is treated as immutable. It is the audit trail. Nothing is modified at ingestion. This matters because it makes the entire downstream system explainable — any output can be traced back to the source record that produced it.
Metric definitions before models
This is the step that most technology-first approaches skip, and it is the most important one. Before any transformation logic is written, the organisation needs to agree on what its metrics mean.
What is net revenue — is it gross sales less returns, or does it also exclude trade spend? What is sell-through rate — units sold as a percentage of units shipped, or units sold as a percentage of units available at retail? What counts as an active territory — one visit per month, two, or any contact in the trailing quarter? These questions do not have universally correct answers. They have organisational answers, and those answers need to be explicit, documented, and agreed before they are codified in a data model.
The tool of choice for this work is dbt — a transformation framework that treats metric definitions as code, keeps them under version control, and makes them testable. Every downstream report draws from the same defined metrics. When the definition needs to change, it changes in one place and propagates everywhere. The era of Finance and Commercial citing different revenue figures from the same period ends the day the metric definitions are codified.
"The era of Finance and Commercial citing different revenue figures from the same period ends the day the metric definitions are codified."
The reporting layer
With a governed mart layer in place, the reporting tool — Power BI, Tableau, Looker, or any comparable platform — connects to defined, reliable data rather than to raw exports or individual spreadsheets. Dashboards refresh on a schedule. The weekly trading report is available at 6am on Monday. Territory managers see their account performance on their phones without calling the analyst. The supply chain team receives automated alerts when inventory positions move outside acceptable parameters.
The analyst who previously spent three days producing the report now spends their time on analysis — asking questions of the data rather than assembling it. That is a material shift in the value the function delivers to the business.
A realistic assessment
None of the above is simple to execute. Identity resolution — establishing a shared product or customer identifier across systems that were never designed to share one — is consistently the hardest part of any data platform build, and it is frequently underestimated. The technical problem is tractable. The organisational problem — getting the relevant teams to agree on a canonical identifier and maintain it — requires more effort and more senior sponsorship than the engineering work it enables.
The other honest point is that data platforms require ongoing maintenance. Source systems change, new data sources are added, metric definitions evolve as the business evolves. A platform that is built and then left without operational ownership will degrade. The organisations that benefit most from this investment are those that treat the platform as infrastructure — something that is actively run, monitored, and developed — rather than as a project that is delivered and closed.
For organisations that are serious about getting this right, the investment required is material but not prohibitive. The return — decisions made on current data, commercial opportunities acted on in days rather than weeks, analyst time redirected from assembly to insight — is compounding and visible within the first quarter of operation.
Anstrom designs and builds data platforms for mid-market companies, then operates them on a monthly retainer. If the situation described in this piece is familiar, we are happy to have a direct conversation about it. Get in touch.