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

BOOK A CALL

Why Your Closed Month in Cin7 Keeps Changing

Locking Xero doesn't protect Cin7 Core. Learn why closed-period COGS changes after month-end, which transactions trigger it, and what a genuinely protected close requires.

SYSTEMS AND SOFTWARE

Christo Kleinhans

7/12/20269 min read

Why Your Closed Month in Cin7 Keeps Changing

Christo Kleinhans, COO @ Fiskal

TL;DR

Locking the month in Xero or QBO does not protect it in Cin7 Core. Cin7 Core requires its own separately configured lock date under Settings > General Settings > Financial Settings.
That lock date is disabled by default and must be manually advanced every period. Most implementations have never activated it.
A single backdated transaction can distort COGS across the following 3 to 6 months through FIFO cost layer recalculation, with no notification from either system.
The problem can be triggered automatically by Shopify return date mappings and 3PL late ship logs. Operator training alone is not a sufficient control.

You closed the month. You reconciled the accounts, ran the reports, and sent them to leadership. A week later someone notices that the COGS figure for that period has changed. Nobody touched the closed period. Nothing in Xero has moved. And yet the number is different.

This is not a sync glitch. What happened is a structural period-control failure, and it will keep happening until the underlying configuration is fixed.

Most finance teams running Cin7 Core integrated with Xero or QuickBooks Online are working with an incomplete model of how period protection actually works. The assumption is: lock the month in Xero, and the period is protected. That assumption is wrong. This article explains why, which transactions trigger it, and what a genuinely protected close requires.

Why Did My Cin7 COGS or Inventory Figures Change After I Closed the Month?

Cin7 Core accepted a transaction with an effective date, invoice date, or shipment date that falls inside the closed period. Without Cin7's own internal lock date configured, there is no mechanism to block this. Cin7 processes the backdated transaction first, recalculates its FIFO cost layers from that historical date forward, and updates its internal figures immediately. The accounting system only enters the picture when Cin7 attempts to push the corresponding document across the integration. The change to the closed period happens inside Cin7. It is silent.

Why Doesn't Locking the Month in Xero Stop Cin7 From Changing the Figures?

The Xero lock date and the Cin7 Core internal lock date are completely separate controls. They do not communicate. The Xero lock date is a gate that Xero applies to incoming transactional documents from Cin7. By the time that gate activates, Cin7 has already accepted the transaction, recalculated its FIFO cost layers, and updated its own internal reports. The Xero lock date stops the accounting system from changing. It does not stop Cin7 from changing.

The Cin7 Core internal lock date lives in Settings > General Settings > Financial Settings. It is disabled by default. When it is not configured, Cin7 will accept any effective date, any invoice date, any shipment date, regardless of which period it falls into. When Xero's lock date blocks a document from Cin7, the push fails without proactive notification. No banner. No email. The transaction sits as a visible, retryable error in the Cin7 Sync History log. Cin7's internal figures have changed. Xero's have not. The two systems are showing different numbers for the same closed period, and neither has told anyone.

How Far Back Can a Single Backdated Transaction Affect my Figures?

Further than most finance teams expect. A backdated purchase invoice that alters a FIFO cost layer does not only affect the period it is backdated to. Every subsequent period that used stock from the same cost batch will also have its COGS figure recalculated. A single late invoice can distort gross margin data across the following 3 to 6 months, until the affected stock batch is fully depleted.

If the invoice is backdated to a period where the related stock has already been sold, Cin7 generates a Cost Correction. Based on SME operational experience with standard Cin7 Core configurations, this correction is likely to post against the original historical transaction date rather than appearing as a new adjustment in the current open period. That means it updates the closed period directly. The opening balance for the next period may also shift, creating a cascading reconciliation problem across months you have already reported on or filed against.

What Cin7 Does When a Backdated Date Gets Through

Cin7 Core does not log a new entry in the current period and move on. It goes back to the historical date and rebuilds the FIFO cost layers from that point forward. Every sale that drew stock from the affected cost batch has its COGS figure recalculated. A single backdated purchase invoice can change COGS across the following 3 to 6 months, depending on how quickly that stock batch turns over. One late supplier invoice, entered with last month's date, can quietly rewrite half a financial year of gross margin data.

The FIFO recalculation happens inside Cin7's internal inventory ledger. If the Xero lock date is active and blocks the sync, the accounting system shows no change. The mismatch between the two systems is invisible until someone specifically compares the Cin7 Inventory Ledger balance against the Xero Trial Balance inventory asset account.

The most acute version occurs when a purchase invoice is authorised after the related stock has already been sold. Cin7 generates a Cost Correction to reconcile the difference between the cost it used at shipment and the actual invoiced cost. Based on SME operational experience with standard Cin7 Core configurations, this correction is likely to post against the original historical transaction date. That means the correction rewrites the COGS figure in the closed period where the sale occurred, rather than appearing as a transparent adjustment in the current month.

Which Transactions Trigger the Problem

1. Backdated purchase invoices

The most common trigger. A supplier delivers their invoice late. The operator uses the date on the supplier's document rather than today's date. Cin7 accepts it without a warning. The cost layer recalculation runs immediately across every sale that drew from that batch.

2. Late invoices after stock has already been sold

The highest FIFO cascade risk. A purchase invoice is authorised after the related stock has been sold and COGS already posted. Cin7 generates a Cost Correction that is likely to post against the historical sale date in standard configurations. For businesses with fast-moving inventory and routinely late suppliers, this is a recurring source of closed-period changes, not an isolated incident.

If your late invoices are a symptom of broken stock-receipt or procurement workflows upstream, the Fiskal receiving errors article covers that root cause in detail.

