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

BOOK A CALL

Amazon Cin7 Integration: Why Connected Is Not Configured Meta

A live Amazon and Cin7 sync can still oversell stock and misreport margin. See where mapping, allocation, and settlement logic actually break down.

SYSTEMS AND SOFTWARE

Pierre Goldie

8/3/20269 min read

Amazon & Cin7 Are Connected. Here Is Why That Is Not the Same as Working.

Pierre Goldie, Co-founder & CGO @ Fiskal

A Green Connection Status is Not Proof that Anything is Working

Amazon sellers running Cin7 open the integration panel, see a connected status, and assume the risk is behind them. Then the orders start overselling anyway. Or Amazon financials stop matching what the business expects to see in QuickBooks or Xero. The connection itself never went down.

This is the gap this article addresses directly. A technically live, error free sync between Amazon and Cin7 can still oversell stock, stall orders, and misreport margin, because the actual risk sits in mapping, allocation, and settlement logic underneath the connection, not in the connection itself.

That distinction matters for two different readers at once. An operations or ecommerce manager troubleshooting a live symptom needs to know where to look first. A finance stakeholder trying to trust the numbers needs to know why a clearing account will not reconcile to zero on demand. Both problems trace back to the same three layers, and this article walks through all three. For a broader look at this category of problem, see Fiskal's resource on reconciliation gaps.

This is not a case for disconnecting and rebuilding the integration. It is a case for auditing what is configured underneath a connection that is already live.

Most sellers reading this fall into one of two situations. Either they are about to connect Amazon and Cin7 for the first time and want to configure it correctly from the start, or they already have a live connection and are troubleshooting a specific symptom, such as overselling, orders that will not progress, or numbers that will not reconcile. In both cases, the underlying question is the same. Is this a genuine platform limitation, or a configuration and logic problem sitting underneath a technically working sync. This article is built to answer that question directly, layer by layer, rather than sending the reader back to generic setup steps they have likely already followed.

TL;DR

A connected Amazon and Cin7 integration can still oversell stock and misreport margin because the risk lives in mapping, allocation, and settlement logic, not in the sync connection itself.
FBM and FBA use different systems of record. Cin7 is the system of record for FBM. Amazon fulfillment centers are the system of record for FBA.
Pending Amazon orders must be reserved in Cin7 before that stock is treated as available elsewhere, or overselling follows.
Amazon multi packs must map to a Cin7 bundle or assembly SKU, never a simple one to one SKU, or stock counts corrupt silently.
Amazon revenue must be reconciled against official settlement files through a clearing account, not matched line by line against bank deposits.

Why Sellers Keep Seeing Symptoms After the Integration Goes Live

Clients rarely describe this as a mapping or allocation problem. They describe it operationally: we keep overselling on Amazon, or the numbers do not match between Cin7 and our books. The green connected status gives them no reason to look further, so the actual cause goes unexamined while the symptom repeats.

Three layers sit underneath a technically working sync, and a failure in any one of them produces the symptoms sellers report.

Mapping. Character level mismatches, such as trailing spaces or case differences between the Amazon Seller SKU and the Cin7 product code, hold incoming orders in a staging state rather than causing a clean failure. Unmapped tax rules or fulfillment locations do the same thing. This is the same category of failure covered in Fiskal's piece on SKU mapping errors, where mismatched or duplicate identifiers stall records instead of failing cleanly.

Allocation. Amazon orders sitting in Pending status, awaiting payment verification, are not automatically reserved against Cin7 stock. If Cin7 is not configured to hold that stock, it stays marked as available and gets sold again on another channel.

Settlement. Recording Amazon net payouts directly to income, without parsing the official settlement file, skips fee deductions and reserve holds. That produces a clearing account that never reconciles and a margin figure that understates real cost.

