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

BOOK A CALL

Cin7 Wrong PO Quantities? Why Clean Data Is Not the Fix

Cin7 purchase suggestions can be wrong even with clean sales data. See the configuration and allocation logic actually driving demand planning failures.

SYSTEMS AND SOFTWARE

Juandré Nortier

7/21/20268 min read

Why Cin7 Keeps Suggesting the Wrong Purchase Order Quantities (Even With Clean Data)

Juandré Nortier, ERP Sytems Lead @ Fiskal

Your sales data is clean. Your team reconciles it every month. And Cin7 still tells you to reorder stock you do not need, or misses a shortage that shows up two weeks later on the warehouse floor.

The instinct is to blame the data. It is usually not the data.

TL;DR

Clean sales data does not guarantee an accurate Cin7 demand plan.
Six configuration and logic points, channel consolidation, static reorder parameters, cold start SKUs, allocation logic, lead time records, and BOM explosion, can each break the plan independently of data quality.
Allocation logic can hold stock against authorized but unfulfilled orders. To a planner running an MRP sweep, that reads as a real stock drop. It is not.
The financial cost shows up as overstock, stockouts, working capital strain, and a ledger that no longer matches the warehouse.
The fix is a configuration and allocation logic review, not another data cleanup pass.

Why Does Cin7 Keep Suggesting the Wrong Purchase Order Quantities?

Purchasing suggestions can be wrong even when the sales data feeding them is clean. The break usually sits at a configuration or logic layer, not in the data itself. Six named failure patterns, from channel consolidation settings to BOM explosion toggles, can each cause this independently, and most were set once at implementation and never revisited.

The Problem Is Not the Data

Purchasing suggestions that do not match warehouse reality force a planner to manually review every MRP run before trusting it. That is expensive on its own. But the deeper problem is what it does downstream: cash tied up in stock nobody ordered, expedited freight bills on stock that ran out, and working capital strain when overseas suppliers demand a significant deposit months before goods land.

A planner who no longer trusts the suggested supply grid starts overriding it manually, SKU by SKU, every planning cycle. That is not a workaround. It is the system quietly reverting to manual planning while still charging the business for automated planning it is not getting. The hours spent on that manual override are hours the planning team could spend on the exceptions that actually need judgment, not on re verifying a suggestion the engine should have gotten right.

This happens independent of data quality. Good sales history alone does not produce an accurate plan. Data cleanliness still matters. It is necessary. It has just never been sufficient on its own.

The Root Cause Sits in Configuration, Not in the Numbers

The common assumption is simple: our data is clean, so the plan should be accurate. The reality is that configuration and allocation logic decide the planning outcome just as much as the sales data does.

Settings chosen at implementation for accounting convenience, daily sales consolidation, single warehouse rollups, come at the direct cost of planning granularity. Reorder points, lead time assumptions, and supply routing rules get configured once when the business is small, and rarely get revisited as the business scales into new channels and new SKU volume.

This is not a platform limitation. Evidence consistently points to configuration and review cadence. The fields exist. Nobody goes back to check them once the business outgrows the assumptions baked in at setup. A configuration built for one warehouse and two sales channels does not fail loudly when a third channel and a second warehouse get added. It keeps running, producing suggestions that look normal and are quietly wrong, because nothing in Cin7 forces a review of those fields when the business changes shape around them.

How Cin7 Actually Builds a Purchase Suggestion

Cin7's MRP engine does not look at your sales history in isolation. It runs through a structured sequence, and a failure in any layer produces a suggestion that looks confident and is wrong.

Run initialization and parameter ingestion

The engine first evaluates the planner's selected horizon and demand vectors before it reads a single physical stock number.

Inventory state evaluation

Only after the demand parameters are set does the engine pull live Stock on Hand, Allocated and Committed positions, and On Order supply already in the pipeline.

Demand and threshold aggregation

Consumption history is applied against the reorder parameters configured for each product and location.

Supply rule execution and BOM explosion

When the engine identifies a net shortage, it processes that shortage through the explicit priority order of the Supply Rules configured at the location level. Cin7 has no fixed or hardcoded routing hierarchy. Whether a Stock Transfer, a Purchase Order, or a Production Order gets checked first is whatever priority the business has configured for that location, not a default sequence. The MRP run does not execute background orders automatically. It compiles these pathways into Supply Suggestions, and converting a suggestion into a live Draft or Authorized order still requires a planner to select and confirm the line. If the shortage routes to a Purchase Order, the suggested quantity references the thresholds set in the Locations and Bins reference book under the Supply Rules tab, or the Reorder Levels tab on the individual product card, not a single global default.

If BOM Explosion is left disabled on a nested bill of materials, this component level deconstruction is skipped for standard production tracks. The engine will not identify a sub assembly shortage unless the product uses an auto assembly or auto disassembly bill of materials, which is the one built in exception to the toggle. Outside that exception, the engine has no idea a sub assembly is short, because it never asked.

Outcome

The result is a set of Supply Suggestions, plus an errors tab most planners never open, all still waiting on a planner to convert them into live orders.