3. Backdated credit notes

The effective date field on a Cin7 credit note defaults to today but is independently editable. Operators routinely overwrite it with the original invoice date for supplier reconciliation purposes. The consequence is that the reversal posts into the period where the original invoice sits, which may already be closed.

4. Shipment date versus invoice date mismatch

COGS in Cin7 Core is driven by the shipment authorisation date. Revenue is driven by the invoice date. When an order placed in one period is fulfilled after month-end and the shipment date is recorded as the original dispatch date, COGS posts into the prior closed period while revenue posts into the current one. Gross margin is wrong in both periods. This behaviour is the same for Xero and QBO integrations.

If the margin distortion you are seeing tracks specifically to shipment timing, the Fiskal Cin7 sales and COGS mismatch article covers the mechanics of this pattern in more depth.

5. Automated backdating via Shopify returns and 3PL late logs

No one on the team did anything. The system did it automatically. Depending on how the integration mapping rules are configured, Shopify integrations frequently inject return journals using the original historical order date rather than the date the return was processed. A customer return from 45 days ago posts into a period that closed five weeks earlier. With 3PL connections, a late ship log carrying a physical dispatch date from before month-end causes the operator to backdate the Cin7 shipment date to match operational reality. The COGS journal follows the shipment date into the closed period. This risk lives at the integration layer, not the operator workflow layer.

Why Finance Teams Miss This

The most common configuration asymmetry: the finance team locks the month in Xero, treats the period as protected, and moves on. What is not visible is the operational timing gap between what Xero enforces and what Cin7 enforces. Xero's lock date has no reach into Cin7's internal inventory sub-ledger. If Cin7 has already recalculated its cost layers and updated its internal reports, the Xero lock date arrives too late to prevent that internal change.

The second control invisibility gap is the automation vector. Finance teams are trained to investigate when someone changes something. But Shopify return integrations and 3PL late ship logs can inject backdated transactions without any human decision point. A closed period can change because of a customer return processed 45 days after the original sale. No operator touched the closed period. The integration mapping did what it was configured to do.

The Cin7 Sync History does record sync failures as hard, visible error lines. But it generates no proactive notification. No banner. No email. A finance team without an explicit Sync History review step on the close checklist will not encounter this information unless they go looking for it.

What a Genuinely Protected Close Requires

Period protection in Cin7 Core is a three-part control framework. All three are required.

Lock date in the accounting system: Set a lock date in Xero or QBO that covers the closed period before moving on to the next month.
Lock date in Cin7 Core: Set a matching lock date under Settings > General Settings > Financial Settings. This is the step most implementations are missing. It must be manually advanced every single period. It does not auto-advance. It does not inherit from Xero or QBO.
Post-close reconciliation: Compare the Cin7 Inventory Ledger closing balance against the inventory asset account in the Xero or QBO Trial Balance. If they diverge, find the source before the next period opens.

What Should Never be Done

Never deauthorise and reauthorise a historical transaction to fix an administrative detail. Reauthorisation triggers a full FIFO recalculation from that date forward and frequently corrupts cost layers for unrelated sales.

Never make manual inventory quantity adjustments in the current month to offset a historical valuation discrepancy. This masks the symptom while leaving the FIFO distortions intact.

Never treat a single lock date as sufficient. Setting only the Xero or QBO lock date is, for Cin7 period control purposes, the same as setting neither.

For businesses that have been using manual adjustments in Xero to force inventory balances to match Cin7, those manual journals are themselves a source of permanent sub-ledger desynchronisation. The Fiskal inventory not matching article explains why, and why the fix requires removing the manual journal and addressing the root cause in Cin7.

The Commercial Consequence of an Unprotected Close

The effective date problem is easy to underestimate when you first encounter it. A COGS figure moved slightly. A gross margin is a few percentage points different. It feels like a cleanup task.

The actual exposure is usually larger than the visible discrepancy and almost always older than the period where it first became visible. A backdated purchase invoice from six months ago may have altered a cost layer that touched every period since. Assessing the full scope requires a structured cross-system diagnostic. It cannot be determined from within Xero or Cin7 alone.

For businesses that have prepared tax filings or annual financial statements against period figures that subsequently changed, the consequence is a retrospective amendment burden. Correcting historical financial statements after filing introduces preventable compliance penalties during routine data reviews.

If Your Figures Have Changed - or you are not sure they have not

If the COGS or inventory figures in a closed month have changed without explanation, the immediate question is not how to fix the visible discrepancy. The more important question is how far back the distortion may have gone, and which periods have been affected across months you have already signed off on, reported to leadership, or filed against.

If your month-end close process has never included a lock date step inside Cin7 Core, then every period you have closed since implementation has been structurally exposed to the problem described in this article. Without a cross-system reconciliation, there is no way to know which periods have changed.

The Fiskal Financial System Diagnostic maps the gap between what Cin7 Core is currently reporting and what your accounting system shows. It traces the source of any effective date distortions across your transaction history, identifies which periods and cost layers have been affected, and provides a clear picture of what needs to be corrected before the damage compounds further.

The Problem Does Not Fix Itself

Closing the month in Xero or QBO does not protect it in Cin7 Core. The two systems enforce period control independently. A lock date in Xero tells Xero what to reject. It has no authority over what Cin7 accepts.

The Cin7 Core internal lock date is disabled by default. It requires manual configuration every period. In most implementations, it has never been activated. The problem can be triggered by operator action, by integration behaviour, or by both.

The most common scenario: Xero shows a closed period with stable figures. Inside Cin7, that period has been quietly rewritten. Neither system has surfaced the difference. The gap is visible only when the two are specifically compared. The dual lock date configuration is what closes it.