Replenishment

Where Shopify's count drifts when goods arrive

Sales take themselves off your stock number. An arrival is typed in by a person, months after anyone could check the paperwork against the pallet.

Marcus VolstedCo-founder, Restocio Published 22 September 202613 min read

Every source on this page was opened and read, and each one is dated in the Sources section at the foot.

Shopify takes units off your count by itself when something sells. Putting them back after a supplier delivery is a person typing a number, which is why an importer's records drift at the receiving door before they drift anywhere else.

Nothing dramatic has to happen for it. A container turns up, someone opens it, someone types a number, and from that minute the record and the shelf are two separate facts that agree out of habit rather than by construction. With a supplier who delivers on Thursday the habit holds, because reality corrects the record within the week. With ninety days between ordering and arrival, a typed number gets a full quarter to be wrong, and every order you place in that quarter is built on it.

Where the count and the shelf part company

Five ordinary things happen at a delivery. Each one leaves the record saying something the warehouse does not.

What happened at the door	What the record ends up saying	Which way the number is wrong	What eventually reveals it
Only the air part of the order landed, the boat is still out	The whole order was marked received	Too high, by whatever is still at sea	The shelf empties while the admin still shows cover
The supplier shipped fewer units than the order said	The ordered quantity was typed, not the counted one	Too high, by the shortfall	Nothing, until you count or sell out early
The supplier shipped more than the order said	The ordered quantity was typed again	Too low, by the surplus	Nothing. Extra stock never raises an alarm
Units counted in against the neighbouring size or colour	One variant up, its sibling down, the product total correct	Both directions at once	One variant selling out repeatedly beside a twin that never moves
One delivery arrived as two drops on two days	Counted once for the whole quantity, or counted twice	Either, and the number cannot tell you which	A physical count, eventually

Read the last column rather than the first. The expensive mistakes here are not the large ones, they are the ones nothing in your admin ever contradicts.

The two mistakes no total will catch

Receiving a carton against the wrong variant is the quietest failure on that list. Thirty units of size 38 counted in as size 39 leaves the product's total exactly right, the stock value report exactly right, and both variants wrong. Every check you are likely to run agrees with itself. The tell is behavioural rather than numerical: one variant that keeps going dark next to a sibling that has not moved in months, with no sales pattern that explains either.

Over-shipment hides behind good manners. A factory that sends 620 against an order for 600 has done you a small favour, and nobody files a complaint about extra goods. Record the ordered 600 anyway and those twenty units sit on your shelf and in no system at all, so the product reads emptier than it is and comes up for reorder sooner than it needs to. The invoice is a separate conversation, and often a longer one.

A third version starts earlier, on the order line itself. A line carrying the factory's article number rather than your own SKU has nothing to match against when the goods land, so the units end up real, on the shelf and invisible to every calculation that nets what is already on its way. Restocio counts those lines on the order row so they can be fixed before the container arrives, and what belongs on the document is a post of its own.

Which direction the error runs

An overstated count is the dangerous one, because it moves two things at once. Take a product selling five a day. Shopify says 600 units, which reads as 120 days of cover. The shelf actually holds 450, because a short delivery was counted as complete, and that is 90 days. Your boat takes 70 days and you keep 30 spare days on top, so the last safe ordering day falls at 100 days of cover. On the record you have twenty days in hand. In the warehouse you are ten days past the point where ordering at boat prices was still possible.

Then the quantity moves too. Any reorder calculation worth using subtracts what you already have from what you need, so the 150 units you do not have are still being subtracted. You under-order by at least the size of the error, on the product where the error happened, which tends to be the product moving fastest.

Understatement is cheaper and still real. You buy stock you already own, park cash in it for a quarter, and never find out, because a full shelf raises no questions.

Restocio inherits all of this, and it is worth saying rather than implying. The plan starts from the quantity Shopify reports for each variant, so whatever drift is in your Shopify number is in our recommendation too, unit for unit. A record that says in stock while the shelf is empty also feeds days into your sales-rate measurement that were never selling days, which is the loop behind most repeat stockouts. And none of this is the same thing as stock that is genuinely still at sea, which Shopify tracks separately and leaves out of Available on purpose, covered in incoming inventory.

