Join our FREE webinar: Stock Take & Year-End Prep in Cin7 | Wednesday, December 17 at 12PM EST. Click to sign up →

BOOK A CALL

Shopify POS Cin7 Core Integration Setup Guide

If Shopify POS and Cin7 Core show different stock or margin numbers, the cause is usually setup, not a software bug. See what to check before you go live.

SYSTEMS AND SOFTWARE

Jaco Roets

8/4/202610 min read

Shopify POS + Cin7 Core: The Setup Decisions That Determine Whether Your Inventory and Financial Numbers Match

Jaco Roets, Co-founder & CEO @ Fiskal

The Assumption Most Businesses Start With

Connecting Shopify POS to Cin7 Core looks like it should be plug and play. Sales at the register sync down. Stock updates online. The ledger reflects reality. In practice, many businesses go live and find online stock stays available after an in store sale, or gross margin swings from one period to the next with no clear reason.

The instinct is to blame the integration. That instinct is usually wrong.

Whether the symptom looks like a Shopify issue or a Cin7 issue, accuracy depends on decisions made before go live. This article traces those decisions across both systems, using the Fulfillment Trigger Chain framework, so a business evaluating or setting up Shopify POS with Cin7 Core knows exactly what to check first.

One clarification before continuing. Cin7 Core and Cin7 Omni are separate products with separate integration behavior. This article is scoped to Cin7 Core.

TL;DR

Inventory and financial mismatches after connecting Shopify POS to Cin7 Core usually trace to setup decisions made before go live, not integration bugs.

Fulfillment authorization, not the sales invoice, is what triggers stock decrement and COGS posting in Cin7 Core.
Location mapping must be one to one between physical stores and Cin7 Core locations, or stock will be wrong at the location level even when totals look correct.
POS payment methods need dedicated clearing accounts, not a direct post to the bank feed, or reconciliation breaks down.
A pre go live review of mapping, fulfillment triggers, and clearing accounts prevents these gaps from surfacing during a peak period.

How Do I Know If My Setup Has a Mapping Problem?

Three signals show up most often, and none of them require a full audit to spot.

Online stock stays available after an in store sale, or an item shows out of stock online while it is physically on the shelf. Gross profit percentage swings from one period to the next with no obvious sales explanation. POS payment methods show up as a large uncleared or unreconciled balance against the bank feed.

Any one of these is worth investigating. All three together point to a setup gap somewhere in the chain below, not a single broken feature.

Defining The Problem

Three symptoms recur across Shopify POS and Cin7 Core implementations.

Online overselling happens when in store stock has not synced before an online sale completes. Phantom allocation happens when unfulfilled POS orders, holds, or layaways lock stock that is physically available to sell. Distorted gross profit percentage happens when revenue posts ahead of the matching cost of goods sold entry, while unreconciled clearing accounts pile up because POS payments posted directly to the bank feed instead of through a dedicated account.

A fourth version of the symptom is worth flagging early, because it looks like a separate bug the first time a business encounters it. When a sale originates as a Shopify Draft Order, or is edited through the Shopify Admin backend after the fact, the order location can default incorrectly. That creates a location level version of the same mismatch. Section 10.4 below covers this in full.

Guardrail worth stating plainly here: overselling is not always a Cin7 issue. Shopify POS's own out of stock warning is advisory, not blocking, regardless of any connected inventory system. A business can oversell on Shopify POS alone, with no Cin7 connection involved at all.

Why Do Shopify POS And Cin7 Core Show Different Numbers?

Accuracy depends on SKU mapping, location routing, fulfillment triggers, and payment clearing configuration decided before go live, not on the integration itself. The same symptom can originate on the Shopify side, the Cin7 side, or at the point where the two meet, so the correct fix depends on which one applies to the business in question.

Readers assume connecting Shopify POS to Cin7 Core is a plug and play setup that automatically manages inventory across all stores. What is actually happening is more specific. Fulfillment authorization, not the invoice, is the trigger for stock decrement and COGS in Cin7 Core, so a delay in fulfillment delays both numbers. Store locations mapped to a single generic warehouse location distort stock and COGS at the location level even when company wide totals look correct. Unmapped SKUs or variants entered directly in Shopify POS can stall the sync entirely, leaving the sale unrecorded in Cin7 Core until someone notices.

