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 Unit Costs Are Wrong in Cin7 (Even After Fixes)

If you have already tried to fix unit costs in Cin7 Core and the numbers keep breaking, the problem is likely the layer you fixed it on. This article explains the system architecture behind the failure.

SYSTEMS AND SOFTWARE

Pierre Goldie

6/17/202616 min read

Why Your Unit Costs Are Wrong in Cin7 (Even After Fixes)

Pierre Goldie, Co-founder & CGO @ Fiskal

Most unit cost fixes in Cin7 Core fail because they are applied to the wrong system layer. The accounting layer and the informational display field are not where COGS is calculated.
The Average Cost field on the Cin7 product card is a display metric only. Editing it has no effect on any posted journal entry, the P&L, or the General Ledger.
Cin7 Core calculates COGS from the inventory cards picked under the product's costing method. Purchase invoice authorization confirms or updates the final cost layer used for those picked items. When stock ships before the purchase invoice is authorized, Cin7 looks for cost in this order: the Purchase Order cost if explicitly filled out, then Historical Average Cost at the time the stock receipt is authorized, then $0.00 only if neither exists.
When a cost correction is triggered after a sale has posted, the remediation path depends on transaction state, accounting integration, period status, and whether the COGS Maintenance Tool is used. Changing the visible product cost does not automatically fix the original financial impact.
Diagnosing unit cost errors correctly requires identifying the originating layer first: purchase receipt, landed cost allocation, or integration sync. The fix must go to that layer.

TLDR

Why does my Cin7 unit cost fix keep breaking?

The fix is likely correcting a display value rather than the underlying cost layer. Cin7 Core calculates COGS from FIFO or FEFO cost layers established at purchase invoice authorization, not from the Average Cost field shown on the product card. A fix applied to the wrong layer does not prevent the system from continuing to generate COGS from the original, unresolved cost layers. The numbers look corrected at month-end, and then break again the following period because nothing at the source has changed.

Where do unit cost errors in Cin7 actually originate?

At one of three layers. At the purchase receipt layer, when a purchase invoice is not yet authorized at the time of stock receipt, Cin7 looks for cost in this order: the Purchase Order cost if explicitly filled out, then Historical Average Cost at the time the stock receipt is authorized, then $0.00 only if neither value exists. Any sale processed before authorization inherits that cost. At the landed cost allocation layer, freight or duty invoices allocated after the goods have already been sold trigger a separate out-of-period adjustment entry rather than automatically correcting the original COGS impact. At the integration sync layer, costing method changes made while historical transactions are still open can cause costing and synchronization errors that persist until all historical transaction dependencies are completely resolved.

What happens if I keep applying fixes to the wrong layer?

Manual journals posted in Xero or QuickBooks Online correct the General Ledger surface without touching the Cin7 inventory subledger. The subledger remains structurally broken. Each subsequent period adds a new layer of adjustment on top of an unresolved root cause, making the diagnostic progressively harder. Where MRP or automated reorder logic is active, those systems operate on distorted cost data and generate inaccurate procurement suggestions. Purchasing decisions made on inflated gross margins can create cash flow pressure once catch-up adjustment entries correct the figures in a later period.

You ran the fix. The numbers looked right at month-end. Then the following period rolled around and the COGS figures were wrong again.

If this has happened more than once, the problem is not the fix you applied. The problem is the layer you applied it to.

Unit cost errors in Cin7 Core are not usually data entry mistakes that can be corrected by updating a value on a product card. They are structural mismatches between the layer where the error entered the system and the layer where the correction was made. Most fixes fail because they target the wrong one.

This article explains how Cin7 Core actually calculates and stores unit costs, why the most common fix attempts do not touch the right layer, and what a correct diagnostic approach looks like. It will not walk you through button sequences. It will give you the framework to understand why the fix needs to go where it does.

To make that framework useful, it helps to understand what the system is actually doing under the surface.

The Three-Layer Cost Architecture

Cin7 Core does not manage costs in a single unified system. It works across three distinct layers, and what happens in one layer does not automatically correct errors in another.

The Inventory Layer is where FIFO and FEFO cost cards live. This is where cost data originates. Cost layers are established here at purchase invoice authorization and mapped to specific inventory cards. This layer is the authoritative source of truth for unit costs.

