Oct 27, 2026Sourcing Guides
Shopify Inventory Reconciliation with a China Warehouse: Keeping Stock, Returns and Re-Listing in Sync
Two stock numbers, one store and one China warehouse. The cut-off, the bundle map, the return log and the re-listing gate that keep a store from selling what it cannot ship.
The store says one number. The warehouse counts another. Nobody has sold anything unusual. No order failed. Yet the number has drifted for a month.
This is a common state of a store that outgrew the spreadsheet. Orders, returns and re-listings each move stock, and each one moves it in a different system. When the two sides disagree, the store keeps selling and the warehouse keeps picking, and the gap turns into a cancelled order or a refund.
Shopify inventory reconciliation is the routine that closes that gap. Not an annual stocktake. A short, repeated comparison with a fixed cut-off, a fixed set of definitions and a record of why any difference exists.
We run China fulfillment for stores with live order flow. The sequence below is the one we use to keep a store and a warehouse on the same numbers.
Fix the Cut-Off Before You Compare Any Two Stock Numbers
Two stock files only compare if they describe the same moment. The same test applies to a 3PL report and an in-house count. A common reconciliation argument starts there, not in the arithmetic.
Pick a window: daily or weekly, one is enough, as long as it is the same every time. Then pick a cut-off time inside it. Everything shipped before the cut-off belongs to the old count. Everything picked but not shipped belongs to the next one. Returns received but not yet graded sit in their own bucket. Without those rules, a difference is just a time zone.
Record two timestamps on every file: when the export was generated, and when the physical count was taken. If they are hours apart, the comparison is already soft. If the file has no timestamp, put one in the filename and in the log.
Both files should carry the same fields: code, quantity, status and timestamp. A report that changes shape every week is not comparable with last week's.
The test is simple. Take one SKU you know moved during the window. If the store file and the warehouse file disagree on it, ask whether the order shipped before or after the cut-off. The answer may explain the difference on its own.
A difference that moves every time you recount is often a cut-off problem, not a stock problem. We fix the window before we touch the number.
One SKU, One Bundle, One Warehouse Code
The store sells variants. The warehouse stores physical units. Between them sits a mapping, and quiet discrepancies can live in it.
Take a shirt in three colors and four sizes. The store sees twelve variants. The warehouse should see twelve codes, each with its own barcode and its own shelf position. If the store lists a parent and the warehouse invents the child SKUs at inbound, the mapping is being built by the person with the least information.
Bundles are the harder case. A bundle sold as one unit consumes several components. Decide which component the sale decrements, whether the bundle has its own physical pack and label, and whether it is assembled at the warehouse or arrives pre-packed. Then write that decision into the map, because a bundle that decrements one component while the others sit uncounted will look like a shortage within a month.
Kits have the same trap when they are built to order. The components are picked, the kit is packed, and the store sees one sale. If the component stock is not decremented at the moment of packing, the next count finds pieces that the system still believes are on the shelf.
We keep the map as one table: store variant, warehouse code, barcode, unit of measure, component list. Then check that it is still true. A re-label, a new supplier pack size or a discontinued color can break a line that worked last quarter.
Print the map and keep it at the packing bench. The person who packs a bundle is the last chance to catch a wrong component. If a barcode will not scan, relabel the unit before the next inbound; a hand-keyed code is a new code.
One product, one code. Everything else is a guess.
Stock on the Shelf, Stock Promised, Stock for Sale
Three numbers matter, and they are not the same number.
Stock on the shelf is what a counter would find. Stock promised is what open orders have already claimed. Stock for sale is the difference, minus anything held back for damage, quality checks or returns that are not yet graded. A store that publishes the first number sells units that are already promised. A store that publishes the third sells what it can actually ship.
Keep three separate fields. On-hand, reserved and available are not interchangeable, and the store should read the third.
Negative stock is a signal, not a mistake to hide. It can mean one of four things: an order shipped against a receipt that was never posted, a return was restocked twice, a bundle consumed the wrong component, or two warehouse codes point at the same physical unit. Each has a different fix. An adjustment number hides all four, and the next count finds them again.
We treat the warehouse as the owner of the physical count and the store as the owner of what has been promised to a customer. That split has to be explicit, because a field that both sides write to will eventually disagree with itself.
Watch the reserved field after a big promotion or a batch of cancellations. Stock that stays reserved after the order is cancelled is stock you cannot sell and cannot see. Release it the same day, or the next count will look short for no reason.
Three numbers, one shelf.
Receiving and Returns Restock: Where the Count Starts to Drift
The count starts to drift at two doors. Inbound and returns.
At inbound, agree whether the warehouse counts cartons or units, and post the receipt only after the count is complete. A partial receipt posted early makes stock available that is still in a carton on the floor. If the count is short, record the difference before the carton is opened further.
Returns are the second door, and they are messier because the unit arrives in an unknown state. A returned unit should enter the count as a return, not as new stock. Every returned unit is graded before it goes back into sellable stock, and the grade decides whether it enters the available pool, waits for a decision, or leaves the pool entirely.
A common source of drift is timing. A store may refund the customer as soon as the parcel is scanned, and the unit appears available before anyone has opened the box. Or the opposite: the unit is graded and shelved, but the store still shows it as sold, so the warehouse has stock the store will not sell. Both are record problems, and both are fixed by making the status change once, at the moment the grade is recorded.
We count the same way on both sides. If the warehouse counts pieces and the store counts packs, convert at the map, not in someone's head.
Two doors, one rule: a unit enters sellable stock when a record says so.
Cycle Counts and the Recount Trigger
A cycle count is a small, repeated count of part of the warehouse, not a shutdown. Its purpose is to catch drift while it is still small enough to explain.
Count blind. The counter should not see the expected quantity, and the count sheet should not carry a column that invites a copy. When the count is done, compare it with the system, and if there is a difference, recount before adjusting. A single wrong count is common. A wrong adjustment is expensive, because it erases the evidence.
We set the trigger by rule, not by feel. Any difference on a serialized or high-value item goes to recount and a location sweep. A difference that repeats on the same code in two cycles goes to the mapping table, because the problem is probably not on the shelf. A difference that appears across several codes in the same aisle goes to the receiving log.
Start where the money and the movement are: high-value items, fast movers and locations where picks and returns share a shelf.
Use reason codes that name the failure: mispick, unposted receipt, ungraded return, bundle component, wrong location, damage not written off, duplicate posting. A code that says miscellaneous teaches nobody anything.
Decide who may approve an adjustment and what has to be attached: the count sheet, the second count, the reason code and the reviewer's name. Then review the codes monthly. The pattern is the useful output, not the individual fix.
Count blind. Recount before you adjust.
API Sync and the Re-Listing Gate
The sync has one job: move stock and orders between the store and the warehouse without inventing numbers. A common failure comes from unclear direction, not from the software.
Write in one direction per field. The warehouse owns the physical count and pushes it to the store. The store owns orders and pushes them to the warehouse. If both sides can write the same quantity, the last message wins, and the last message is not always the true one.
In our operation, orders enter our queue within a 12-hour response window. That window is for order intake, not a promise about how fast stock updates. Inventory updates follow the agreed rhythm: the warehouse posts a receipt, a pick, a return grade or an adjustment, and the store receives it.
Watch the failure queue. A failed push rarely announces itself. It sits in a queue, the store keeps selling, and the warehouse finds out at the pick face. A failed push on a busy morning can sell stock that has already left the shelf. Someone should own that queue and look at it daily, and the queue should show what failed, when, and whether the retry worked.
The re-listing gate is the other half. We do not put a unit back on sale until its grading record exists and the stock update has been posted. A refunded unit with no grade is not stock, and the store should not list it.
One field, one writer. Our fulfillment process, including returns grading, is covered at (/b2c-fulfillment), alongside the warehouse work.
Set the Last Stock File Next to the Return Log
Reconciliation is not a system feature. It is a habit with a fixed window, a mapping, three numbers, two doors, a count rule and one writer per field. The documents show whether the habit is working.
Set the last stock file next to the return log (/contact-us). Include the SKU and bundle map you are using, including the component list for anything sold as a set. We read the three together, look for the drift pattern and send back a reconciliation worksheet and a variance threshold table.
We take on fulfillment work from five orders a day. Below that, a formal routine may be more process than the store needs, and we would rather say so.
If the last count and the last return do not match, the packet is still useful. That gap is the reason to start.
Two files, one question.
