There is a dangerous assumption in growing e-commerce businesses. If Amazon and Cin7 Core are connected, the inventory must be in sync.

It sounds logical. Amazon knows how much inventory you have. Cin7 Core knows how much you should have. Connect the two and they should stay aligned.

That is not always what happens. When a Cin7 Core and Amazon sync breaks, most teams treat it as a connectivity problem. Disconnect, reconnect, wait, repeat. Sometimes that clears a temporary fault. Most of the time it does not. The sync was following mapping instructions, settlement logic, or permission gaps that were wrong from the start. They were never configured properly during implementation.

That distinction matters because it determines where your team spends its time and what gets fixed. Fixing the mapping logic and governance underneath a broken sync requires a proper diagnosis, one that traces the reconciliation difference back to its source.

The Real Cost Of A Broken Cin7 And Amazon Sync

A sync issue rarely stays contained to one report. Stock counts drift, so you oversell a merchant fulfilled item that Amazon still lists as available while Cin7 Core already knows it is gone. Refunds do not match, so your finance team spends hours a week manually adjusting credit notes that should have flowed through automatically. Settlement reports stop lining up with consolidated orders in Xero or QuickBooks, so reconciliation turns into a guessing game at month end. Tax mismatches surface too, when Amazon tax handling and the tax rules mapped in Cin7 Core do not match.

These gaps compound across stock, refunds, and settlement reports until the numbers stop reflecting what happened. That is the real cost. Decisions get made on top of bad data before the reconciliation gap gets traced back to its source.

Connected does not mean the inventory agrees

The first thing to understand is that the problem is not necessarily the integration. Amazon does not treat every unit inside its fulfillment network as available.

Imagine you physically have 1,000 units inside Amazon's fulfillment network. At a particular point in time, those units might look like this:

Available: 400 units
Reserved, FC Transfer: 600 units
Total physical inventory: 1,000 units

Those 600 units have not disappeared. Amazon may simply be moving them between fulfillment centers.

Here is where it gets interesting. A native Cin7 connector may query Amazon and receive an available figure of 400. Cin7 Core was expecting 1,000. So the automated stock sync concludes that 600 units are missing. Depending on the configuration, Cin7 Core can create a negative stock adjustment for those 600 units.

Nothing physically happened to the inventory. The stock was not necessarily lost, damaged, or sold. Amazon moved it. But the integration is looking at a different definition of inventory, so a temporary status change reads as an inventory discrepancy.

We call this a ghost adjustment. Cin7 Core now shows 400 units because it has written down 600 units that may still physically exist inside Amazon's network.

A small sync issue has now reached the rest of the business.

Now orders start getting stuck

Say your Amazon integration loads orders into Cin7 Core when the customer pays. A new order arrives. Cin7 Core tries to allocate inventory from the FBA location. But the balance has already been reduced by the ghost adjustment, so Cin7 Core believes there is not enough stock.

The order can move into Draft or Backordered status. More orders arrive. More allocations accumulate. Eventually you can have a large backlog while Amazon still has inventory available to fulfill every order in it.

That backlog does not clear itself. Someone has to work through it order by order. Every hour spent there is time taken from work that matters. The longer an order sits, the harder it is to complete cleanly. The scale depends entirely on order volume.

Your team sees a stockout. Amazon sees inventory. Cin7 Core sees something else entirely.

This is why integration problems are so hard to diagnose. Every individual system can appear to be doing exactly what it was configured to do. The architecture is the problem.

Which system should own the process?

Start with the split between FBA and merchant fulfilled orders. They follow different rules. For merchant fulfilled orders, Cin7 Core is the system of record. For FBA, Amazon controls the physical execution. Amazon decides where the inventory sits, when it moves between fulfillment centers, and when it gets picked, packed, and shipped.

So why should Cin7 Core try to allocate stock that Amazon is already managing? For FBA orders, in many cases it should not.

Here is how it works today. Under the Load from Amazon setting, you choose between capturing orders when paid or when fully shipped. With paid capture, every Amazon sale enters Pending Orders and allocates stock in Cin7 Core right away. Some Amazon orders can also sit as pending on the Amazon side for up to two weeks before Cin7 Core can load them.

A cleaner architecture lets Amazon manage fulfillment while Cin7 Core records the completed transaction.

Instead of:
Customer pays → Order enters Cin7 Core → Cin7 Core allocates stock → Amazon fulfills the order

Move toward:
Customer pays → Amazon fulfills the order → Order ships → Completed transaction enters Cin7 Core

Once Amazon confirms shipment, the completed sale enters Cin7 Core and the inventory is deducted. Cin7 Core is no longer competing with Amazon's network for control of inventory in transit.

There are important exceptions. Shopify orders fulfilled through Amazon Multi Channel Fulfillment may still need paid capture, because downloading the paid order can be what starts the MCF fulfillment process. Capture also changes the transaction date, from the payment date to the ship date. That means the sale and COGS may be recorded on shipment instead of payment, which creates a timing difference between those events.