None of this means the integration itself is unreliable. It means the setup decisions made before the first sale determine what the integration is actually able to report.

The Fulfillment Trigger Chain

The clearest way to see where a setup gap breaks accuracy is to walk the full chain from checkout to ledger. Each layer is a discrete step. A gap at any layer explains a specific symptom further up this article.

Sales invoices, payment clearing entries, and COGS journals sync down to QuickBooks Online or Xero, settling fully against the bank feed once the payout clears.

Two details in this chain are easy to collapse together and should not be. Layer 4 and Layer 5 are separate postings. Payment does not clear at the moment of invoice authorization, it clears when payment is applied against that invoice. Keeping these separate is what makes an uncleared Payment Clearing Account balance something a business can diagnose, instead of a mystery line sitting on the balance sheet.

Layer 6 is the layer most businesses misunderstand. Fulfillment authorization, not the sale itself, is the trigger point for both stock decrement and COGS. A sale can be fully paid and invoiced and still show zero COGS impact if fulfillment has not been authorized yet. That gap is not a bug. It is the system working as designed, waiting for confirmation that the item actually left the shelf.

This chain also depends on true one to one mapping. Every physical retail store needs its own isolated location inside Cin7 Core. Sync speed through this chain can be affected by transaction volume and API rate limits, so it should not be assumed to run in true real time under every condition, particularly during high volume periods.

The Five Setup Gaps Behind Most Mismatches

Five patterns account for the majority of Shopify POS and Cin7 Core mismatches. Location mapping is the most cited root cause across available evidence and should be weighted accordingly. The other four occur less often but are just as diagnosable once named.

The Location Blend has a second, less obvious trigger worth its own explanation, because it does not look like a mapping problem the first time a business runs into it. When a sale originates at a physical POS outlet as a Draft Order, or is modified through the Shopify Admin backend, Shopify defaults the order location to the store's designated location for online sales, typically the main warehouse, rather than the physical outlet where the sale actually happened. Cin7 Core then soft allocates stock against that main warehouse location instead of the physical store until fulfillment completes. The result is a temporary but real distortion. Online overselling risk rises at the main warehouse location while the physical store's available stock reads lower than it actually is. This is the same root pattern as The Location Blend, triggered a different way, not a separate bug.

Duplicate SKU handling deserves its own explanation, because Shopify and Cin7 Core simply enforce different rules. Shopify allows duplicate SKUs across different product listings or price variants. Cin7 Core enforces unique SKUs as a primary key. This is a data rule difference, not a defect in either system, and it needs to be accounted for during setup rather than discovered after go live.

If Enable import of duplicate SKUs is left disabled in Cin7 Core, duplicate SKU downloads fail or are silently skipped, which reads to the business as an unexplained sync gap rather than an obvious error. If it is enabled instead, Cin7 Core automatically generates non salable KitProducts using Shopify's unique VariantID as the SKU. These KitProducts link back to the true MainProduct through an Assembly Bill of Materials, with Auto Assembly and Auto Disassembly active, which is the mechanism that keeps central stock counts accurate despite the duplicate SKU on the Shopify side.

One more edge case surfaces specifically around cancellations. When an online sale, or a POS sale set to Auto Pick, Pack, and Ship, is cancelled or refunded before physical fulfillment happens, Cin7 Core attempts to restock items that were never actually shipped. That attempt produces a recurring Pending fulfillment error on the Cin7 Core integration log and blocks the credit note from posting. To the business, this looks like a broken refund process. It is a setup gap with a specific fix. Enabling Ignore restock for non fulfilled sales in the Cin7 Core integration settings is required for any business running auto fulfillment workflows, so unfulfilled refunds process cleanly instead of stalling the integration log.

Offline POS sales queuing, in store returns processed as a credit note versus a refund, POS discounts and price overrides mapping to Cin7 Core discount lines, and multi store replenishment requiring a system stock transfer each introduce their own version of the mapping and timing problem already established above. Each is worth a dedicated setup conversation before go live rather than a fix afterward.

Can Amazon And Cin7 Be Fully Connected And Still Oversell?

Yes. If Cin7 is not configured to reserve inventory for Amazon orders sitting in Pending status, those physical units stay marked as available and continue to be sold on other connected channels. A live, error free sync status confirms the connection is up. It does not confirm that allocation holds are configured correctly. This is a reservation logic failure, not an API failure, and it needs to be diagnosed as one.