These three layers, mapping, allocation, and settlement, form what Fiskal refers to internally as the Three Layer Failure Stack. The value of naming them separately is practical, not academic. A connection can be technically live and error free at the API level while failing at any one of these three layers, and each layer produces a different symptom. Mapping failures stall orders. Allocation failures oversell stock. Settlement failures corrupt the numbers finance is trying to trust. Because all three sit beneath the same green connected status, the reader has no way to tell which layer is at fault without checking each one directly. That is the diagnostic gap this article exists to close.

Why Are Amazon Orders Not Syncing to Cin7?

Unmapped Seller SKUs, character level mismatches, or unmapped tax and location settings hold incoming orders in the Cin7 Amazon Integration Log instead of generating a fulfillment task. A changed Seller SKU on Amazon without a matching update in Cin7 produces the identical symptom. Check the Cin7 Amazon error log and the SKU mapping table first. Do not re authorize or reset the API connection as a first step. Resetting the connection can duplicate order downloads, disrupt historical sync state flags, or trigger stock overwrite loops across every connected channel.

Orders held for these reasons are not lost. They sit in the integration log and can be recovered once the mapping or setting is corrected.

FBM & FBA Do Not Run on The Same System, and That Is Where Most Misconfiguration Starts

Fulfilled by Merchant and Fulfilled by Amazon are often treated as one workflow with two labels. They are not. Each has a different system of record, a different sync direction, and a different update schedule, and Amazon Multi Channel Fulfillment adds a third flow that reverses the usual roles.

Why Does Amazon Inventory Sync Work Differently For FBA & FBM?

For FBM, Cin7 is the system of record. It calculates available to sell stock, on hand minus allocated, and pushes that figure to Amazon on a 15 to 30 minute cycle. For FBA, the Amazon fulfillment center is the system of record. Cin7 imports FBA shipment logs to decrement virtual FBA stock on a frequent polling cycle, and separately syncs the total FBA snapshot balance on a batch schedule of one to two times daily. These are two distinct data paths, not one, and confusing them is a common source of reconciliation error.

None of these flows run in real time. Treating FBM and FBA as a single generic sync, or assuming FBA only fulfills Amazon originated orders, is where setup mistakes compound. MCF is the exception worth naming on its own: a Shopify order, for example, is ingested by Cin7, which then transmits a fulfillment request to Amazon FBA. FBA ships it and tracking returns to Cin7. Cin7 is the originator here, and FBA is the executor, the reverse of the standard FBA flow.

The practical reason this distinction matters is that each flow assigns a different system as the source of truth. For FBM, if Cin7 says a unit is available, that figure should be trusted, because Cin7 is calculating it directly from on hand and allocated stock. For FBA, Cin7 is not calculating availability from first principles. It is importing what Amazon reports, on two separate schedules, and displaying it as though it were one continuous figure. A seller who does not know this will troubleshoot an FBA stock discrepancy the same way they would troubleshoot an FBM one, checking Cin7 configuration first, when the actual answer may simply be that the frequent shipment path and the batch snapshot path have not both updated yet. Waiting for both paths to complete their cycle resolves more apparent discrepancies than any configuration change does.

The Three Failure Patterns That Survive A Successful Connection

The section above explains how data actually moves through FBM, FBA, and MCF. This section explains what breaks when that movement is not configured correctly. Each of the three layers has a specific failure pattern attached to it, with its own trigger and its own symptom.

Each pattern is recoverable, but only once it is correctly identified. Orders held by the Sync Killer Configuration Trap are not lost, they are staged, waiting for a corrected mapping or setting. Stock sold twice under the Allocation Anchor and Overselling Trap cannot be recovered after the fact in the same way, since the commercial damage, a canceled order, a frustrated customer, or an account health flag, has already occurred by the time the pattern is spotted. Financial Settlement Drift compounds silently across every settlement cycle it goes unaddressed, since each unparsed payout adds another layer of unbooked fees to a clearing account balance the finance team is already struggling to explain.

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.