Cin7's MRP feature suggests a purchase order that does not match what you actually need. Too much of something you already have. Too little of something you are about to run out of. The instinct is to blame the feature.

That instinct is usually wrong.

TL;DR

• Cin7's MRP calculation logic is mechanically sound. Wrong suggestions usually trace to upstream data, not a broken feature.

• Five confirmed patterns cause this: stalled sales order allocation, locked accounting periods blocking cost sync, BOM data drift, GRNI or GINR clearing account cutoff issues, and peak volume API sync lag.

• Each pattern has a distinct, checkable trigger.

• Ignoring the real cause leads to cash tied up in excess stock, stockouts, or margin distortion. It is not just an annoying feature

• The fix is diagnosing which upstream layer is at fault, not reverting to manual purchasing or blindly trusting the suggestion.

How Do You Know If It Is a Data Problem, Not a Broken Feature?

Fiskal has observed the planning loop execute across five distinct operational stages every time it runs. Quantity snapshot, demand processing, BOM explosion, error checks, suggestion. It runs this sequence regardless of whether the inputs feeding it are trustworthy. That single fact explains almost everything else in this article, so it is worth sitting with before going further.

Before assuming feature failure, check the Errors section of the MRP run. Cin7 surfaces Information, Warning, and Critical entries directly on the individual run page once a calculation completes. These entries often name the exact input the calculation flagged as unreliable before it ever produced a number. Most teams never open this section until something has already gone wrong downstream, an over order or a stockout, at which point the diagnostic trail is harder to reconstruct.

There is also a pattern in the timeline worth checking. If suggestions were accurate before and started drifting as order volume or complexity grew, the more likely explanation is upstream data drift, not a system defect that appeared out of nowhere. A feature does not usually degrade gradually on its own. Data quality does, particularly as more sales channels, more SKUs, or more order volume place pressure on the manual processes that used to keep stock, cost, and sync data aligned.

MRP is not claimed to be broken anywhere in this article. The calculation sequence itself is intact and has been confirmed to run correctly on the inputs it is given. What changes over time is the quality of what feeds it, and that is where the diagnostic effort belongs. Treating this as a feature problem points toward disabling MRP, adjusting settings that were never the cause, or escalating a support ticket that will likely confirm the calculation is working as designed. Treating this as a data problem points toward the Errors section and the five patterns below, which is where the actual answer tends to live.

The Root Cause Sits Upstream of the Calculation

The perception is simple. The feature used to work and now it does not, so the feature must be broken. That is the natural conclusion when a system that used to feel reliable starts producing suggestions that visibly do not match reality.

The reality is less simple and more useful. The calculation logic has not changed. What has changed is the stock, cost, or sync data the calculation depends on. MRP will always output a suggestion. It has no built in way of knowing whether the numbers it was handed were correct, current, or complete. It treats every input as equally trustworthy, because trustworthiness is not something the calculation is designed to test.

There are five distinct upstream patterns that commonly cause this drift. Each one has been confirmed against a specific, checkable trigger, not a vague description of things generally going wrong. None of them are a defect in the MRP feature itself. All five can exist at the same time in the same account, which is part of why the wrong suggestion is often blamed on the wrong layer. A team that fixes an obvious sync error might still see distorted suggestions weeks later, because a second and unrelated pattern was quietly active the entire time.

This is also why generic fixes tend to underperform. Adjusting a reorder point or a planning period setting can mask a symptom for a short period without addressing which of the five upstream layers actually produced the distortion.

The Planning Loop Runs a Fixed Sequence. It Cannot See Whether Its Inputs Are Trustworthy

Cin7's MRP calculation moves through the same sequence every time. Fiskal refers to this as the Upstream Distortion Chain, our own diagnostic model for describing the loop, not an official Cin7 term. Quantity snapshot, to demand processing, to component explosion, to error checking, to suggestion generation. Each stage hands its output to the next stage without re checking the stage before it.

Quantity Snapshot

Demand Processing

Component Explosion

Reads physical stock on hand minus live allocations across the locations selected for the calculation. This is the stage most sensitive to stalled sales orders, because allocation is subtracted here before demand is even considered.

Reads historical sales velocity alongside authorized sales order timelines. This stage assumes the sales history it is reading reflects genuine, fulfilled demand rather than orders that are technically open but not actually moving.

Explodes bills of materials against static supplier lead time fields set in product records. If those fields were accurate a year ago but have not been reviewed since, the explosion inherits that staleness without flagging it.

