Cin7 Inventory Management Problems: Ranked Causes and Fixes

Cin7 inventory management goes wrong in a fairly fixed order when it runs beside Shopify, and this page ranks the causes by how likely we think each one is, with a fix and a test for each. The ranking is our working judgement from how these setups tend to fail, not a measured data set, so read it as a triage order rather than a statistic.

The reader here is an operator at a $3M–$30M brand on Shopify Plus or a paid subscription platform, already live on Cin7, with stock numbers that sometimes disagree between the two. It is not an evaluation of whether to buy Cin7, and it is not for brands under the $3M floor with one shelf and a spreadsheet. For the wider picture of how inventory software fits an ecommerce stack, start with ecommerce inventory software.

What does Cin7 inventory management change when it sits beside Shopify?

Cin7 adds a second ledger. Shopify already holds an inventory level for every variant at every location, and checkout reads it. Cin7 holds its own stock records for purchasing, receiving, warehouses and other channels. A connector moves numbers between the two. Every problem in this article is some version of the two ledgers disagreeing, or of the connector doing exactly what it was told and the instruction being wrong.

Two consequences follow. First, a stock number in Shopify is now a copy, and a copy can be stale. Second, “the sync is broken” is almost never the right first diagnosis, because a sync that runs on time and moves the wrong number looks identical from the outside to one that has stopped.

The Cin7 products and connectors vary by plan and have changed over the years, so this article claims no specific feature. Where a fix depends on a setting, it says what to look for and tells you to confirm it in Cin7’s own documentation and in the documentation of whichever connector you use.

Which causes come first, and in what order should you check them?

Check the causes in numbered order. The ordering matters more than any single fix, because the early causes produce most of the confusing symptoms and hide the later ones. A team that starts at cause 6 will spend a week tuning something that cause 1 keeps undoing.

Use the table to decide where to start. Each cause gets its own section below.

1. Are two systems writing the same stock number?

Unclear ownership of the stock number is the most likely cause, and it hides well. Ownership means one system is allowed to set the on-hand quantity for a variant and the other only receives it. In practice, both write. A warehouse lead corrects a count in Cin7. A merchandiser edits inventory in Shopify admin to “fix” a product that shows sold out. A returns app adds stock to Shopify directly. The connector then overwrites one with the other.

The symptom is a number that reverts. Someone fixes it, it looks right for an hour, and then it snaps back to the old value. People conclude the sync is flaky. The sync is faithfully applying whichever write arrived last.

The fix is a written rule and a small amount of enforcement. Decide the owner of on-hand quantity (for most operators with purchasing and a warehouse process, that is Cin7). Then list every path that can change stock in the other system: manual edits, apps, bulk imports, returns tools, a 3PL connection. Remove or restrict each one, and reduce staff permissions in Shopify so that editing inventory is not something a merchandiser can do by accident.

An opinion a vendor would not write: most of the effort in this fix is not technical. It is getting three teams to stop being helpful. The person who fixes a count in Shopify at 9am is solving a real problem for a real customer. Give them a route that writes to the owning system instead, or they will keep doing it.

Test the result by picking five SKUs, changing each in the non-owning system, and confirming the change is either blocked or clearly overwritten and logged. If it is silently accepted and then lost, the ownership rule is not enforced yet.

2. Do your Shopify locations map to the right Cin7 warehouses?

Location mapping is the second most likely cause. Shopify organises stock by location: a warehouse, a retail shop, a 3PL, sometimes a dummy location created to hold pre-orders. Cin7 organises stock by its own warehouse or branch structure. The connector has to be told which corresponds to which, and that mapping is easy to get wrong and easy to forget when something is added.

A typical break: a brand adds a second fulfilment location in Shopify to route east-coast orders, and nobody adds the matching mapping. Shopify now shows stock at the new location as its own number, while Cin7 keeps counting everything at the original warehouse. The total looks plausible. The per-location numbers are fiction.

Check it with one SKU. In Shopify, open the product’s inventory and note the available quantity at each location. In Cin7, note the stock in each warehouse. Every Shopify location should map to exactly one Cin7 warehouse, and every Cin7 warehouse that sells online should map to exactly one Shopify location. A location that maps to nothing, or two that map to one, is your finding.

Retail and pre-order locations deserve special care. If Shopify has a location that exists only to allow overselling on a backorder, decide deliberately whether it appears in the connector at all. Including it can push phantom stock into Cin7.

