If you are searching for why Cin7 MRP is not working, the issue may not be that MRP is broken.

It may be that the system is calculating from inputs your team does not trust.

That distinction matters.

MRP in Cin7 Core is not an automatic buying system. It does not replace purchasing judgement, production planning, or inventory governance. It takes the data, rules, dates, stock positions, lead times, BOMs, and run parameters available to it, then turns those into suggested actions.

If the inputs are wrong, incomplete, stale, or misaligned, MRP can calculate precisely and still produce a plan that is commercially wrong.

That is why many businesses pay for MRP, but still plan in spreadsheets. They have the module, but not the planning foundation needed to use it properly.

TL;DR: Why Cin7 MRP Feels Like It Is Not Working

Cin7 MRP is a planning engine, not an automatic purchasing system.

It depends on location-level reorder logic, Supply Rules, stock accuracy, Required by Dates, lead times, BOM settings, forecast inputs, and run parameters.

If those inputs are wrong, MRP can still calculate correctly from the data it has, but the plan it produces may be wrong for the business.

ForesightAI and forecasting help predict possible future demand. MRP uses demand and supply inputs to suggest what to buy, transfer, assemble, or manufacture.

If your team still plans in spreadsheets, the issue may not be the module alone. It may be system trust, setup, governance, or adoption.

Why Is Cin7 MRP Not Showing the Suggestions You Expected?

Cin7 MRP may not show the suggestions your team expects when the system does not have the right planning foundation.

Common causes include missing Supply Rules, incorrect location-level reorder setup, excluded sales order demand, incomplete Required by Dates, stale active runs, incorrect supply settings, or BOM Explosion not being selected where multi-level component planning is required.

In some cases, the module is not “wrong.” It is doing what the inputs and parameters allow it to do.

For example, if demand exists at a location but the system does not have a valid Supply Rule for that product and location, Cin7 does not have the instruction it needs to suggest how the demand should be supplied. The issue is not just that the system failed to generate a suggestion. The issue is that the planning rule was missing from the operating model.

That is the bigger pattern behind many MRP problems.

The output looks like an MRP issue, but the source is often setup, workflow, data quality, timing, or governance.

MRP Is Not the First Planning Layer

A common mistake is treating MRP as the beginning of planning maturity.

It is not.

MRP is usually a Phase 2 optimization layer. It works best after the business has already stabilized the basics:

• Product setup

• Location logic

• Supply Rules

• Stock accuracy

• Supplier lead times

• Reorder levels

• Required by Dates

• Open purchase orders

• Transfers

• Assemblies

• Production records

• BOMs

• Forecast assumptions

• Team planning discipline

If those are unstable, MRP does not magically clean them up. It exposes them.

That is why a company can pay for MRP and still have buyers working from spreadsheets. The team is not necessarily resisting the software. They may have learned that the system output cannot be trusted.

At that point, spreadsheets become the shadow planning system. They reduce short-term uncertainty, but they also hide the deeper issue: Cin7 is no longer the single source of truth for replenishment planning.

The MRP Readiness Chain

A useful way to understand Cin7 MRP is through the readiness chain:

Product setup → Location reorder logic → Supply Rules → Demand inputs → Stock accuracy → Lead times → BOM / production settings → MRP run parameters → Suggested actions

MRP output sits at the end of this chain.

That means poor suggestions usually start upstream.

If product records are incomplete, the plan is weaker.

If reorder logic is global when the business needs location-level planning, the plan is weaker.

If Supply Rules are missing, MRP cannot suggest the expected supply action.

If Required by Dates are missing or wrong, demand may fall into the wrong planning window.

If supplier lead times are blank or zero, the system may assume unrealistic delivery timing.

If stock-on-hand is wrong because warehouse receiving is delayed, MRP starts from a false inventory position.

Available stock is only as reliable as the stock-on-hand and allocation data feeding it.

If BOM Explosion is not selected when multi-level component planning is needed, nested component requirements may not appear as expected.