Error Checking

Surfaces Information, Warning, and Critical entries in the Errors section of the run, visible directly on the individual MRP run page once calculation completes. This is the one stage built specifically to surface a problem, and it is also the stage most teams skip past.

Suggestion Generation

Produces a Purchase, Transfer, or Production Order suggestion whether or not the stages feeding it were accurate. The output looks identical whether every upstream stage was clean or every upstream stage was distorted. Nothing in the suggestion itself tells you which.

That last point matters more than any other in this article. MRP does not pause and ask whether its inputs look reasonable. It calculates and it outputs. Reliability is not something the feature checks for you. It is something that has to be checked upstream, stage by stage, before the suggestion is trusted or discarded.

The Five Patterns Behind a Wrong MRP Suggestion

Each pattern below has its own trigger. Diagnosing which one is active starts with identifying the symptom, not guessing at a fix. In practice, more than one pattern is often live in the same account at once, so ruling patterns in or out one at a time is the more reliable approach than assuming a single cause.

The Allocation Anchor is often the easiest of the five to check first, because it shows up directly in the quantity snapshot layer. A sales order that has sat open without progressing through picking, packing, or shipping is still holding allocation against stock that, functionally, is not moving anywhere. MRP reads that held allocation as unavailable stock, which quietly suppresses the available quantity feeding the calculation.

This pattern applies to any connected storefront or enterprise sales channel, not only direct to consumer orders. For wholesale operations running a connected system like Prospect CRM, an order pushed to the back office lands as a sales order in draft status. Whether that draft holds a stock reservation or leaves it fluid depends entirely on whether Cin7 is configured to auto authorize incoming external transactions, which is worth checking alongside the order itself.

Cost Adjustment Lockout behaves differently, because the distortion sits in the connected accounting system rather than in Cin7 itself. Early lock dates in QuickBooks Online or Xero actively block Cin7 from adjusting old ledger entries when inventory values change. When a vendor bill price adjustment comes in, Cin7 runs a set sequence: it cancels the initial asset journal entry and replaces it with a revised version reflecting the true landed cost. If that adjustment hits a locked accounting period, it does not fail silently. It generates an explicit API sync error on Cin7's synchronization dashboard, stopping ledger processing until someone intervenes manually. This behavior is identical whether the connected platform is QuickBooks Online or Xero. The cost layer feeding MRP then continues running on a figure that no longer reflects what was actually paid, until that error is resolved.

BOM Data Drift tends to build slowly rather than appear all at once. Supplier lead times that were accurate when first entered rarely get revisited once the product is live. Substitutions get made in practice without being reflected in the bill of materials. Wastage factors that were once estimated get left unrevised for years. Each of these individually looks small. Stale vendor lead times and un updated material wastage metrics directly cause delayed material planning runs, changing when and how much the component explosion stage decides to reorder.

The diagnostic approach differs depending on the product type. Kitted products rely on standard auto assembly logic, and component shortages surface through the Out of Stock Components for Auto Assembly report. Advanced manufacturing explodes multi tier production tasks against labor and machinery capacity as well as materials, and shortages there are tracked through the Production Run Shortage report instead. Checking the wrong report for the product type in front of you is a common reason this pattern goes undiagnosed.

The GRNI / GINR Cutoff Gap shows up when open purchase orders sit in the Goods Received Not Invoiced or Goods Invoiced Not Received clearing accounts without a clean period cutoff. These are mapped under Settings, Reference Books, Account Mapping in Cin7 Core. Financial reports and inventory reports are, in effect, reading two different timelines of the same transaction, and MRP inherits whichever version of that timeline it is pointed at.

Sync Interval Lag is the pattern most likely to surface specifically during peak trading. Under normal order volume, the API connection between Cin7 and a sales channel like Shopify or Amazon keeps pace comfortably. Under peak volume, that same connection can fall behind, and the quantity snapshot briefly shows more available stock than actually exists, right at the moment when demand signals matter most.

Because supply rules, logistics paths, and inventory buffers are configured on a per location basis, this distortion does not affect the general ledger uniformly. A high velocity retail fulfillment center can hit real time stockout exceptions during a traffic spike while a standard B2B warehouse in the same account remains entirely unaffected, which is why checking one location's sync status is not enough to rule this pattern out.

Two Ways Teams Get This Wrong, and Both Skip the Actual Diagnosis