These are not reasons to avoid changing the architecture. They are reasons to understand the whole workflow before changing one setting.

For merchant fulfilled items, Cin7 Core only pushes stock levels to Amazon if that optional setting is switched on. Confirm that it is.

Replace unattended stock syncs with controlled reconciliation

The second change is equally important. Cin7 Core natively includes an Auto Sync Stock with FBA feature. It can sync daily, weekly, or monthly. The default is Never. Do not switch it on until you know which inventory figure Amazon sends back. An automated sync that writes adjustments into your inventory ledger based on incomplete inventory states should not operate unattended.

The alternative is a controlled reconciliation. Once a month, pull Amazon's Inventory Ledger and review the relevant inventory states:

Available
Reserved, FC Transfer
Reserved, FC Processing
Reserved, Customer Order

Together, those give you a much better picture of the inventory Amazon is actually holding. Compare that figure against the FBA location balance in Cin7 Core. Investigate the difference. Then make a documented stock adjustment where required. The Initial Stocktake or Sync function in the Stocktake module supports that process, rather than a flat CSV import.

Yes, that adds a manual control. But automation is not automatically better. One controlled monthly reconciliation is better than an automated process quietly writing incorrect adjustments into Cin7 Core every day.

One detail matters for finance. For products with zero stock on hand in Cin7 Core, the sync brings in the quantity, but the unit cost must be entered manually. A wrong cost here becomes a valuation problem, not just a count problem.

A planned monthly reconciliation is a control. Repeated unplanned stocktakes just to stay aligned are a signal. The sync cadence or product linking logic needs to be rebuilt, not worked around again. Start with product linking. Confirm that each FBA product is linked to its Cin7 Core product on the Amazon integration page, not only on the FBA page.

Two process gaps that also cause drift

Neither of these is a sync schedule issue. The native FBA integration does not support inbound shipments. Stock you send to Amazon needs a stock transfer to the FBA location in Cin7 Core. Without it, Cin7 Core has no record that the stock moved.

The native integration also does not support returns. Returned units need a deliberate process, because the integration does not bring them back for you.

Order and settlement reconciliation breakdowns

One of the most common frustrations we hear is that consolidated orders in Cin7 Core do not match the way Amazon's settlement report groups the same transactions. Amazon settles in batches, roughly every two weeks, that do not always correspond neatly to individual orders. Standard daily consolidation in Cin7 Core does not automatically account for every fee, adjustment, or reimbursement inside that batch.

If you use Xero, Cin7 Core has a setting for this. In the Amazon integration, set the Xero synchronization mode to Consolidate by Amazon settlement. Cin7 Core then exports one settlement invoice per settlement file. That setting takes priority over your other Xero sync and consolidation rules. When a settlement report covers two months, Cin7 Core splits it into two.

QuickBooks Online accounts need a different check. This mode is documented for Xero. Confirm how settlement data reaches your ledger before you change anything. Cin7 also documents a simpler option for some accounts. Setting the Amazon integration to No Consolidation captures each sale individually as it happens.

Mapping matters just as much as the mode. Amazon transaction types, such as fees and adjustments, need to be mapped to accounts in your chart of accounts. If a settlement report contains a transaction type that is not mapped, Cin7 Core notifies the master user of the account. That notification is easy to miss and hard to explain at month end.

The underlying gap is still structural. It comes from how the two systems group transactions by default, not from an accounting error. For Xero accounts, it is a gap with a documented setting to close it, not a reconciliation process to build from scratch. Confirming that setting is configured correctly, and that it is actually solving the mismatch for your account, is a controlling function. It is not a support ticket.

Refunds and credit notes on historical orders

How Cin7 Core handles a refund on an order placed before your Amazon integration went live depends on how that historical order entered Cin7 Core in the first place.

If the refund comes through as part of the automatic sync, Cin7 Core processes a standalone credit note and refund. The original order is not altered or synced. The restock tab is left empty and no inventory adjustment happens.

If your team manually loaded that historical order from the Pending Orders tab instead, Cin7 Core recreates the original sale order in full, with order lines, pick, pack, and ship detail, the credit note, and the restock lines together. Check how far back manual loading goes before you rely on it for older orders.

If your team does not know that distinction exists, the standalone credit notes from the automatic path look like duplicates or errors. Someone ends up manually adjusting entries that were already correct, or missing a restock that genuinely needs a manual stock adjustment. Knowing this in advance changes how you set up your credit note and refund accounts and your review process. Refunds should follow two separate workflows based on how the historical order was imported, because Cin7 Core is already treating them that way behind the scenes.

Getting the connection right the first time

