Three Counts, None of Them Right: Why a Light Manufacturer's Stock Disagrees in Shopify, QuickBooks and the Warehouse.
Updated: 3 days ago
Ask a light manufacturer that sells online how many units of a product they have and you get three numbers. Shopify says one thing, because it is what the shop will sell. QuickBooks says another, because it is what the accountant values. The warehouse says a third, because someone counted the shelf on Tuesday. On a good day the three are close. On the day a customer orders something that turns out not to exist, they are not.
The usual reaction is to buy a sync. A connector that pushes the count from one system to another every fifteen minutes. It helps for a month and then the numbers drift again, sometimes faster, and this post is about why: the count is not a fact that can be synced. It is the result of six events, and no one of the three systems sees all six.
Six events move stock.
Here is what changes a stock quantity in a company that makes and sells things.
A receipt. Components or finished goods arrive from a supplier. The warehouse sees this. QuickBooks sees the bill, which is not the same thing and often not the same day. Shopify sees nothing.
A build. Components become a finished product. The warehouse sees this if there is a work order system; if not, nobody records it and finished goods appear on the shelf by magic while components vanish. QuickBooks sees it only if someone posts an assembly. Shopify sees nothing.
A sale. An order is placed. Shopify sees this first, and reserves or deducts the unit. The warehouse sees it when the order is picked. QuickBooks sees it when the invoice posts, which may be the same day or may be the end of the month.
A shipment. The unit leaves. The warehouse sees this. Shopify sees it when the fulfilment is marked. QuickBooks sees nothing new.
A return. The unit comes back, possibly saleable, possibly not. Shopify sees the refund. The warehouse sees the box, eventually. QuickBooks sees the credit. Whether the unit goes back into stock is a decision, and it is made in different places in different companies.
A count. Someone counts the shelf and it does not match. The warehouse is corrected. Nothing tells Shopify or QuickBooks, or the correction is typed into all three by hand, on different days, by different people.
Six events, three systems, and each system sees some events on some days. A sync that copies the count from Shopify to QuickBooks is copying a number that was already wrong about the builds and the receipts, and it overwrites a number that was wrong about the sales. Two-way syncs between two systems that are both not the master do not converge. They oscillate.
What it costs.
Oversold orders. Shopify sells a unit that a return did not restore or a build did not produce. The customer gets an apology and the company gets a review.
Dead stock. Components bought for a build that the count said was needed, sitting in a bin because the count was wrong in the other direction.
A finance count that does not match the floor. At year end the accountant values inventory from QuickBooks, the auditor counts the shelf, and the difference is written off. The write-off is the sum of a year of events nobody recorded.
Nobody trusts any number. Once the three disagree, every decision that depends on stock, whether to buy, whether to build, whether to promise a date, is made by walking to the shelf. That is a company whose systems have stopped being used for the one thing they exist for.
The fix is masters, not syncs.
We wrote the general principle in system of record versus source of truth: for each fact, one system is the master, and everything else is a view of it or a feed into it. For stock, it comes down to two facts with two masters.
Quantity belongs to the warehouse.
The warehouse system, whether that is Zoho Inventory, a WMS or a small application built for the purpose, is the only place that can see all six events, because all six happen to physical units in physical locations. So it becomes the master for quantity. Every event is recorded there first: receipts on arrival, builds on completion, picks and shipments on the floor, returns on inspection, counts on the day of the count. If your warehouse system cannot record builds and returns, that is the gap to fix first, and we have written about when to build that system and when to buy it.
Value belongs to the accounting system.
QuickBooks, or Zoho Books, is the master for what the stock is worth: the cost layers, the valuation method, the balance sheet figure. It should not keep its own quantity. It should receive the quantity movements from the warehouse as they happen, valued at cost, and post them. That is a one-way feed, and it means the year-end count matches the ledger because the ledger was built from the counts.
The shop is a view.
Shopify does not own anything. It shows the customer the available quantity, which is the warehouse quantity minus what is reserved for orders not yet picked, and it sends every new order to the warehouse as an event. One feed in, one feed out. When a return is inspected and put back, the warehouse tells Shopify, not the other way round.
The joins in the order that pays.
Orders from the shop to the warehouse first, because it is the event with the most volume and the one that is most often typed by hand.
Available quantity from the warehouse to the shop second, because it stops overselling the day it goes live.
Movements from the warehouse to accounting third, because it makes the ledger right, and because the accountant will be the one to tell you whether it worked.
Builds and returns recorded in the warehouse throughout, because the joins above are only as good as the events underneath them.
For a wholesale side of the same business, where orders arrive from an ERP or an EDI feed instead of a shop, the same masters hold and the order flow looks like this.
What we do not recommend.
We do not recommend a two-way sync between the shop and the accounting system, because neither is the master and the sync will fight itself. We do not recommend making the shop the master because it sees only sales. And we do not recommend replacing all three with an ERP to solve this, because the ERP will need the same six events recorded, and if they are not being recorded today, the ERP will show one wrong number instead of three.
How we start.
A no-risk discovery, a few days long. We take the ten products that sold the most last quarter, trace every one of the six events for each through the three systems, and show you where each count went wrong and by how much. Then a written plan and a guaranteed estimate for the joins, in the order above, with the masters named. If the plan finds the warehouse system cannot hold builds or returns, it says what to build or buy first, and the rest waits for that.
The short version.
Three counts are wrong because six events move stock and no system sees all six. A sync copies a wrong number into another wrong number. Make the warehouse the master for quantity and the accounting system the master for value, make the shop a view, and build the joins in the order that stops overselling first. Then the three numbers are one number, and people stop walking to the shelf.
Find out where your orders, inventory and invoices stop agreeing.
In a no-risk discovery we follow an order from sale to shipment to invoice across your systems and show where it breaks and what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments