Skip to content

Three systems that never agreed on a Monday

Shopify, a third party warehouse and Xero, each correct on its own and none of them agreeing. One person spent every Monday finding out why.

Client
A direct to consumer skincare brand
Sector
Retail and e-commerce
Duration
9 weeks
Year
2026
Tallyhouse
Reconciliation screen comparing every order across Shopify, the third party warehouse and Xero side by side, with the one cell that disagrees highlighted on each row and the action needed beside it.
The same orders read from all three systems at once. Only the cell that disagrees is marked, which is the whole job the Monday reconciliation used to do by hand.

Monday reconciliation

Before
~7 hrs
Now
~20 min

Time to spot a stuck order

Before
~31 hrs
Now
Under 1 hr

Oversells per month

Before
40 to 60
Now
3 to 8

Returns in a shared inbox

Before
All of them
Now
None

The problem

The brand turned over about £9m a year with thirty staff and no developers. Orders arrived through Shopify and a marketplace channel, fulfilment ran through a third party warehouse, and the books were in Xero.

Every Monday one person spent the day reconciling the three. Stock figures disagreed, so the site oversold lines the warehouse had already run out of. Returns were tracked in a shared inbox, which meant they were tracked by whoever happened to read it.

Each of the three was answering a different question, and nobody was holding the three answers against each other.

What we found

The Monday job was described as reconciliation. What it was actually doing was finding orders that had stopped moving.

On an average week, thirty to forty orders were sitting between two systems with nobody responsible for them, and the average time before anyone noticed was over a day.

That number mattered more than the reconciliation itself, because a stuck order is a customer waiting and a refund coming.

How we got there

Nine weeks, with nothing replaced. The work was deciding, case by case, which of three systems to believe when they disagree, and those decisions were the client's to make.

One order, followed by hand

Before building anything we followed single orders from payment to the warehouse to the invoice, as cards on a wall, with the person who did the Monday job telling us where each one tended to stop. Every place a card could stop became a reason the system now gives: paid but not sent to the warehouse, sent but not shipped, shipped but not invoiced.

Who wins when they disagree

On stock it took one meeting. The warehouse is holding the boxes, so the warehouse wins. The first correction took a handful of lines off sale that the team was sure were in stock. The warehouse counted again and they were not there.

Returns, tested with a real parcel

Returns left the shared inbox last, because the customer team trusted the inbox. We ran test returns ourselves from request to refund, scanning the parcel in as the warehouse would, until the refund reached Xero and the stock came back with nothing typed. The team kept the inbox open for a month and then closed it themselves.

Reasons in their words

Our first reasons for a stuck order read like error messages. The person who had done the Monday job for years rewrote them the way they would say it to a colleague, and those are the ones on the screen now.

What we built

One view across Shopify, the warehouse and Xero

Orders traced from payment through the warehouse to the Xero invoice, so a break in the chain is visible where it happens rather than at the end of the week.

Stuck orders with the reason attached

Each one names what disagrees and what the two systems each say, which is enough for the person reading it to act without opening three tabs.

Stock corrected at the source

When the warehouse and Shopify disagree, the warehouse wins and Shopify is corrected to match, because the warehouse is the one holding the boxes.

Returns out of the inbox

A return moves through four stages with the value and the reason on it. Refunds post to Xero and take the stock back with them.

Tallyhouse
Returns board with four columns for requested, in transit, at the warehouse and refunded, each card showing the customer, the product, the value and the reason, with one flagged for sitting seven days.

Afterwards

Nothing was replaced. Shopify, the warehouse and Xero are all still in use, which is the answer to the question the project was really about.

The oversell figure will not reach zero. A warehouse count is a point in time and the site sells through the night, so a handful a month is the floor rather than a failure.

Built with

  • TypeScript
  • React
  • Next.js
  • PostgreSQL
  • Prisma
  • BullMQ job queue
  • Redis
  • Shopify Admin API
  • Xero Accounting API
  • Third party logistics EDI feed

More case studies

Is this your problem too?

If any of the above sounded familiar, describe your version of it. The first conversation is about whether software is the right answer at all.

From £10,000Most projects land between £15,000 and £55,000.