In short: The ERP vs planning system boundary is a set of decisions about which system owns each piece of information, and the arguments happen wherever nobody made the decision explicitly. An ERP records what happened and what is committed, while a planning system computes what should happen next, which is why versions and scenarios belong on the planning side. For contested parameters such as safety stock, the workable arrangement is to compute the value in the planning system, write it to the ERP for execution, and specify that write back rather than assume it. A write back specification needs an override policy and a conflict rule, because manual overrides accumulate silently and the accumulation is measurable.
The argument is always about the same field. Somebody has computed a safety stock in the planning system and wants it in the ERP so that the MRP run uses it. The ERP team says the field is theirs and points at four years of manual values in it. The planning team says the manual values are the reason nobody trusts the output. Both are right about their own system and neither has written down what happens when they disagree.
That single field is a useful entry point into the larger question. The boundary between an ERP and a planning system turns out to be a set of decisions about which system owns each piece of information, and the ones that cause trouble are always the ones nobody made explicitly.
Two different jobs
An ERP records what happened and what is committed. A planning system computes what should happen next. Those are different jobs with different requirements, and the requirements explain most of the architectural differences between the two.
Recording requires transactional integrity, auditability, and a single current value for every field. There is exactly one on-hand balance for an item at a location, and if two processes disagree about it, one of them is wrong.
Computing requires the opposite in several places. A planning system needs multiple simultaneous versions of the same quantity, because a scenario is a different answer to the same question. It needs to hold a value that is deliberately provisional. And it needs to recalculate large sets of numbers quickly, which is a different performance profile from processing individual transactions correctly.
Those two sets of requirements pull in opposite directions, which is why the products are built differently and why trying to do all the planning inside the ERP tends to produce something slow and inflexible, while trying to hold transactional truth in the planning system produces reconciliation work forever.
The version problem is the concrete form of that difference
The abstract point above becomes concrete the first time somebody asks for a scenario. A record system holds one current value per field, so representing an alternative version of the future means either copying the whole dataset or adding a version key to every table that participates.
Size what that costs. A planning dataset of 40,000 item-locations over a 104-week horizon with 20 measures is 83.2 million values. Holding four alternative scenarios by copying takes you to 416 million. A planning system built for this stores scenarios as overlays, holding only the cells that differ from the base, so a scenario that changes 3 percent of the cells costs 2.5 million values rather than 83.2 million. That is a factor of thirty-three on storage and a similar factor on the time taken to create a scenario.
The reason this matters organisationally rather than technically is that when creating a scenario takes an hour, people stop creating them, and the planning process quietly becomes single-threaded. B4 covers what a scenario has to do to be worth running at all.
What clearly belongs where
Some assignments are uncontroversial and worth stating so the contested list is shorter.
The ERP owns master data creation, transactional records, inventory balances, purchase and sales orders, production orders, financial postings and anything with a legal or audit obligation attached. If a regulator or an auditor might ask for it, it lives in the system of record.
The planning system owns forecasts, plans, scenarios, planning parameters as calculated values, the assumptions behind a plan, and the reasoning trail that connects an input to a recommendation. If somebody might ask why a number is what it is, that explanation lives in the planning system.
The list of things that sit in between is short: safety stock and reorder points, planned orders, available-to-promise and allocation, and bill of materials effectivity. Those four cause almost all the arguments.
The rule for the contested middle
For each of the four, the workable arrangement has the same shape. The value is computed in the planning system, written to the ERP for execution, and the write-back is specified rather than assumed.
Safety stock and reorder points. Computed in planning, because the calculation needs demand variability, lead time distributions and a service target, none of which the ERP holds properly. Stored in ERP, because MRP reads them there. The specification needs a refresh cadence, an override policy and a rule for what happens when a planner edits the ERP value directly.
Planned orders. Generated in planning, converted to firm orders in ERP. The boundary here is a horizon rather than a system: inside the firm window the ERP owns it, outside it the planning system does, and the window has to be stated per item or per category rather than globally.
Available to promise and allocation. This one depends on the answer's required latency. A promise given to a customer on a live call needs a synchronous answer against current commitments, which pushes it towards the ERP or towards a service with live access to it. A weekly allocation of constrained supply across customers is a planning calculation. I7 covers what a promise date needs to be defensible.
Bill of materials effectivity. Engineering owns the structure in the ERP or the PLM system. Planning frequently needs a different version of it, aggregated or simplified, and the two diverge. Hold the planning BOM as a derived object with a documented transformation rather than as a separately maintained copy.
The common shape of the failure across all four is the same. Somebody needs a value the other system does not provide, builds a local copy to get moving, and the copy outlives the reason for it. Six months later two systems hold different numbers for the same thing and both are being used. The defence is to insist that every derived copy has a documented derivation and a scheduled refresh, so that a copy which stops matching its source raises an alert rather than quietly diverging.
Specify the write-back properly
Most integration specifications describe the payload and the schedule and stop. A parameter write-back needs four more things, and their absence is what produces the arguments.
An idempotency key. The same write applied twice should leave the same state. Without one, a retry after a partial failure produces duplicates or double-applied changes.
An effective date. A parameter change that takes effect immediately will affect an MRP run that is mid-cycle. Effective dating lets the change land at a known boundary.
A change reason. Every written value carries the identifier of the calculation and the version that produced it. When somebody asks in March why a reorder point moved in January, this is the only thing that answers them.
A reversal path. A specified way to restore the previous value, tested before go-live. This is the part people leave out and the part that matters at three in the morning.
AA6 covers the integration patterns themselves and how each behaves when a source restates history.
The drift arithmetic
The reason the override policy matters is that manual overrides accumulate silently, and the accumulation is measurable.
Take 60,000 item-locations with safety stock recomputed monthly. Suppose planners override 8 percent of the values in a given month, for good reasons at the time: a known supply issue, a promotion, a customer commitment. That is 4,800 overrides. If overrides have no expiry, then next month's calculation writes to the other 55,200 and leaves the overridden ones alone, and another 8 percent of the remainder get overridden.
After twelve months, the proportion of item-locations still under system control is 0.92 to the twelfth power, which is 0.368. So roughly 63 percent of your parameters are frozen at a manual value set for a reason that expired months ago, and the planning system is computing values for the third of the estate that nobody has touched. The output looks like a functioning system. It is governing a shrinking minority of the decisions.
The fix costs nothing structurally. Every override carries an expiry date, defaulting to something short like 90 days, after which the value returns to system control unless renewed. Add a monthly report of the override count and the share of the estate under system control, and the number stops drifting because somebody is looking at it. P3 covers what happens to replenishment parameters nobody has revisited since go-live.
Who is authoritative when they disagree
The last piece is a decision rule for conflict, and it should be written before the first conflict.
The version that works in practice has three parts. Name a single owner per field, by field rather than by system, so that the question of who decides has an answer. State the direction of authority for each contested field explicitly, including the conditions under which it reverses. And define what happens to the ERP value when the planning system is unavailable, because a batch that does not run should leave the last good value in place rather than writing a default.
That third point catches people. A write-back process that fails silently and leaves a stale parameter is a mild problem. One that fails and writes a zero, or writes the default from a blank record, is a serious one, and the difference is a few lines of validation on the receiving side.
The limit
The clean assignment above assumes your ERP is one system. Many businesses run several, from mergers or from regional autonomy, and the planning system then sits above a set of records that disagree with each other about item codes, units of measure and customer identity. Resolving that is a prerequisite rather than a planning problem, and T3 covers the entity resolution part of it. Z6 covers what happens when the disagreement arrives through an acquisition.
The write-back specification also assumes the ERP will accept parameter updates at the volume and cadence you need. Some will not, either because of an interface limit or because of a change control process that treats a parameter update as a configuration change. Find that out during design rather than during testing, because the workaround, which is usually a slower cadence, changes what the planning calculation can sensibly do.
And there is a genuinely undecidable case worth admitting. Where a business runs a single site with simple products, stable demand and a capable ERP planning module, the boundary question may not be worth answering, because the ERP's own functionality is adequate and adding a second system adds interfaces without adding decisions. The threshold is roughly where the number of item-locations, the variability of demand, or the need to compare scenarios exceeds what a planner can hold in their head, and that threshold is a judgement rather than a number.
Start by listing the four contested fields for your own estate and, for each one, writing down who owns it, what refreshes it, how often, and what happens to a manual override. Four lines. Most organisations discover while writing them that at least one field has no owner at all, which is why it drifted.