For the wider problem of holding one stock picture across several places, see multi-channel inventory management software, which covers the structural side this page skips.

3. Why do some products never update at all?

Identifier mismatch is third. The connector links a Shopify variant to a Cin7 product by an identifier, normally the SKU, though you should confirm in your connector’s documentation exactly which field it matches on. If the identifiers differ by a single character, a trailing space, a changed case, or a re-used SKU, the link fails and that product is simply never updated.

The pattern is deceptive because most of the catalogue works. The broken products tend to be the ones that were renamed, merged, imported from an old system or created by hand in a hurry. A single duplicated SKU can point two Shopify variants at one Cin7 product, so a sale of one drains the stock of the other.

The fix is an identifier audit, done in a spreadsheet, in three passes:

1. Export all Shopify variants with their SKU and variant ID. Export all Cin7 products with their SKU.
2. Normalise both columns (trim spaces, apply one case) and list every identifier present in one system and missing from the other.
3. Sort the Shopify export by SKU and flag every SKU used by more than one variant, and any variant with an empty SKU.

Every flagged row is a decision: correct the identifier, retire the product, or accept that it is not synced and document why. The audit takes an afternoon the first time and minutes after that, because it is only a join. Make it a scheduled check rather than a project, since new products keep creating new mismatches.

On the Shopify side, Shopify inventory tracking covers how the platform records levels per variant, which is the half of this problem you can inspect without touching Cin7.

4. Do Shopify and Cin7 agree on what “available” means?

Definition mismatch is fourth, and it produces the small, stubborn gaps that survive every other fix. Inventory systems separate several quantities: what is physically on hand, what is committed to orders that have not shipped, what is incoming, and what is available to sell. Shopify has its own set of states, and Cin7 has its own. The names overlap while the meanings may not.

If the connector pushes Cin7’s on-hand figure into Shopify’s available field, Shopify will happily sell units that are already allocated to open orders. If it pushes an available figure that has already deducted allocations, and Shopify then deducts the same orders again when they arrive, you undercount. Both errors are small per order and large across a promotion.

Work out the definitions before changing anything. In Cin7’s documentation, find how it defines the quantity your connector sends. In Shopify’s documentation, find which states are available, committed, unavailable and on hand, and which one checkout reads. Then run a controlled test with one SKU:

• Note starting on-hand and available in both systems.
• Place one order and note both systems before fulfilment.
• Fulfil it and note both again.
• Receive one unit against a purchase order and note both again.

The four snapshots show exactly where each system moves and whether the connector double-counts. Do this once per fulfilment location type, because a 3PL location may behave differently from your own warehouse.

Here is a hypothetical, for illustration only. A SKU has 10 units on hand and 3 committed to open orders, so 7 are available. The connector sends on-hand (10) to Shopify’s available field. Shopify sells 8 more units against a real availability of 7, and one customer is told the item has shipped when it has not. Nothing was broken. The wrong field was mapped.

5. Do bundles and kits deduct stock the way you think?

Bundles come fifth because not every brand has them, but where they exist they cause disproportionate drift. There are at least three different mechanisms: a Shopify bundle app that manages components, a Shopify product that represents a bundle with its own stock number, and an assembly or kit record in Cin7. Each deducts differently, and mixing them is the mistake.

A common failure: the Shopify listing is a bundle with its own SKU and its own stock number, Cin7 has the individual components, and the connector has no idea the bundle is made of them. Bundle sales reduce a number that Cin7 never sees, while the components stay full until someone notices they cannot be picked.

The fix is to choose one place where the bundle-to-component relationship lives, and make the other system read from it. Then test with a real order: sell one bundle and follow every component’s number through both systems. If you cannot make one system hold the relationship, consider whether the bundle should be a set of separate line items instead. Shopify bundles without an app describes what the platform can do natively, which limits what your connector can reasonably be asked to reproduce.

6. Which adjustments bypass the sync?

Adjustments come sixth. Receiving a purchase order, a cycle count, a write-off, a transfer between warehouses, a return restocked: none of these is a sale, and many connectors are built around the sale. Whether the adjustment reaches Shopify depends on the connector and how it is configured, so it must be tested, not assumed.

The symptom appears the morning after a stocktake. The warehouse has corrected 40 SKUs in Cin7, everyone is satisfied, and Shopify still shows the old numbers because nothing told it. Or a purchase order is received, and stock that has been physically on the shelf for two days still shows as sold out online.