Finding drift without counting the whole warehouse

Shopify records who changed a quantity, when it happened and what it did to the number. Its page on viewing inventory adjustment history, read on 22 September 2026, also gives the limit worth knowing: you can view only the last 180 days of that history for a product or variant, and anything older has to come from the inventory adjustment changes report instead. For a sea importer, 180 days is barely two order cycles. A receipt typed last spring is already outside the window you can open from the product.

That still gives you a cheap first test. Open the history on a product you suspect, find the entry from the day the delivery landed, and put it beside the packing list for that delivery. Two numbers, one minute, and if they agree you have eliminated the likeliest cause without touching a shelf.

Choosing what to count is a ranking problem, not a moral one. Units sold a day times your lead time in days is how many units a bad record could cost you before a replacement could possibly land. A product selling twenty a day on a ninety day lead time has close to two thousand units riding on its count being right. A slow mover with a domestic supplier has almost nothing riding on it, and counting the whole catalogue evenly spends your afternoon on the second kind.

Inside Restocio there is a report built for exactly this question, on the cost of goods sold panel. For a period it lays four figures side by side, stock at the start, deliveries counted in, units sold and stock at the end, and shows what is left over in two places: units that left the shelf with no sale behind them, and units that appeared with no delivery counted in. Each is matched against the adjustments logged in the app, so a row can say how many were logged and how many are still unexplained. It states its own limits on screen too, since a period can only start the day after your first recorded day and the last three days can still move.

What counting a delivery in actually fixes

Goods in exists because one purchase order is rarely one arrival. The page opens by saying so: an order usually lands as several deliveries, the air part first and the boat weeks later, and each is counted on its own so the order is finished only when everything has really turned up. Creating those deliveries from an order records what is on the way and changes no stock.

What the counting screen asks for is deliberately narrow. You type how many units of each product arrived in this delivery, and that number is treated as the fact rather than as a confirmation of the order. A line that comes up short stays short, the summary line says how many units across how many product lines are still missing, and the delivery stays open until somebody accounts for them.

Type more than the delivery said and nothing clamps it. The extra shows as a plus figure on the line and the receipt keeps what you counted, because the goods are real and arguing with them helps nobody. That is the over-shipment row from the table, closed.

Two smaller pieces matter more than they look. Reopening a delivery you already counted part of brings back the counts you saved, so the second drop is counted without re-counting the first. And one delivery can carry lines from several purchase orders at once, with a badge on the row saying how many, which is how a consolidated container tends to arrive.

On the purchase order side, a mixed order asks which transport turned up before it fills in a single quantity, so counting the plane's units cannot close the boat's. Any line that comes up short then gets one question, whether the rest is still coming. Yes keeps those units on the way, where the late reminder can chase them. No takes them off the order with a dated note, so the next plan is free to buy them again.

The status follows the counts rather than the other way round. Nobody can mark an order partially received by hand, because a partial with no shortfall recorded anywhere is a claim the lines contradict. What did come up short collects in a list grouped by supplier with a copy button for the email, and the email itself stays yours to write.

One gap, and it is ours. The counting screen has columns for what was expected, what you counted, what is missing and what a unit cost, and no field for damaged units, even though the chase list is built to report damage separately from shortfall. Until that field exists, breakage found in the carton has to go in as a stock adjustment and in your own words to the supplier.

Correcting the number itself

Counting a delivery in fixes the plan. It does not fix Shopify, and keeping those two jobs apart is deliberate.

For the count itself there is a separate screen in SKU Manager. Type the number you actually counted, pick a reason from physical count, damaged, lost, found, returned to stock or other, and add a note if the reason needs one. Preview reads the live store and shows the location and the before and after without writing anything. The write is the second click, never the first.

Two details in that write are worth copying whether or not you ever use our app. The reason words map onto Shopify's own adjustment reasons, so a correction lands in its history as a manual count or as damage rather than as a bare edit your future self cannot interpret. And the write is a set guarded by the quantity we read a moment earlier, not an addition. If someone else changed the stock in between, Shopify refuses it and we say so, instead of overwriting their count. A double click cannot double count.

