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 Cin7 Numbers Start to Diverge After Month-End Close

Cin7 figures change after month-end for identifiable system reasons, not because someone made an error. Learn what causes post-close divergence in Cin7 Core and what a stable close actually requires.

SYSTEMS AND SOFTWARE

Juandré Nortier

6/18/20269 min read

Why Cin7 Financial Reports Change After Month-End (and What Triggers It)

Juandré Nortier, System Team Lead @ Fiskal

Post-close divergence in Cin7 Core is not a random glitch. It tends to trace back to one or more of five conditions around costing logic, transaction timing, sync state, and close governance.

When a shipment is authorised before the matching supplier invoice is approved, inventory accrual is not enabled, and no usable cost history or authorised purchase cost is available, Cin7 may record the shipment at zero cost. If the supplier invoice is later backdated into the closed period, a cost adjustment entry may land there. If the invoice posts to the new period, the adjustment posts there instead.
Xero and QuickBooks Online lock dates sync into Cin7 Core after synchronisation. The lock date should be set in the accounting platform, not manually in Cin7. If a user backdates a transaction inside Cin7 into a period already locked in Xero or QBO, the sync may fail or flag as Failed in sync history.
The GRNI accrual balance on your balance sheet at period end is often expected system behaviour. Both the reversal and the accounts payable bill land on the invoice date, not the stock receipt date. A balance at period end is not automatically an error.
Revenue and COGS may be recognised in different periods if Invoice Tab and Ship Tab authorisations do not occur in the same period. This can affect gross margin reporting across consecutive months.
A visually clean sync queue does not confirm ledger integrity. If account mapping is misconfigured, transactions can sync with a Completed status while posting to the wrong GL accounts.

You close the month. You pull the reports. You distribute the management accounts.

Then, a week or two later, someone notices the numbers have changed. Your Cin7 inventory valuation looks different. Your COGS figure has shifted. Your Xero balance no longer matches the report you used to build the accounts. Nobody on the team can point to a single thing they did that caused it.

Post-close divergence in Cin7 Core is frequently the result of system behaviour operating as configured, just in ways a finance team running a standard month-end process may not expect. The mechanisms that move the numbers are identifiable and traceable. This article explains what they are.

TL;DR

How to Recognise Post-Close Divergence

Three signals tend to appear before the full picture is clear:

COGS or inventory valuation in Cin7 or Xero changes after management accounts have been distributed, by a meaningful amount with no obvious source.
The Financial Transactions vs Stock on Hand Difference report in Cin7 Core shows a gap that was not present at close.
The Xero Synchronisation Report shows Failed, Warning, or Skipped transactions dated to a period you consider closed, or the sync queue appears clear but the balances still do not reconcile.

Not every change after close is a problem requiring correction. Some adjustments, such as a cost entry landing in the current period because a supplier invoice was authorised after close without backdating, reflect the system working as intended. The question is whether the effective date and period assignment are accurate, and whether the change was expected given the close conditions at the time.

Why Cin7 Numbers Can Change After Month-End

Cin7 Core is a perpetual inventory system. It is designed to process transactions and cost events as they occur, not to freeze at a calendar boundary. If the controls that enforce that boundary are absent, incomplete, or misconfigured, new entries can land in a period the business has already reported on.

Those controls include the lock date managed in Xero or QuickBooks Online, the state of the sync queue at close, the authorisation status of open orders, and the transaction dates applied when processing late entries. When all of these are correctly set and confirmed, the period is genuinely closed. When one or more are not, subsequent transactions or cost events may affect figures the team considered final.

The five patterns below cover the most common sources.

Five Patterns That Can Move Numbers After Close

Pattern 1: Late Cost Events and Backdated Supplier Invoices

Pattern 2: GRNI Date-Split Logic

Pattern 3: Synced Lock Date Governance and Backdated Transaction Failures

Pattern 4: Invoice and Ship Tab COGS Decoupling

Pattern 5: Sync Failure States and Account Mapping Errors

Cin7 Core is designed to avoid altering historical COGS transactions. When a supplier invoice is authorised after a shipment has already been processed, the costing engine determines where to post any cost adjustment based on the effective date of the cost change.

If the supplier invoice is authorised in the new period without backdating, the cost adjustment will typically post to the current open period. This is the system working correctly. The prior period COGS is not changed.

Where this becomes a divergence risk is when a user manually backdates the supplier invoice or related cost document into the closed period. In that case, the cost adjustment entry may carry a date inside the previously reported month, potentially affecting figures that have already been distributed.

A related condition can occur when inventory accrual is not enabled and a shipment is authorised before the matching supplier invoice is approved, where no usable cost history or authorised purchase cost is available. In that configuration, Cin7 may record the shipment at zero cost at the time of authorisation. When the invoice is later processed, the resulting cost entry posts based on the effective date of that invoice. If the invoice is backdated, the entry may land in the closed period. If it is not backdated, it posts to the open period.

This pattern is most relevant in environments where inventory accrual is disabled and where sales and purchasing workflows are not tightly sequenced around the close boundary.

When the Accrued Inventory Transactions setting is enabled in Cin7 Core, the system creates a Goods Received Not Invoiced accrual entry when stock arrives before the supplier invoice is processed.

Many finance teams expect the GRNI reversal to post back to the original stock receipt date. In Cin7 Core, both the GRNI reversal and the accounts payable bill post on the invoice date, not the receipt date. If stock arrives in Month 1 and the invoice is processed in Month 2, the GRNI accrual legitimately sits on the balance sheet at the end of Month 1. It clears in Month 2.

A GRNI balance at period end is not automatically an error. It is expected behaviour when receipt and invoice dates span a period boundary. Finance teams who treat this balance as a discrepancy requiring correction can introduce reconciliation problems that were not present before.

The lock date in Cin7 Core is not managed independently. Xero lock dates sync into Cin7 Core after synchronisation, and QuickBooks Online lock dates sync into Cin7 through the product update process. The correct approach is to set the lock date in the accounting platform. Cin7 then uses the synced lock date to govern transaction posting.

If a user attempts to create or authorise a transaction in Cin7 with an effective date inside a period that is already locked in Xero or QBO, the sync may fail or flag that transaction as Failed in the sync history. This prevents the entry from reaching the general ledger for that period.

The risk this creates is a sub-ledger gap. The transaction exists in Cin7 but has not posted to the accounting platform. If that failure state is not investigated and resolved, the Cin7 sub-ledger and the general ledger will reflect different figures for that period. The gap may not be visible unless sync history is reviewed alongside a sub-ledger to GL reconciliation.

A related risk exists if the accounting platform lock date has not yet synced to Cin7 when backdated entries are processed. Depending on the timing of the sync, there may be a window where Cin7 accepts a backdated transaction that would subsequently fail when pushed to the locked accounting period.

In Cin7 Core, revenue is recognised when the Invoice tab is authorised and COGS is recognised when the Ship tab is authorised. These are separate workflow events that can occur in different periods.

At month-end, invoices are sometimes authorised to capture revenue in the current period while physical dispatch is confirmed in the following month. The result is that Month 1 carries revenue without the corresponding cost, and Month 2 absorbs the COGS for orders that belong to the prior period revenue. Management accounts prepared at Month 1 close may not accurately reflect the true gross margin for that period.

The Sale Process Customisation setting in Cin7 Core includes options that can align invoice and ship dates, which simplifies profit and loss reporting but introduces its own considerations for clearing account auditing. This is worth reviewing with a systems advisor before adjusting.

Failed, Warning, and Skipped states in the Xero Synchronisation Report indicate that a transaction has updated the Cin7 sub-ledger but has not reached the general ledger. Any of these states left uninvestigated at close represents a gap between what Cin7 reports and what the accounting platform holds.

Skipped items are not removed from the system. They remain visible in the Sync History log and can be filtered by status. A skipped item can be set back to Pending so it can be retried once the underlying issue is resolved.

A less visible version of this problem can occur even when the sync queue shows as clean. If account mapping is misconfigured, transactions may sync successfully with a Completed status while posting to the wrong GL accounts. No sync error appears, but the general ledger is incorrect. This is why sync clearance should be paired with a sub-ledger to GL reconciliation before the period is locked, not treated as a standalone confirmation of ledger integrity.

Why Common Fixes Can Make This Harder to Diagnose

Posting a manual journal in Xero or QBO to match the general ledger to the distributed management accounts addresses the GL symptom without changing anything in Cin7. When the underlying transactions finish processing, the system generates its own correction on top of the manual journal. Depending on timing and direction, the result can be a double-count or a reversal in the following period.

Manual journals in the accounting platform

Three responses appear regularly when post-close divergence is discovered. All three are understandable. All three can obscure the source of the problem.

Marking sync items as Skipped

Unlocking prior periods

Unlocking a prior period in Xero or QBO to allow a late adjustment to post can allow other pending transactions for that period to post as well. The downstream effects on historical margins, closed tax periods, and previously reported figures should be reviewed before the period is reopened. In many cases, accounting for the adjustment in the current open period is the cleaner path.

What a Stable Cin7 Close Should Check

All Shipments and Stock Receipts for the period should be in an Authorised state. Transactions in Draft or partial workflow states at close may be authorised later with dates inside the prior period.

Operational cutoff

A governed close in a Cin7 Core environment is a sequenced process. These checkpoints should be completed before the accounting platform lock date is set.

GRNI audit

Run the Stock Received vs Invoice report. Identify open GRNI layers and verify unit costs against the corresponding purchase order. Partially closed or orphan purchase orders should be resolved or formally deferred.

Sync history review

Review the Sync History log for the period being closed. Investigate any Failed, Warning, or Skipped items before locking. Do not mark items as Skipped to clear the view. A clean-looking queue is not confirmation of ledger agreement.

Sub-ledger to GL reconciliation

Before applying the lock date, confirm that the Cin7 sub-ledger and the accounting platform general ledger agree. The Cin7 Inventory Movement Summary, combined with the Financial Transactions vs Stock on Hand Difference Report, should equal the sum of GL inventory asset accounts in Xero or QuickBooks Online. If this does not balance, the period is not ready to lock.

Lock date via the accounting platform

Set the lock date in Xero or QuickBooks Online. Cin7 will sync the lock date from the accounting platform. Do not attempt to set the Cin7 Period Lock Date independently as a substitute. Once the lock date has synced, confirm that any queued or attempted backdated transactions are being handled correctly in sync history before considering the close complete.

If Your Cin7 Figures Keep Moving After Close

Post-close changes in Cin7 are usually traceable to a specific condition: a backdated transaction, a late cost event with an incorrectly assigned effective date, unresolved sync failures, or a close process that was not fully completed before reporting.

Identifying which condition is active, and how it is interacting with your specific configuration of costing logic, accrual settings, sync state, and lock date governance, requires looking at both systems together.

That is what the Fiskal Financial System Diagnostic does. It traces the discrepancy back through lock date behaviour, costing logic, GRNI state, sync history, and account mapping to identify the source and what needs to change.

The Numbers Moved Because of How the System Was Configured and Used

That is the frame most finance teams are missing.

Cin7 Core processed entries that were permitted by the conditions present at close. The lock date had not yet synced, or a transaction was backdated, or a supplier invoice was authorised after close with an effective date inside the prior period. In each case, the system responded according to its configuration and the dates applied to the transactions involved.

The fix is not a manual journal in Xero. It is a close process designed around how Cin7 Core, perpetual costing logic, and an asynchronous accounting integration actually work. The checklist above is the starting point. If the divergence has accumulated across multiple periods, a cross-system diagnostic is the faster path to identifying the source and resolving it cleanly.