This is why MRP should not be reviewed in isolation. It is downstream of the operating model.

The Setup Problems That Make MRP Output Untrustworthy

Some MRP issues are highly specific to Cin7 Core configuration.

They should not be treated as generic “bad data” problems.

1. Location-level reorder logic is not set correctly

For localized MRP planning, the setting under Settings → General Settings → Purchase process customisation → Minimum Before Reorder must be set to Each location.

If reorder logic is evaluated globally instead of by location, MRP can miss the reality of where demand exists and where stock is actually needed.

This matters because most growing product businesses do not operate as one single pool of stock. They have warehouses, retail locations, 3PLs, production locations, transfer flows, or channel-specific stock requirements.

If the planning logic is not location-aware, the recommendations will not match how the business actually operates.

2. Supply Rules are missing or misconfigured

Supply Rules tell Cin7 how a product should be supplied for a specific location.

If a product lacks a Supply Rule for the location experiencing demand, MRP cannot provide the expected suggestion for that product and location.

This can create what looks like a “ghost suggestion” problem: demand exists, but MRP produces no useful purchasing, transfer, assembly, or production suggestion.

The team sees open demand and assumes MRP is broken. In reality, the system may not know how that demand should be fulfilled.

3. Required by Dates and planning periods are wrong

Cin7 Core only permits one active MRP run at a time across the account.

If a previous run is left in draft, active, or incomplete status, the team may not be able to generate a fresh replenishment plan. That can leave buyers working from stale planning data, especially if different users are running MRP without a clear review and completion process.

This is not just a technical lockout. It is a planning governance issue. If old runs are not completed, deleted, or controlled, MRP can stop reflecting the current state of demand and supply.

MRP also should not be treated as a live, self-refreshing planning board. Recalculate can update parameters, but Scheduler data does not dynamically refresh as days pass. If the team is relying on an old run, the planning view can become stale unless MRP is re-run and reviewed against current demand, stock, and supply data.

4. An old MRP run is still active

MRP depends heavily on timing.

If Sales Orders have missing, generic, or mismatched Required by Dates, demand may not fall into the expected planning window.

Past-due sales order demand also needs careful handling. When MRP is being run strictly against active sales order demand, and automated inventory threshold replenishment is not the basis of the run, leaving Include past due demand unchecked can mean older unfulfilled demand is not included in the way the team expects.

This caveat matters because Cin7 can still factor past-due demand into availability calculations when procurement settings such as Minimum Before Reorder or Stock Level are used. The risk is highest when the team assumes all overdue sales demand is automatically included in a run without checking how the MRP parameters and procurement settings are being applied.

The team may think MRP has reviewed all demand, when the run logic is narrower than expected.

5. Supplier lead times are blank or unrealistic

MRP run parameters can include or exclude draft and planned supply records.

Both choices can create issues if the team does not govern them properly.

If draft or planned supply is excluded, MRP may suggest buying more than needed.

If draft or planned supply is included, but those records are not actually authorized or likely to happen, MRP may assume inbound stock that never arrives.

That is how “ghost inbound stock” creates under-purchasing. The system believes supply is coming. The warehouse does not receive it. The team only sees the problem when fulfilment or production pressure hits.

6. Draft and planned supply are not governed

If supplier lead times are blank or zero, MRP may assume stock can arrive immediately.

That can make the suggested order date appear too late, because the system is not calculating against a realistic supply timeline.

This is where the output can look clean on screen but fail operationally. The suggestion exists, but it does not reflect real supplier behaviour.

Why Demand Planning Feels Inaccurate Even When the Forecast Exists

Demand planning and MRP are connected, but they are not the same thing.

A useful distinction is:

ForesightAI / forecasting is the predictive brain.

It looks backward at sales history and related demand patterns to project what future demand might look like.

MRP is the execution architect.

It takes current demand, open orders, live stock, forecast snapshots, Supply Rules, lead times, reorder logic, BOM settings, and run parameters, then turns those into suggested actions.