Test it once for each adjustment type you actually use. Change one count, receive one unit, transfer one unit, restock one return. After each, look at the same SKU in Shopify at the right location, and write down whether the change arrived, how it arrived (as a set-to-value or as a plus and minus), and after how long. That table is your real behaviour, and it is worth more than any documentation summary.

A set-to-value adjustment and a plus-or-minus adjustment behave very differently when an order lands between the count and the sync. The first can overwrite a sale that happened in the gap. If your connector supports both, read how it chooses between them.

If purchase orders drive most of your receiving, purchase order automation software covers the upstream half, which decides how quickly received stock becomes sellable stock at all.

7. Does timing or rate limiting cause the oversells?

Timing is seventh, which surprises people, because it is the first thing most teams suspect. Any connector that polls or batches has a gap between an event and the update. In normal trading the gap costs nothing. During a launch or a flash sale, orders arrive faster than updates, and the last few units get sold more than once.

Rate limits add to it. Shopify’s and Cin7’s APIs both restrict how many requests an app can make in a window, and a large catalogue updated all at once may queue. The specific limits are published by each vendor and change, so read them in the current developer documentation rather than trusting a figure from a blog post, including this one.

Diagnose it by comparing timestamps. Take three oversold orders and, for each, find the time of the order, the time of the last stock update to Shopify for that SKU, and the time Cin7 recorded the corresponding movement. If the update arrived after the order every time, you have a latency problem. If it arrived before and the number was still wrong, you are back at causes 1 to 6.

Mitigations, in order of cost:

• Hold back a buffer on fast sellers during promotions, so the last units are never offered.
• Limit which SKUs sync during a peak, so a large catalogue does not queue behind the products that matter.
• Ask your connector vendor what schedule and mechanism it uses, and whether that can be tightened on your plan.

Buffers are unglamorous and effective. A promotion that oversells by a handful of units costs less to prevent with a stock hold than to apologise for. The trade is a few units of foregone sales against a set of cancelled orders and support tickets.

8. Would you know if the sync failed?

Silent failure is eighth in likelihood but first in how much it costs when it happens, because it removes the evidence for every other cause. A connector rejects an update because a SKU is missing, an authentication token expires, a rate limit is hit, and the error goes into a log nobody reads.

Decide three things now. Where do failures land (an email list, a Slack channel, a ticket queue)? Who owns each failure type? How long may an unresolved failure sit before someone is paged? Then build the smallest thing that answers: a daily reconciliation that flags drift, and an alert on any sync error, sent to a person.

Reconciliation is where automation earns its place. The reconciliation is a scheduled job: pull both stock lists, join on SKU and location, and post the exceptions. It does not need AI. It is deterministic, and that is the point, because a check that occasionally guesses is worse than no check. Where an AI step could help is in explaining an exception to a human, and even there, a wrong explanation costs more than a human minute, so keep a person in the loop for corrections.

How do you check the whole thing works?

Run the full check once after any fix, and on a schedule afterwards. It has four parts.

1. Reconcile. Export Shopify available by location and Cin7 available by warehouse, join on SKU and mapped location, and list every difference. The target is an empty list, or a short list where each row has a known, written reason.
2. Trace one order. Place a test order and follow the numbers through Shopify and Cin7 at each state, as in cause 4.
3. Trace one adjustment of each type. Count, receipt, transfer and return, as in cause 6.
4. Trigger one failure on purpose. Use a SKU that is deliberately unmatched and confirm someone is told.

Record the results in a page the team can see. When a number goes wrong six months later, the page tells you which of your assumptions has expired.

Where does Cin7 not help you?

Whatever purchasing or forecasting features your Cin7 plan includes, they work from the numbers you give them and do not make a forecast good. It records stock and movements; the quality of reorder decisions depends on the demand data behind them. For that half of the problem, demand and inventory planning covers the forecasting side, which is separate from keeping the counts right.

Cin7 also does not fix a bad process. If receiving is late, locations are undefined and counts are rare, a connector will move the mess faster. Sort out the physical process before blaming the software. And do not put an AI agent on any stock decision where the underlying data is unreliable: refunds, allocations and order edits belong with a human until the reconciliation is clean for a sustained period.

Running Cin7 beside Shopify is an ops automation problem: two systems, one stock number, and the work is deciding who owns it, mapping it correctly and building the checks that tell you when it drifts. If that describes your setup and the reconciliation is still done by hand, our ops automation service is built for exactly this.