Consider a finished good assembled from three sub components at two warehouse locations. If the Locations and Bins reference book at one warehouse still carries a Minimum Before Reorder threshold set for launch volume from a year ago, that location will generate a supply suggestion completely disconnected from current velocity, even though the other location's suggestion looks correct. Nothing about the sales data explains that gap. The gap sits entirely in a threshold field nobody has opened since implementation.

Locating which layer broke, not re cleaning the sales data, is what fixes the suggestion. A planner who does not know the sequence exists will keep pulling the same lever, re exporting and re importing sales history, while the actual break sits three layers downstream in a supply rule priority or a reorder threshold field.

The Six Ways This Breaks, Even With Clean Data

Six configuration and logic points, confirmed by direct SME review, can each independently produce a wrong suggestion.

These patterns rarely show up one at a time. A business running multichannel consolidation while also carrying static reorder points on its oldest SKUs is compounding two failures in the same MRP run, and the resulting suggestion can be wrong in two directions at once, understating one product while overstating another. Reviewing them individually is how a diagnostic finds the actual combination at play in a specific account, rather than assuming only one pattern applies.

Why Would Cin7 Say We Need to Reorder When We Already Have Enough Stock?

Authorizing a sales order moves that stock into Committed or Allocated status immediately, regardless of when it actually ships. During a busy season, a backlog of authorized but unshipped orders holds allocation across dozens of SKUs at once. A planner running an MRP sweep sees Available quantity drop and reads it as a genuine consumption signal. It is not. It is a paperwork queue, not a warehouse shortage.

This is exactly the kind of pattern that gets misdiagnosed as a data problem, because the numbers on the screen are technically accurate. The stock really is Allocated. What is missing is the context that Allocated does not mean shipped, and a planner who does not separate the two will keep authorizing reorders the warehouse does not need.

Misreading the Symptom as the Cause

When a purchase suggestion is wrong, the first assumption is almost always that the sales history behind it must be wrong. That assumption sends teams back into data cleanup projects that never touch the actual break.

Allocation logic holding stock against authorized but unfulfilled orders reads to a planner as a real drop in available stock, prompting an unnecessary reorder. A cold start SKU with three months of history can produce a confident, wrong forecast even when every other product in the catalog is behaving normally. A nested bill of materials with BOM Explosion switched off will keep suggesting finished goods purchases while quietly ignoring a shortage in the sub component two levels down. None of these are data problems. Each one is a configuration or logic layer doing exactly what it was set up to do, on a business that has outgrown that setup.

The pattern that causes the most wasted hours is a planner discovering one wrong suggestion, assuming the whole data set is unreliable, and re auditing every SKU in the catalog to find a problem that only ever existed in a handful of configuration fields. That audit consumes a full planning cycle and rarely finds anything, because the sales data was never the layer that broke.

What Happens Downstream When These Points Go Unreviewed

Overstock, stockouts, working capital strain, and a ledger that stops matching the warehouse all trace back to the same six unreviewed configuration points.

The pattern is consistent. Planners stop trusting suggestions they cannot explain, so they move planning into a spreadsheet. Purchase invoices get coded straight into the general ledger in QuickBooks Online or Xero to hit a deadline, bypassing the Cin7 sub ledger entirely. At month end or year end, the physical Inventory Movement Summary report asset valuation does not match the general ledger control accounts, because one of them was never updated by the actual purchasing activity. Planners can trace the exact transactional friction behind that mismatch with the Transactions vs Stock On Hand Difference Report, which surfaces the specific unposted journals and open paperwork gaps hiding beneath the ledger. The finance team is left posting a manual plug journal to force the balance sheet to close, and that journal obscures the real shrinkage and distorts gross margin reporting for every product line it touches.

Manual journals correct the balance sheet. They do not correct the configuration that caused the mismatch, and they make the real gap harder to find the next time. Each cycle this repeats, the plug journal grows a little, and the confidence the finance team has in the inventory asset value on the balance sheet shrinks a little more. By the time someone asks why gross margin looks worse than it should on a specific product line, the configuration break causing it is several quarters old and buried under a stack of prior adjustments.

Find Out Where Your Plan Is Actually Breaking

If purchase suggestions in Cin7 have stopped matching what your team sees on the warehouse floor, the sales data is usually not the problem. Reorder parameters, lead times, allocation logic, and BOM explosion settings configured at implementation rarely get revisited as a business adds channels and SKUs. A configuration review identifies exactly which of the six points is driving the gap, and what needs to change before your next planning cycle runs.

The Fiskal Cin7 Configuration and Operational Diagnostic Review looks at:

Reorder parameters, lead times, and allocation logic against current business reality, not implementation era defaults
Which SKUs are still cold start and should not be sitting on fully automated forecasting yet
BOM explosion and supply rule settings across multi level manufacturing and assembly

The Real Takeaway

Clean data does not explain why Cin7 keeps getting purchase suggestions wrong. Six specific, nameable configuration and logic points do, and each one can be identified and corrected without touching the sales history at all. This is not a data problem. It is a configuration problem, and it is the kind of problem a targeted diagnostic review finds in days, not months.

The next time a suggestion looks wrong, the first question worth asking is not whether the sales data can be trusted. It is which of the six configuration points has not been reviewed since the business looked different than it does today.