Every Cin7 Core and Amazon connection needs a Seller Pro account, the correct eCommerce integration permission, an available integration connection on your subscription plan, and a chart of accounts and tax rules configured before the first sync runs. If you are selling through FBA, the Amazon integration is still required. You also add the Fulfillment by Amazon integration to your subscription if your plan does not include it, and your users need the Fulfillment by Amazon permission. Skipping or rushing any of these steps at setup is where most long term sync problems originate.

Treat this as a recurring pre launch checklist, and revisit it whenever you add a new marketplace, warehouse, or SKU category. Governance at setup prevents most of the drift that shows up as a sync issue six months later.

When to stop troubleshooting and call in a diagnostic partner

An integration can be technically connected and still be operationally wrong. The API can work. The sync can execute exactly as configured. And you can still end up with bad data.

The real question is not whether the systems are connected. It is whether they agree on what the data means, and whether you have decided which system owns each part of the process.

At 10 orders a day, you might never notice the difference. At significantly higher volumes, a temporary inventory status can turn into stock adjustments, allocation failures, and a growing backorder queue.

Some sync issues are user error, and those are worth fixing yourself. Others are architectural, built into how the integration was mapped from day one, and no amount of reconnecting or manual stocktaking will resolve them permanently. If you have rebuilt the same workaround more than twice, that is the signal.

Fixing the sync is not the same as fixing the workflow. Fiskal treats a sync issue as a diagnostic problem, not a connection problem. That means diagnosing the mapping logic, the reconciliation rhythm, the governance behind the sync, and the behavior change needed to keep it working. It also means looking at the complete flow between people, process, and technology.

For FBA, if Amazon owns fulfillment execution, let Amazon manage the inventory while it is in transit. Your ERP should record what actually happened. It should not fight Amazon's fulfillment network to decide what inventory exists.

Frequently Asked Questions

Why does my Cin7 Core stock count not match Amazon FBA?

Why do my consolidated Cin7 Core orders not match my Amazon settlement report?

By default, Cin7 Core consolidates orders daily, while Amazon settles transactions in batches that do not align with those daily groupings. Fees, reimbursements, adjustments, and refunds inside a settlement batch create the gap. For Xero accounts, setting the Xero synchronization mode in the Amazon integration to Consolidate by Amazon settlement closes this by exporting one settlement invoice per settlement file. QuickBooks Online accounts need a separate check, because this mode is documented for Xero. Amazon transaction types also need to be mapped to accounts, or Cin7 Core will flag them as unmapped.

What happens when I refund an Amazon order that predates my Cin7 Core integration?

It depends on how the historical order was imported. If it came through the automatic sync, Cin7 Core processes a standalone credit note and refund with no restock and no change to the original order. If your team manually loaded the order from the Pending Orders tab, Cin7 Core recreates the full original order along with the credit note and restock lines. Teams that do not know this distinction often treat a correct automatic entry as an error, or miss a restock that needs a manual adjustment.

What do I need before connecting Cin7 Core to Amazon?

You need a Seller Pro Amazon account, the eCommerce integration permission in Cin7 Core, an available integration connection on your subscription plan, and your chart of accounts and tax rules already set up. If you sell through FBA, the Amazon integration is still required. You also add the Fulfillment by Amazon integration to your subscription if your plan does not include it, and your users need the Fulfillment by Amazon permission. Missing any of these at setup is a common source of sync problems later.

When is a Cin7 Core and Amazon sync issue not something I can fix myself?

If the same sync problem keeps recurring after reconnecting, remapping, performing manual stocktakes, or manually correcting refunds more than once or twice, the issue is likely architectural rather than a one off error. At that point, a proper diagnostic review is more effective than continued troubleshooting.

Stock mismatches usually come from timing gaps between when FBA updates inventory and when Cin7 Core pulls that data, combined with product linking or mapping rules that were never tightened after go live. Cin7 Core's Auto Sync Stock with FBA feature defaults to Never, so confirm it is switched on. The Stocktake module's sync process can correct the count. Stock sent to Amazon also needs a stock transfer to the FBA location, and returns are not handled by the native integration. If you are repeating that reconciliation, the sync cadence or linking logic needs to be rebuilt.

Run a Cin7 Core Health Check

If your Cin7 setup has not been reviewed since a channel launch, a warehouse change, or a staff transition, a Diagnostic Call can identify where configuration may have drifted from how the business now operates, before it shows up in reconciliation or margin reporting.

Share on your socials.

Finance Ops:
Bookkeeping
Controlling
FP&A
Industries

Why Fiskal:
About us
Customer Stories
Careers
Contact Us

Contact Details:
+1 (954) 415-7895 or +1 (267) 717-7923
info@fiskalfinance.com
Offices:
Florida
New York
Pennsylvania
Stellenbosch

Resources
Blog
The Fiskal Score
Cin7 Academy
FAQs
Privacy Policy

Cin7 Solutions:
Problems We Solve
Integrations
Report Accuracy
Forecasting & MRP
Cin7 Implementation
Cin7 Support