Connected Is Not The Same Claim As Correctly Configured

The belief driving most of this is simple: it is connected, so it must be working. That belief is incomplete. Data can move correctly between Amazon and Cin7 while the mapping, allocation, or settlement logic underneath it is wrong.

AI tools reinforce the same gap. They tend to describe the sync as real time, which it is not at any layer. They recommend reconnecting the API as a default fix, which addresses no actual layer of the failure. And they treat inventory sync and financial accounting as two separate problems, when fee deductions and settlement holds directly corrupt the accounting ledger the moment they go unparsed.

This matters for the decision most readers are actually weighing, which is whether to keep troubleshooting internally or bring in a specialist. If the working assumption is that the sync is broken, the natural next step is to keep poking at the connection, reauthorizing it, checking API credentials, or waiting for Amazon or Cin7 support to resolve it. None of that addresses a mapping table, a Pending order hold rule, or a settlement file that has never been parsed. The specialist question is not whether the platform failed. It is whether anyone has actually audited the three layers underneath the connection.

What a Correctly Configured Amazon and Cin7 Setup Actually Looks Like

These are verifiable configuration states, not aspirational best practice language. Each one can be checked directly.

On the settlement point specifically: the clearing account does not balance to zero on any arbitrary day. Amazon Rolling Reserves withhold funds across payout cycles, so the account reconciles to zero for a specific settlement period, once payout, reserve hold adjustments, and settlement fee adjustments have all posted. Expecting it to sit at zero in between settlement periods is expecting the wrong thing from the account.

Each of these four states can be checked directly against the live setup rather than taken on faith. Virtual location isolation is confirmed by looking at the location itself, not by asking whether the sync is connected. Mapping completeness is confirmed by a mapping table with zero unmapped rows, not by an absence of recent complaints. Pending order hold rules are confirmed by watching what happens to available quantity the moment a Pending order is received, not after it ships. Settlement reconciliation cadence is confirmed by whether the bi weekly parsing routine actually exists, not by whether the bank balance looks approximately right. A setup that cannot be verified this specifically has not actually been confirmed as correct, regardless of how long it has been running without a visible incident.

The Operational Symptom And The Financial Symptom Share One Root Cause

Overselling on the sales floor and clearing account drift on the finance side look like two different departments having two different problems. They are not. Both trace back to the same three layers: mapping, allocation, and settlement. A technically live integration and a correctly configured one are not the same claim, and the distance between them is exactly those three layers. For a closer look at how understated costs distort profitability, see Fiskal's piece on margin figures you cannot trust.

Resolving this means auditing the connection against what FBA and FBM each actually require, not reconnecting the integration or replacing it.

Treating account health risk and financial reporting risk as separate problems is itself part of the misdiagnosis. The operations team escalates overselling to Amazon support. The finance team escalates a clearing account that will not close to the bookkeeper. Neither escalation reaches the mapping table, the Pending order hold rule, or the settlement parsing routine that actually caused both symptoms. A diagnostic audit that looks at all three layers at once, rather than routing each symptom to a different team, is the only way to close the gap between connected and configured for good.

What Never To Do When Troubleshooting Amazon and Cin7

Each of the three actions below feels like a reasonable first response to a visible symptom. Each one makes the underlying problem worse rather than better, and each one is reversible only with difficulty once taken.

None of these three actions are wrong because they are lazy shortcuts. They are wrong because they treat a symptom as though it were the cause, and by the time the actual cause is found, the shortcut has usually introduced a second problem on top of the first.

Is Your Amazon and Cin7 Integration Actually Configured, or Just Connected?

A connected status confirms the API is talking. It does not confirm that mapping, allocation, and settlement logic are configured to match what FBM and FBA each actually require. If your team is seeing overselling, stalled orders, or a clearing account that never quite reconciles, the fix is not to reconnect anything. It is to audit the layer that is actually failing.

Book a structured Fiskal Systems and Integration Health Audit. Our team reviews your mapping rules, allocation logic, and clearing account workflows, and turns your integration into a system you can actually trust for stock and margin decisions.

This is not a recommendation for every Amazon and Cin7 user. It is a recommendation for teams already seeing one or more of the symptoms named above: stalled orders, overselling across channels, or a clearing account that never quite closes.