Case study — a premium homeware omni-channel retailer
Getting the systems to agree — and surfacing the ones that don't
Sales, payments and stock now flow between systems automatically, and daily reconciliations turn month-end cross-checking into a short exception list.
- Python
- REST APIs
- SQL
- scheduled workflows
The challenge
A premium homeware retailer we’ve worked with for years runs its business across systems that grew up independently: point of sale in the showrooms, an e-commerce storefront, order and inventory management, payment providers and the accounting system. Each was right about its own corner of the business — and no two of them fully agreed. Confirming that every sale, refund and settlement landed correctly in the books meant manual cross-checking every month, and discrepancies surfaced weeks after anyone could still explain them.
What we did
Building on years of work across the retailer’s data estate — warehouse, BI and feed monitoring — we connected the operational systems directly. Orders, payments and stock movements now flow between the storefront, point of sale, order management and accounting through automated integrations instead of re-keying and spreadsheet exports.
On top of the integrated flow we built automated reconciliations. Every transaction is matched across the systems it touches — order to payment to settlement to ledger — on a daily schedule. Matches pass silently; mismatches surface as an exception list with the underlying records attached, the day they happen.
The outcome
Month-end went from days of cross-checking to reviewing a short list of exceptions, each already traced to its source records. Discrepancies are caught while they’re still explainable — a settlement delay, a refund keyed in one system but not another — instead of being archaeology. Unmatched records stay visible rather than being absorbed into a total: the point isn’t that everything always matches, it’s that whatever doesn’t match is on a list the day it happens.
Synthetic example
No customer data. Systems, transaction and amount are fictional.
How to read this. Matching amount and date are not proof of correct posting; the destination attribute is separately tested.
Working in omni channel retail? Let’s talk.