The Integration Layer is the bridge. It governs how cost data is mapped and synced from Cin7 to Xero or QuickBooks Online. Configuration changes to costing methods, account mappings, or open transaction handling all affect this layer. When costing and synchronization errors occur, entries can get stuck until all historical transaction dependencies are completely resolved.

The Accounting Layer is where COGS journals and adjustment entries appear in the General Ledger. This layer receives cost data from the inventory layer via the integration layer. Corrections applied here do not travel back upstream. Posting a manual journal in Xero does not correct the cost cards in Cin7 Core.

The direction of data flow matters. Cost errors originate in the inventory layer and flow downstream into the accounting layer. That means the fix has to go upstream, to the source, not downstream to the General Ledger where the error is visible. This is why accounting layer fixes produce the visual impression of a correction while the system continues generating COGS from the same broken cost layer.

The Average Cost Field Is Not What It Looks Like

This is the most common misapplied fix in Cin7 Core, and it produces zero effect on any financial record.

The Average Cost field on the product details card looks like a cost figure. It is not. It is a derived display metric calculated as total asset value on hand divided by total quantity on hand. It recalculates dynamically as transactions are processed. It has no weight on the P&L, no weight on the General Ledger, and no role in FIFO or FEFO cost layer calculations.

Cin7 Core primarily uses FIFO (First-In, First-Out) or FEFO (First-Expired, First-Out) costing methods. Under these methods, the system tracks individual cost layers that are established when a purchase invoice is authorized. Each layer corresponds to a specific batch of stock received at a specific cost. When a sale ships, Cin7 Core draws from the oldest active cost layer. The Average Cost figure on the product card is not part of this process at any point.

Editing this field and running a cost update does not alter any FIFO or FEFO cost layer. It does not retrigger any posted COGS journal. It does not send a corrected entry to Xero or QuickBooks Online. The number on the card changes. Nothing else does.

The cost layers that actually govern COGS are upstream of the product card. They live in the transaction records created at purchase invoice authorization. Correcting unit costs in Cin7 Core means going to those records, not to the display field.

How Cin7 Core Actually Calculates and Posts COGS

Following a single item from procurement through to the General Ledger shows exactly where cost values are locked in, and where the windows for error occur.

Step 1: Stock Receipt Authorized

Step 2: Purchase Invoice Authorized

Step 3: Sale Shipment Authorized

Step 4: Late Landed Cost Allocated

Step 5: Out-of-Period Adjustment Entry Posted

Step 6: Divergence State

Physical units arrive and are added to inventory. If the purchase invoice has not yet been authorized, Cin7 Core looks for cost in this order: the Purchase Order cost if explicitly filled out, then Historical Average Cost at the time of stock receipt authorization, then $0.00 only if neither value exists. This is the first window for error: any stock received without a confirmed purchase invoice and without a PO cost or cost history enters the system at $0.

True cost layers are established. Cin7 Core maps these to the relevant inventory cards based on the configured costing method, FIFO or FEFO. The Average Cost display value updates at this moment as a consequence of the authorization, not as a driver of it. The cost layers that govern COGS are now in place.

At the moment the Sale Ship tab is authorized, Cin7 Core references the oldest active cost layer under FIFO rules and calculates a definitive COGS figure. This journal is automatically generated and pushed to the connected accounting platform. This is the point where the inventory layer and the accounting layer connect. After this moment, the COGS journal for this sale has posted. The remediation path for any correction from this point depends on transaction state, accounting integration, period status, and whether the COGS Maintenance Tool is used.

Two exceptions to the standard Ship tab trigger:

Dropship orders do not have a Ship tab. Their COGS transactions are generated when the purchase invoice is authorized, not at shipment.
Non-Inventory Products do not trigger cost transactions or inventory movements. Their costs are expensed at the point of purchase.

A freight invoice or customs duty invoice arrives and is allocated to the original purchase order after the corresponding inventory has already been sold. Cin7 Core calculates the cost variance delta. The stock is gone. The COGS journal for that sale has already posted.

Rather than reopening the original period, Cin7 Core generates a separate cost adjustment entry. The effective date of this entry defaults to the authorization date of the landed cost document, placing it in the current accounting period regardless of when the original sale occurred. This is by design. Cin7 Core protects historical period integrity. Where correction is required across previously posted periods, the COGS Maintenance Tool can void previously exported COGS journals for a selected date range and trigger a recalculated re-export.