When users merge those two ideas, expectations break.

Forecasting is not the same as a purchase plan. A forecast may estimate demand, but MRP still needs accurate supply rules, stock balances, locations, dates, lead times, BOMs, and run settings to turn that demand into useful action.

Demand planning can also feel inaccurate when the sales history is not a clean representation of real demand.

For example:

• A one-time B2B bulk order can inflate baseline demand.

• A promotional spike can make future demand look stronger than normal.

• A stockout period can make demand look weaker than it really was, because sales history only reflects what the business could sell.

• New SKUs may not have enough history to forecast reliably.

• Supplier lead times may have changed, but the planning data has not been updated.

• Channel mix may have shifted, making older sales history less useful.

ForesightAI also has its own prerequisites. It requires at least six months of continuous sales history in Cin7 Core before it can produce useful projections, and it requires the relevant active subscription add-on.

That means forecast outputs should not be treated as instant operational truth or as a replacement for planning review.

If your team adjusts forecasting assumptions and immediately expects MRP to behave differently, the timing and availability of those updated forecast inputs still need to be checked before acting on the next planning run.

The BOM Problem That Causes Nested Component Blindness

MRP gets more sensitive when production, assembly, and multi-level BOMs are involved.

A business may plan finished goods and immediate components correctly on the surface, but still miss lower-level raw materials inside nested sub-assemblies.

This often happens when BOM Explosion is misunderstood.

If BOM Explosion is not selected during the relevant MRP run, Cin7 can still plan the parent item and its immediate first-level components. What it will not do is decompose nested sub-assemblies or lower-level BOM structures in the way the team may expect.

The result is nested component blindness.

The parent item appears planned. The first-level component may be included. But the raw materials inside that component’s own BOM may not be surfaced for purchasing or transfer.

This is especially risky in more complex production environments where BOMs contain sub-assemblies, nested components, or Phantom BOMs.

A Phantom BOM should be handled carefully. In Cin7 Core, a Phantom BOM explodes an auto-assembled component directly into the parent component list without creating a separate standalone assembly order.

For complex manufacturing, the safer planning process may involve two stages.

First, run MRP without BOM Explosion to create a Master Production Schedule in Planned status and review resource availability through the Capacity Planner.

Then, run a second MRP with BOM Explosion to trigger purchasing and transfer requirements for the underlying nested components.

The point is not that every business needs this exact workflow. The point is that production planning needs to match the complexity of the BOM structure. If the team expects multi-level component planning but runs MRP without the settings needed to decompose nested BOMs, MRP output will not match reality.

Why Spreadsheets Become the Shadow Planning System

A clean sync queue can create false confidence.

The team sees no visible errors. Operations reports that the sync queue is clear. Leadership assumes the integration is healthy.

But if failed records were manually skipped, the queue may only be clean because the exceptions were removed from view.

This is especially risky under consolidated workflows, where one skipped failed block may represent far more than one transaction.

It is also risky when a consolidated period has been split into multiple 500-line chunks.

If one chunk succeeds and another is skipped, the accounting system receives a fractured version of the day or month.

The problem usually appears later.

Finance may find missing revenue during reconciliation. Payments may not tie to the expected invoice object. Stock on Hand may not agree with the general ledger. Gross margin may look wrong because COGS and revenue did not land together.

At that point, teams often start patching the issue inside Xero or QuickBooks Online.

They post manual journals. They adjust payments. They correct balances. They try to make the report look right.

But those patches do not fix the original source record in Cin7 Core.

Manual correction may reduce immediate reporting pain, but it can also decouple accounting from the operational system.

That is the real danger.

The system no longer has one clean version of the truth.

What a Healthy Cin7 Core Sync Queue Process Looks Like

When MRP is not trusted, teams do not stop planning.

They plan somewhere else.

Usually, that means spreadsheets.

A spreadsheet may start as a temporary check. Then it becomes the buyer’s “real” planning tool. Then production starts relying on it. Then leadership reviews a spreadsheet instead of Cin7. Eventually, the ERP is no longer the planning source of truth.