Neither response is unreasonable on its face. Reverting to manual purchasing feels safer in the short term, because a person is now reviewing every number instead of a system. Blind trust feels efficient, because the whole point of automating MRP was to stop reviewing every number by hand.

Both responses skip the one step that actually resolves the problem, which is identifying which upstream layer is distorted before changing how you buy. Manual purchasing does not fix the Allocation Anchor sitting in the background. Blind trust does not notice a Sync Interval Lag until stock physically runs out. The diagnostic step is the only one of the three options that actually addresses the cause rather than working around the symptom.

There is also a longer term cost to picking either extreme repeatedly. A team that reverts to manual purchasing every time a suggestion looks wrong never builds the internal habit of checking the Errors section on the MRP run, so the underlying pattern stays in place indefinitely. A team that trusts every suggestion without question loses the early warning that a distortion is even present, since nothing in the output itself signals that something upstream has drifted.

What a Healthy Baseline Looks Like

None of these targets are a guaranteed state reached once and kept forever. They are a standard to maintain on an ongoing basis, not a box to check and move on from.

Alongside these targets, a few habits protect the baseline over time. Purchase order releases should not run on full automation without human review, since that review often catches a distorted suggestion before it becomes a real order. Manual journals should not be used to force inventory figures into agreement with the balance sheet, since a forced match hides the gap rather than closing it. Purchase order costs should not be altered after the accounting period around them has locked, since that is exactly the condition that produces a Cost Adjustment Lockout in the first place.

Maintaining this baseline is less about a single project and more about a recurring discipline. A zero error sync screen checked once means little if it is not checked again the following month.

The Cost of Guessing Instead of Diagnosing

Following a distorted MRP suggestion without checking its source has a real cost, and it shows up in more than one place at once.

Working capital ties up in excess stock ordered against a misaligned base. Cash that could have funded other operational priorities sits instead on a warehouse shelf, purchased in response to a suggestion that was never actually accurate. Component or peak period stockouts follow from under ordering when the stock signal was distorted in the other direction, often at the exact moment demand is highest and the cost of being wrong is greatest. Manual journal corrections used to force a match compound the misalignment rather than resolving it, feeding the same distorted data back into the next MRP run and starting the cycle over again.

Each of the five patterns above traces to one of these outcomes, though rarely to only one. Allocation and sync lag distortions tend to show up first as stockouts or excess stock on the shelf. Cost lockouts and timing gaps tend to show up first as balance sheet discrepancies and profitability distortion from plug entries used to force agreement. Left unresolved long enough, the combined effect can undermine a rolling cash flow forecast, because a forecast is only as reliable as the inventory and cost data feeding it, and that data has already been shown to be unreliable at the source.

The resolution is not reverting to manual purchasing, and it is not blind trust in the next suggestion. It is diagnosing which upstream layer, allocation, cost sync, BOM, timing, or channel lag, is actually at fault, and treating that as the starting point rather than the last resort.

Which Pattern Is Actually Behind Your MRP Suggestions?

Cin7 MRP suggestions are only as reliable as the allocation, cost, BOM, and sync data feeding them. Five distinct upstream patterns commonly break that reliability, and more than one can be active at once.

If your Cin7 MRP suggestions have stopped matching what your business actually needs, the issue is often upstream of the calculation itself. A Fiskal Systems Health Check can trace the specific pattern behind it, whether that is allocation, cost sync, BOM data, or channel timing, before you change how you purchase.

The Suggestion Is Not the Problem. What Feeds It Is

The MRP calculation sequence itself is not the point of failure in most reported cases. Each of the five patterns covered here has a distinct trigger that can be checked directly, starting with the Errors section on the MRP run rather than with the settings screen.

The financial and operational consequences of ignoring this are specific, not generic system complaints. Cash tied up in excess stock. Stockouts during a peak period. A cash flow forecast built on numbers that were never reliable to begin with.

This is not a broken feature. It is an upstream data problem wearing an MRP suggestion as its symptom.

Need Support With Your Cin7 and Xero or QuickBooks Integration?

Learn how Fiskal supports post-go-live Cin7 and Xero or QuickBooks environments.

Where close stability, reconciliation clarity, and integration governance require structural alignment.

📞 Or call us directly: (954) 415-7895

Share on your socials.

Services:
Bookkeeping
Controlling
FP&A

Company:
About us
Contact Us
Careers

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

Resources
Blog
Privacy Policy

Products:
Cin7 Implementation
Cin7 Support