There is one exception worth knowing: if the cost adjustment occurs while the stock is still physically in the warehouse, the new cost value binds directly to the inventory card layer before any sale has processed. The result is a clean single COGS entry on future sale, with no out-of-period adjustment required.

The accounting platform now holds the original COGS journal and a separate out-of-period adjustment entry as two distinct transactions in two different periods. Without cross-referencing at the transaction layer, monthly reporting shows unexplained margin movements that do not correspond to any current-period inventory activity.

Understanding this flow is essential to diagnosing unit cost errors correctly. The problem is rarely that the system made an error. The problem is that cost data entered the system at a specific point in this flow, and the fix was applied somewhere else.

Five Confirmed Failure Patterns

The failure patterns below are drawn from Fiskal diagnostic engagements. Each one maps to a specific layer and a specific trigger. Understanding which pattern applies determines where the fix needs to go.

Pattern 1: Costing Method Change With Open Transactions

Pattern 2: Landed Cost Allocated After Units Have Been Sold

Pattern 3: Average Cost Edited on the Product Card

Pattern 4: Sale Processed Before Purchase Invoice Is Authorized

Pattern 5: Manual Accounting Journal Applied to Correct COGS

Layer: Inventory valuation layer and integration sync layer.

Trigger: A product's costing method is changed while a historical transaction on that product remains incomplete. An unapplied payment on an old invoiced bill is a common example.

When a costing method change is made while historical transaction dependencies are still open, costing and synchronization errors will occur until all historical transaction dependencies are completely resolved. Open transaction lines stall across the bridge between systems. The subledger drifts out of alignment.

The correct remediation sequence:

Change the product's costing method back to its original state.
Authorize and complete all open historical workflows on the affected product.
Only then update the costing method.

Attempting the costing method change before completing this sequence restarts the problem.

Layer: Journal posting layer.

Trigger: Freight, customs duties, or handling surcharges are allocated to a purchase order after the corresponding inventory has already been sold and shipped.

Cin7 Core generates a separate out-of-period cost adjustment entry posting in the current period. This entry does not correspond to any current-period inventory movement. It creates margin noise in the current period and understates COGS in the original sale period.

This is expected system behaviour, not a bug. The problem is not that the entry exists. The problem is when it is not identified and managed as part of the month-end review process.

Layer: Interface misapplication.

Trigger: A cost correction is made by typing a new value into the Average Cost field on the Cin7 product details screen.

As covered above, this field is informational only. Editing it has no effect on any cost layer, any posted journal, or any financial record. The fix is either a formal Stock Revaluation transaction or correction of the original source purchase documents. The product card is not the right place.

Layer: Inventory valuation layer and journal posting layer.

Trigger: A sales order is fulfilled and shipped before the corresponding purchase invoice has been formally authorized and priced.

In Cin7 Core, cost layers are established at purchase invoice authorization, not at stock receipt. When a sale ships before the purchase invoice is authorized, Cin7 looks for cost in this order: the Purchase Order cost if explicitly filled out, then Historical Average Cost at the time of stock receipt authorization, then $0.00 only if neither value exists. Where no PO cost and no cost history exist for that SKU, the fulfillment records at $0 unit cost. Gross margins for that period spike artificially.

When the purchase invoice is eventually authorized, Cin7 Core generates a Cost Change / Cost Update transaction posting in the current period. The original sale period retains the prior cost entry. Neither period reflects the actual cost of the goods sold in isolation.

Layer: Accounting layer (General Ledger) only.

Trigger: A month-end discrepancy between the Cin7 inventory valuation and the Xero or QuickBooks COGS figure is corrected by posting a manual journal directly in the accounting platform.

The journal corrects the General Ledger surface. The Cin7 inventory subledger is untouched. The Inventory Asset balance in Xero or QuickBooks diverges from the Cin7 Core Inventory Movement Summary report. With every subsequent automated sync, the divergence widens. The manual journal does not prevent Cin7 from continuing to calculate and post COGS from the same uncorrected cost layers.

This pattern is common because it is the fix that forums, AI-generated content, and generic accounting advice tends to recommend. It is also the fix that makes the problem systematically harder to resolve over time.

Why the Fix Looks Like It Worked

At month-end, if the accounting layer has been manually adjusted, the P&L appears correct. The Inventory Asset balance in Xero may look approximately aligned. The numbers seem to add up. The natural conclusion is that the fix worked.