Now the limitation, since it belongs here rather than in a footnote. Every Shopify write in our codebase is a GraphQL mutation, and all of them sit behind one server-side switch that stays closed until launch day. Until it opens you get the preview, the reason and the log, and the number in Shopify is still yours to type. Counting goods in has never written a quantity to Shopify at all, and it will not start doing so quietly: the endpoint exists and is tested, and the receiving screens do not call it.

Shopify's own transfer flow handles part of this well, for what it is worth. Its page on receiving transfers, read the same day, says a transfer you only partly receive stays In progress until the rest is received, and that units you reject are recorded on the transfer without changing the quantity at any location. Rejecting is the right answer for goods going back. For breakage that stays in your building, the honest place is Shopify's Unavailable state, which covers units held back as damaged, for quality control or as safety stock. The gap for most importers is not the software. It is that a factory order agreed over email never becomes a transfer in the first place, so there is nothing to receive against.

The part that stays yours

No system can tell you how many units came out of a carton. What a system can do is make the moment of counting the only way a quantity enters your records, keep a shortfall visible until somebody answers for it, and refuse to invent the rest. Get that right and every number downstream, from days of cover to the size of the next container, inherits something true instead of something typed in a hurry. If you want the counting and the buying to be one system rather than two files that disagree, that is what Shopify replenishment looks like when it is wired together.

Common questions

Why does my Shopify inventory count not match what is on the shelf?

Nearly always because of what happened when goods came in. The ordered quantity was typed instead of the counted one, part of a split order was marked received before the rest landed, units went in against a neighbouring size or colour, or a delivery that arrived as two drops was counted once for the whole amount. A sale removes itself from the count. An arrival is typed by a person, and that is where the drift starts.

How do I correct a wrong inventory quantity in Shopify?

Set the quantity to what you counted and record why you changed it. Shopify keeps an adjustment history showing who changed a quantity, when it happened and what it did, and its help page states that you can view only the last 180 days of that history for a product or variant. Choosing a real reason, a count or damage rather than a bare edit, is what makes the entry readable months later when you are trying to work out where a product went.

What should I do if a supplier ships more units than I ordered?

Count all of them in. The goods are on your shelf whatever the order said, and a receipt that records the ordered quantity leaves the surplus invisible, which makes the product read emptier than it is and brings its next order forward. Restocio records the counted number even when it sits above the ordered one and shows the extra on the line. Check the invoice separately, because more units often means a larger bill.

How do I handle a delivery that arrives in two parts?

Count each part on the day it lands, against the same delivery, rather than waiting for the whole thing. In Restocio a purchase order is split into deliveries per transport, each one is counted on its own, and reopening a delivery brings back the counts you already saved so the second drop does not re-count the first. Whatever is still missing stays outstanding, which keeps those units on the way instead of disappearing from the plan.

Which products should I count first?

Rank them by units sold a day times your lead time in days, which is roughly how many units a wrong record could cost you before a replacement could possibly land. A product selling twenty a day on a ninety day lead time has close to two thousand units riding on its count. A slow mover with a domestic supplier has almost none. A short list counted often also beats a full count that keeps getting postponed.

Does counting goods in on Restocio change my Shopify stock level?

No. Counting a delivery in updates the purchase order and the replenishment plan, and writes nothing to Shopify. Every Shopify write in the app sits behind one server-side switch that is closed until launch, and the receiving screens do not call the quantity write-back even when it opens. Your Shopify number stays whatever your own process makes it, so build the receiving routine with that in mind.

Sources

Every source below was opened and read on the date shown against it. Rules, rates and schedules change, so check the current page before you act on a number that matters. If anything here is out of date or wrong, tell us and we will correct it.

Shopify Help Center, Viewing inventory adjustment history (read 22 September 2026)
Shopify Help Center, Receiving and managing inventory transfers (read 22 September 2026)
Shopify Help Center, Understanding inventory states (read 22 September 2026)

Marcus Volsted

Co-founder, Restocio

Marcus co-founded Restocio and works on it daily with a Swedish importer who plans their purchasing in it every working day. Restocio is built in Sweden by two founders, one Swedish and one Danish, and Marcus is the Danish one. Why we are building it.