The meeting every retailer has
Someone presents a number. Someone else has a different number. Twenty minutes go on establishing whose is right, and the actual decision is deferred.
The systems are not broken. They are answering slightly different questions and presenting the answers as though they were the same one.
1. One product, four definitions
A single item is legitimately all of these:
- A SKU in the EPOS, created by whoever set up the till file.
- A product in the storefront, with a variant structure invented by whoever built the site.
- A line in the ERP, keyed to a supplier code.
- A pick unit at the fulfilment partner, defined by how it ships.
Each definition suits its own system. The problem is that no system holds the definition connecting them, so the join is performed by a person, in a spreadsheet, monthly.
2. Reconciliation is a treadmill
The instinctive answer is a reporting layer that pulls from everything and resolves differences. It works briefly. Then a supplier changes a code, a bundle is introduced, a variant is split, and the mapping rots.
It never ends because reconciliation happens after the data is created. The sources keep generating divergence at the same rate; you are cleaning up behind a process rather than changing it.
Worse, reconciled data is confidently wrong. It produces a number with no visible caveats, and people buy stock on it.
3. Fix collection instead
The durable version:
- One authoritative product definition, in one system, referenced rather than redefined by the others.
- Creation in one place. If a line can be created in three systems, you have three catalogues regardless of the architecture diagram.
- Meaningless identifiers. Codes carrying supplier, season or category information get restructured when the business does, and every historic record becomes wrong.
- Validation at entry, where a person can still fix it, not in a report three weeks later that nobody owns.
4. The entities that actually need this
Not everything needs to be mastered. Three things cross system boundaries and cause almost all the pain:
Product, including the variant hierarchy and the relationship between a sellable item and a stocked item — these are frequently not the same, and bundles are where most reporting breaks.
Customer, because a shopper who buys in store, returns online and emails support is three records in most estates. Service quality, loyalty and lifetime value are all meaningless until this is resolved.
Stock position, which is less a fact than a set of qualified statements: on hand, allocated, in transit, reserved, damaged. Most “the website sold something we did not have” incidents are a definitional problem rather than a timing one.
5. Build the seams, not the replacement
Retail technology decisions gravitate towards the big replacement, which takes eighteen months while trade continues and the business changes twice.
The more productive question is which systems you are keeping for five years. Usually several are genuinely fine. Naming them converts an open-ended programme into a bounded one, and changes what you build: adapters and a clean contract rather than a migration.
Where systems meet, own something:
- A versioned contract, so a supplier’s change is absorbed in one place rather than felt in four.
- An authoritative record for product, customer and order.
- Observability at the joins. Most retail incidents are integration failures found by customers, because nothing was watching.
Do that and replacing any single system later becomes a normal project.
6. Returns: the data you already have and do not use
Returns are managed as a warehouse cost. Most of the rate was decided earlier, by information that was wrong or missing on the product page.
The reason is exactly the pattern above: return reason is captured in the returns portal, which belongs to operations, and never reaches the product record, which belongs to trading. So the buyer who could fix the size guide never learns that this line returns at three times the category average, always for the same reason.
Connect four things and the interventions become obvious:
- Return reason and rate attached to the product and variant, not the order.
- Time-to-return — same day means the page misled them; three weeks means they never wanted it.
- Return rate visible at reorder, when the decision is made.
- Margin after returns, because some lines are only unprofitable once returns are counted, and the two figures usually sit in different budgets.
7. Reporting last
Dashboards built on unreconciled data give confident answers that are quietly wrong, which is worse than no dashboard. Once the entities hold still, ordinary questions become answerable — what is selling, at what margin, in which channel, and what came back — and they stay answerable, which is the part reconciliation never delivers.
A sequence that works
- Pick one entity, usually product. Establish where it will be authoritative.
- Stop creation elsewhere. This is organisational, not technical, and it is the step most likely to be skipped.
- Build the contract other systems read, and monitor it.
- Backfill history deliberately, accepting that some of it cannot be recovered and marking it as such rather than guessing.
- Then report, and expect the numbers to disagree with the old ones — which is the point, and needs saying out loud before anyone sees them.
The test
Pick one product. Ask each system what it is, what it costs and how many exist. Then ask which of those answers people are already making decisions with.
If nobody can say which is authoritative, reporting is not the project.
If your retail numbers disagree with each other, get in touch, or read about our retail work.