This is not always a people problem.

Often, the team has adapted to weak system trust.

If MRP suggestions are empty, late, excessive, or disconnected from what the team sees operationally, people will create workarounds. The problem is that those workarounds make it harder to fix the original issue.

Spreadsheets can hide whether the problem sits in Supply Rules, Required by Dates, stock accuracy, lead times, BOM logic, forecast assumptions, or MRP run parameters.

That is why spreadsheet dependency should be treated as a signal.

It usually means the team does not trust the planning system enough to act on it.

What Poor MRP Usage Costs the Business

Underused MRP is not just a software adoption issue.

It affects purchasing, production, cash flow, service levels, and margin pressure.

When MRP is not trusted, the business often buys too much of the wrong stock and too little of the stock it actually needs.

Cash gets tied up in slow-moving products.

Stockouts still happen on high-demand items.

Production can freeze because a small nested component was never suggested.

Wholesale orders can come under pressure because replenishment happened too late.

Expedited freight becomes normal because buying decisions are reactive.

The business is then paying twice: once for the MRP capability, and again for the operational workarounds caused by not using it properly.

The deeper cost is confidence.

If the team does not trust the plan, every purchasing decision becomes a debate. Every production schedule needs manual checking. Every forecast becomes questionable. Every spreadsheet becomes another version of the truth.

That is not optimization. That is planning drift.

How Sales-Channel Timing Can Distort

an MRP Run

Timing can also make MRP output look wrong.

Consider a promotion across Shopify or Amazon.

Order volume spikes. Sales-channel orders, stock updates, fulfilment activity, and integration updates may not all stabilize at the same moment. Some data may be current. Some may still be catching up.

If a manager runs MRP while demand or stock data is still stabilizing, the system can produce a plan based on an outdated operating picture.

The run may look valid, but the timing is wrong.

The result can be under-ordering, over-ordering, or missed urgency. Not because MRP failed as a module, but because the run was executed before the demand and stock picture had settled enough to support a reliable plan.

This is why MRP governance matters.

The question is not only “Did we run MRP?”

The better question is:

“Did we run MRP from a stable, accurate, current version of operational reality?”

What a Healthy Cin7 MRP Foundation Looks Like

A healthy MRP environment does not depend on one perfect setting.

It depends on a maintained planning foundation.

At minimum, the business should be able to trust that:

• Minimum Before Reorder is set to Each location where location-specific planning is required.

• Supply Rules are maintained for the relevant products and locations.

• Stock on hand, allocated stock, open purchase orders, transfers, assemblies, and production records are accurate.

• Required by Dates and planning periods are reliable.

• Past-due demand settings and procurement settings are understood before running MRP.

• Supplier lead times and reorder quantities are maintained.

• BOM Explosion is used correctly where nested component planning is required.

• Forecast inputs are reviewed and adjusted for known business context.

• MRP suggestions are reviewed by a human before purchase, transfer, assembly, or production actions are created.

The goal is not blind trust in the system.

The goal is governed trust.

Your team should understand when to accept an MRP suggestion, when to investigate it, and when to override it because of business context the system does not yet reflect.

That is what mature planning looks like.

Paying for MRP Should Mean Better Planning, Not More Spreadsheet Work

If your team is paying for MRP but still planning outside Cin7, the issue may not be the module.

It may be the foundation feeding it.

MRP can only support better decisions when the inputs behind it are accurate, current, and governed. That includes location reorder logic, Supply Rules, stock accuracy, supplier data, lead times, demand inputs, BOM settings, ForesightAI assumptions, open supply records, and team workflow.

Fiskal helps Cin7 Core users review the planning foundation behind poor MRP output, so they can understand whether the issue sits in setup, data quality, forecasting, BOM logic, integrations, or team adoption.

The goal is not just to make MRP run.

The goal is to make the output useful enough for the business to trust.

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