What is not visible in that view is the Cin7 inventory subledger. It still holds the original incorrect cost layers. The next sale will pull from those layers. The next period's COGS will diverge again.

The Xero P&L is not the right tool for confirming that a unit cost fix was successful. Two reports in Cin7 Core are the correct diagnostic reference points.

The Inventory Movement Summary shows the total inventory valuation held in Cin7 Core. If this figure does not match the combined total of all active Inventory Asset accounts on the Balance Sheet in Xero or QuickBooks Online, the two systems are not aligned at the inventory layer.

The Transactions vs Stock on Hand Difference Report shows the specific transactions where timing gaps or unresolved variances exist. This is the report that identifies whether a fix resolved the inventory layer or only the accounting surface.

A successful unit cost correction should produce matching figures across both systems. If the accounting platform looks correct but the Inventory Movement Summary diverges, the fix was applied downstream of the actual problem.

What a Clean System State Looks Like

Three indicators confirm that the unit cost architecture is functioning correctly and that the inventory layer and accounting layer are properly aligned.

Indicator 1

The Failed, Pending, and Skipped sync screens in the Cin7 Core integration logs show a nil count. No stuck or unresolved transactions are queued in the bridge between systems.

Indicator 2

The combined total of all active Inventory Asset accounts on the Balance Sheet in Xero or QuickBooks Online matches the live Cin7 Core Inventory Movement Summary report once documented timing items, such as un-invoiced stock receipts, currency differences, rounding adjustments, and known integration status are fully reconciled.

Indicator 3

Any remaining variance between the two systems is accounted for by legitimate timing items visible in the Transactions vs Stock on Hand Difference Report, such as goods that have been received but not yet invoiced.

These are not targets to reach at the end of a fix process. They are baselines that confirm a clean integration state at any point. If none of them are currently true, the gap between current state and clean state is the scope of the diagnostic work needed.

Three Things That Make the Problem Worse

Beyond the five failure patterns above, there are specific actions that actively compound unit cost errors and make subsequent diagnostics harder.

Force-balancing a clearing account with a plug journal entry

Cin7 Core uses clearing accounts, including GRNI and GINR accounts when Accrued Inventory Transactions is enabled, to manage timing gaps between stock receipt and purchase invoice authorization. Posting a manual plug to force-balance these accounts masks the underlying workflow error, breaks downstream audit tracking, and prevents the system from resolving the gap through its normal process.

Deleting live bank feed transactions during troubleshooting

Only manually imported statement files may be deleted to clear confirmed duplicates. Live bank feed transactions must not be deleted. Doing so creates gaps in the audit trail that cannot be cleanly restored.

Recording platform refunds as a raw Spend Money transaction from the bank feed

Processing a refund this way leaves an outstanding balance floating on the customer profile and breaks the subledger sync link. All refunds must be processed as a Credit Note within Cin7 Core to maintain the correct accounting trail.

The Correct Diagnostic Sequence

Step 1: Isolate the variance

Pull the Transactions vs Stock on Hand Difference Report in Cin7 Core. This identifies the specific transactions where the cost error entered the system and provides the transaction-level evidence needed to trace the error to its source.

Step 2: Identify the originating layer

Trace the variance to its source document. Is the error in a purchase receipt where the purchase invoice was not authorized at the time of receipt? Is it a landed cost that was allocated after the corresponding stock had been sold? Is it a costing method configuration issue with open historical transactions? The source document determines the layer. The layer determines the fix.

Step 3: Back up the current ledger data

Before making any changes to the accounting platform, back up the current state. This provides a reference point if the correction introduces unexpected downstream effects.

Step 4: Void, do not delete, incorrect entries in the accounting platform

If journal entries in Xero or QuickBooks Online need to be removed as part of the correction, void them rather than deleting them. Voiding preserves the audit trail. Deleting removes it.

Step 5: Correct the source documents in Cin7 Core

After the source corrections are made, trigger a fresh sync to push the corrected data to the accounting platform. Verify against the three health indicators above.

This sequence addresses the problem at the inventory layer and preserves the audit trail in the accounting platform. It is the correct order. Attempting to correct the accounting platform first, before identifying and fixing the source document, is the pattern that produces repeated month-end failures.

When unit costs are wrong and journals have already posted, the sequence in which the correction is made matters as much as the correction itself. Applying steps out of order creates additional complexity.

Step 6: Run a fresh manual sync

Make the corrections at the inventory layer, in the source purchase documents, receipts, or bills where the error originated. This is the step that actually resolves the problem. Steps 1 through 4 are preparation for this step.

Two Edge Cases Worth Knowing

Most unit cost errors follow one of the five patterns above. Two additional scenarios can produce misdiagnosis when they are not known.

Multi-Location Stock Transfers

When a Disassembly task is processed on a product bundle or kit in Cin7 Core, the system divides the parent product's historical cost base equally across all component lines by default, ignoring quantities per line. This applies unless a custom Disassembly Cost percentage is explicitly defined on the Bill of Materials before processing.

In practice, this means a low-value packaging component absorbs the same cost basis as a high-value electronic element. The unit costs of both resulting products are instantly distorted. This is a specific action that causes a unit cost problem rather than a symptom of an existing one, but it appears in diagnostics regularly in businesses that process product kits.

Disassembly Costing Splits

Stock transfers can affect FIFO analysis depending on the product's stock received date settings. If Cin7 is configured to update stock receipt date with transfer completion date, FIFO investigation based only on original receipt date can point the diagnostic to the wrong transaction layer.

Where this setting is active, the Stock Aging and Velocity Tracker metrics will also reflect the transfer date rather than the original procurement date. When diagnosing a unit cost problem on a transferred SKU, confirm the active setting before working from receipt date logic.

Why Unit Cost Errors Compound Over Time

A single unit cost error in a single period, left unresolved, does not stay contained. The compounding mechanism is straightforward.

In the period when a sale posts at $0 cost, gross margin appears artificially high. When the Cost Change / Cost Update transaction posts in a later period, gross margin drops. Neither period shows an accurate picture. If reporting is used to make purchasing decisions in the intervening time, those decisions are based on margin data that does not reflect actual cost.

Each manual journal applied to correct the accounting surface adds a layer of complexity to the diagnostic. The original error remains in the inventory layer. The manual correction sits on top of it in the accounting layer. The next automated sync may conflict with the manual correction. Over time, the number of overlapping adjustments makes it progressively harder to trace the original error to its source document.

Where MRP or automated reorder logic is active, the system consumes whatever cost data is present to generate procurement suggestions. If unit costs are understated, suggested reorder quantities may be too high. If unit costs are overstated, the system may recommend under-ordering. Neither produces reliable procurement guidance.

The business case for resolving unit cost errors at the inventory layer rather than patching them at the accounting layer is not primarily about the month-end P&L. It is about preventing the diagnostic from becoming progressively harder with each passing close cycle.

Need to Find Where Your Cin7 Unit Cost Error Actually Started?

If unit costs keep changing after each fix, the issue may not be the number showing on the product card. It may sit deeper in the purchase invoice, landed cost, inventory, disassembly, stock transfer, or accounting sync layer.

Fiskal's Financial System Diagnostic traces the error back to the originating transaction layer before more journals or adjustments are added. It maps the correct remediation sequence for your specific configuration before anything in either system is changed.

If you are running out of confident fixes, a diagnostic is the right next step.

Request a Financial System Diagnostic

The Fix Has to Go to the Source

The reason unit cost fixes in Cin7 Core fail to stick is almost always the same: the correction was applied to a layer that does not govern how COGS is calculated.

The Average Cost field on the product card is a display metric. It recalculates dynamically and has no weight on any posted financial record.

Cin7 Core establishes cost layers at purchase invoice authorization using FIFO or FEFO costing. It generates COGS at the moment of shipment authorization, drawing from those layers. When a cost correction is required after a sale has already posted, the remediation path depends on transaction state, accounting integration, period status, and whether the COGS Maintenance Tool is used. Changing the visible product cost does not automatically fix the original financial impact.

Understanding this architecture is a prerequisite for diagnosing unit cost errors correctly. The three-layer framework, inventory layer, integration layer, accounting layer, gives the diagnostic a structure. Corrections applied at the accounting layer do not travel upstream. The fix has to go to the source document, in Cin7 Core, at the layer where the error entered the system.

The five failure patterns in this article each have a specific originating layer and a specific fix pathway. Identifying which pattern applies is the diagnostic step that determines where the fix needs to go.