Solutions For SAP IBP

SAP IBP, loaded from ECC, S/4HANA and everything beside them.

IBP stores planning numbers as key figures at a planning level — product by location by customer by week, say — inside a planning area whose master data must exist first. Where the whole estate is one S/4HANA system, SAP's own integration covers the core. Where it includes ECC, a second ERP, warehouse and 3PL systems or external forecasts, Lima Backbone conforms them to IBP's keys, builds the key figures at their level with the sums checked, loads them on the planning cycle, and returns approved plans to the ERP with every write acknowledged.

Run your first load into SAP IBP Planning integration overview

First load: one dataset, four weeks, fixed price. SAP partner listing pending the certification-tier decision (Q4 2026).

IBP's planning area: master data and compound combinations must exist before a key figure can load; key figures live at a planning level in a time profile and a version. Lima conforms the non-SAP and second-ERP sources to the same keys.

Level-complete

every key figure row carries every attribute of its planning level, or it is held

214,000

Product-Customer combinations derived from history and maintained on the showcase estate

3 ERPs

S/4HANA, ECC and Oracle conformed to one product, location and customer key set

Step 1 · What SAP IBP expects

A planning area with master data first, then key figures at a level

Everything in IBP hangs on the planning level: a key figure is stored against a set of attributes (product, location, customer, week), and the combinations behind those attributes must already exist as master data. That ordering, and the time profile, decide whether a load lands.

Object	What it holds, in plain words	Why the plan needs it	SAP source	Oracle source
Master data types	Products, locations, customers, resources, sources of supply, each with attributes	The building blocks of every planning level	MARA · T001W · KNA1 · CRHD · EORD · MKAL	Items · organizations · customers · resources · sourcing rules
Compound master data	Valid combinations: product at location, product for customer	A key figure row for a missing combination is rejected	MARC (product-plant); product-customer derived from sales history	Item-org assignment; item-customer derived
Key figures	Time series such as actuals, consensus demand, projected stock, capacity, each at a planning level	The numbers the plan is built from	VBRP · LIPS · MARD · KAKO	OE lines · WSH · MTL_ONHAND · resources
Time profile	Days rolling into fiscal weeks, months and quarters	Every key figure lives in a bucket	T009 · T009B	GL_PERIODS
Versions and scenarios	The baseline plan and named scenarios	Keeps a scenario from overwriting the baseline	Tagged by Lima on load	Tagged by Lima on load
Attributes	ABC class, planner, lifecycle status, unit — the fields planning levels are made of	A missing attribute means the row cannot be stored at its level	MARC-MAABC · MARC-DISPO · MARA-MSTAE	Item attributes
Order-based data	Orders and stock for response and supply planning, near real time	Order-level planning	EKPO · VBAP · PLAF · MARD	PO · OE · WIP · MTL_ONHAND (via Lima)
Non-SAP and second-ERP sources	Oracle, warehouse and 3PL stock, external forecasts, point-of-sale	The inputs SAP's own integration leaves out	—	Conformed by Lima to IBP's keys

IBP receives loads through its supported integration channels — batch time-series integration, real-time order integration, and APIs; Lima produces loads for the channel you use.

When SAP's own integration is enough

A single S/4HANA system feeding IBP with standard master data and key figures is what SAP's own integration is built for, and it can stay. Lima adds the layer for ECC as a source, a second ERP, warehouse and 3PL systems, external forecasts, planning master data governed outside the ERP, reconciliation reports per load, and write-back to non-SAP systems.

Step 2 · Where ERP integrations go wrong for SAP IBP

Six places the data breaks, and what it does to the plan

Two of these are IBP's own strictness — planning levels and compound master data — and the rest come from feeding IBP from more than one system.

A key figure row needs every attribute of its planning level demand disappears from the reviewIBP stores a key figure only at its defined level. A sales row with a product and a location but no customer cannot be stored at product-location-customer level; it is rejected or lands at an aggregate, and the demand for that customer disappears from the review.

Compound master data must exist first, and some of it exists nowhere new customers rejectedProduct-location combinations live in the ERP (the material at the plant), but product-customer combinations for sales history exist in no master table; they have to be derived from transactions and maintained as customers come and go. A load that skips this step rejects every row for a new customer.

The time profile is fiscal, and weeks must add up S&OP and finance disagreeDaily documents roll into IBP's fiscal weeks and months, including partial weeks at period edges and 53-week years. If the weekly total differs from the daily total, the S&OP number and the finance number disagree, and nobody can say which is right.

Only stored key figures accept loads a load that fails or changes a number silentlyIBP calculates some key figures from others. Loading into a calculated key figure fails; loading a stored one that another key figure is calculated from changes the calculated one silently. The integration has to know which is which.

Versions are easy to overwrite the baseline overwrittenA scenario loaded without its version tag replaces the baseline, and the S&OP meeting reviews an upside case as if it were the plan.

More than one system, one key set one key set needed firstSAP's own integration reads one SAP system. An estate with ECC and S/4HANA during a migration, an Oracle unit, warehouse stock at a 3PL and an external forecast needs every product, location and customer conformed to one key set before IBP sees any of it.

Industry flavour: consumer products, life sciences, industrial manufacturing, estates mid-migration

Consumer-products estates bring customer-level demand review and promotions, so the product-customer combinations matter most. Life sciences brings batches and expiry that feed projected stock. Industrial estates bring resources and capacity key figures from work centres. Estates moving from ECC to S/4HANA bring two SAP systems feeding one planning area for a year or more. Each has a check in Step 4.

Step 3 · How Lima Backbone handles each one

Each problem has a specific answer, and each answer is something you can see

The figure shows daily invoice rows becoming one weekly key figure at its planning level, with the compound check before the load. The table maps all six problems.

Problem	What Lima does	The capability behind it	What you see
1 · Planning-level completeness	Requires every attribute of the key figure's level on every row; rows with a missing attribute are held with an owner, so they never land at an aggregate	Rules in plain language per key figure; exception routing	Held rows per key figure with the missing attribute named
2 · Compound master data	Derives product-customer and product-location combinations from history and orders, maintains them as customers appear, and loads them before key figures with the owner's approval for new ones	Derived master data with owner review; dependency-ordered loads	A combination register: existing, new this cycle, approved
3 · Time profile	Builds each key figure at its bucket from the daily rows using IBP's fiscal calendar and checks weekly and monthly sums against the daily rows	Grain builder with a configurable calendar; sum-of-parts checks	Per-key-figure reconciliation: daily total, weekly total, difference
4 · Stored versus calculated	Keeps a catalogue of the planning area's key figures that accept loads, and refuses a load into a calculated one before it starts	Target-model catalogue for IBP	The key-figure catalogue with load status per key figure
5 · Versions	Tags every load with its version and blocks a scenario load that names the baseline without a second-person approval	Version tagging; second-person approval	Loads listed by version with who approved them
6 · One key set	Conforms products, locations and customers across ECC, S/4HANA, Oracle, WMS and 3PL sources into one key set before any load, with the mapping versioned	Consolidation with name resolution; versioned mappings	One key with its source codes listed underneath, per system

Step 4 · The checks that run before anything loads

Nine checks an IBP load runs every cycle

Every check is a rule with an owner. A failed row is held with the rule and the row; the load continues with the rest and the report says what was held. Examples from the showcase estate:

Check	Kind	Example	When it fails
Every key figure row carries every attribute of its planning level	Completeness	9,120 sales rows with no customer at PRDLOCCUST level	Held; exception to the sales-data owner
Every product-location and product-customer combination exists before the key figure loads	Completeness	212 new product-customer combinations this cycle	Proposed; owner approves; then loaded
Weekly and monthly totals equal the daily totals they were built from	Consistency	Week 37 actuals vs VBRP rows for plant 1000	Load stays open until they match
The target key figure is stored (accepts loads)	Quality	A load aimed at a calculated key figure	Refused before it starts
Every load carries a version; baseline loads are approved	Consistency	An upside scenario without a version tag	Held for the planner
Units converted to the IBP base unit; currency key figures converted at the rate type and date	Quality	Revenue in local currency without a rate for the period	Exception to finance
Keys identical across ECC, S/4HANA and Oracle sources	Consistency	Customer C-88 in S/4HANA and CUST88 in Oracle	Consolidated; owner confirms
Time profile covers the planning horizon with no missing buckets	Completeness	Fiscal 2027 buckets still undefined	Exception to the calendar owner
Record counts and control totals per key figure match the source	Completeness	Every key figure, every load	Load report stays open until they match

Kinds: completeness (is everything there), consistency (do related numbers agree), quality (is each value valid).

Step 5 · Watching the data flow, correcting it on the way

One screen from the ERP table to the planning object

Integration suites such as Informatica sell data integration, data quality, the catalog and lineage as separate services on one consumption meter, and a team stitches the four together for each load. Lima runs the four as one surface. The screen above is the same for every load into SAP IBP: each step from the ERP invoice table to the IBP key figure row shows its row count; the rule that stopped a row shows the row and the person who owns the fix; the fix is applied where the row stopped and the replay starts from that step. Column-level lineage is recorded from the run itself, so the trace from a number in SAP IBP back to the ERP table is current every morning without a scanning project.

Rules in plain language

Checks a planner can read

A rule such as "confirmed date is on or after order date" is written in words, previewed on live rows, versioned, and owned by a named person.

Exceptions with owners

Nothing disappears

A row that fails a rule becomes an exception with the row, the rule, an owner and a deadline. The load carries on with the valid rows and says what it held.

Lineage from the run

Always current

Every step records what it read and wrote at column level, so the trace from a planning number back to the ERP field is captured as a by-product of running.

Governed planning master data

Parameters with owners

Values the ERP never held — hierarchies, changeover matrices, demand-stream rules — live in Lima with an owner and an effective date.

Acknowledged write-back

The loop closes

Results return to the ERP as transactions the ERP confirms; the confirmation is stored and reconciled against what was sent.

Deadlines on the pipeline

The planning run waits for nothing

Each load carries its window and deadline; a tripped rule pauses the run and the clock, and the run resumes from its checkpoint after the fix.

Step 6 · Load, reconcile, return

On the planning cycle, reconciled, and back to the ERP

IBP is loaded on its cycle through the channel you use; every load ends with a reconciliation report; approved plans return to ECC, S/4HANA and non-SAP systems as transactions they confirm.

Weekly demand cycle

Actuals and attributes at their planning level before the demand review, with compound checks and sum checks.

Nightly supply net-change

Stock, open orders and capacity as net-change, in dependency order, for supply and response planning.

Monthly S&OP

Scenario versions loaded and tagged; the baseline is written only with a second-person approval.

What goes back to the ERP

Result	SAP transaction	Oracle interface	How it is confirmed
Approved supply plan	`BAPI_PLANNEDORDER_CREATE` · `BAPI_PR_CREATE` into ECC or S/4HANA	WIP job interface · `PO_REQUISITIONS_INTERFACE_ALL`	Order numbers stored; failures re-queued with reason
Consensus demand to the ERP	Planned independent requirements: `BAPI_REQUIREMENTS_CREATE`	`MRP_FORECAST_INTERFACE`	Counts acknowledged and reconciled per product-plant
Safety-stock and parameter updates	`BAPI_MATERIAL_SAVEDATA`	Item interface	Second-person approval in Lima, then the acknowledged write
Results to non-SAP systems	—	Oracle, WMS and 3PL through their APIs	Acknowledged and reconciled the same way

Standard released interfaces; the exact objects are confirmed per scope during the assessment.

A first load, step by step

Twenty-two days on the showcase estate

How a first load into IBP runs for an estate with two SAP systems, an Oracle unit and a 3PL. Figures are from the showcase estate.

Day 1
connect

Four sources, one planning areaS/4HANA (Europe), ECC (Americas), Oracle EBS (an acquired unit) and a 3PL stock feed connected; the S&OP dataset scoped to the demand and stock key figures at product-location-customer week.

Day 4
keys

One key set6,800 customer records across three ERPs resolve to 4,120 customer keys; 214,000 product-customer combinations are derived from history and loaded as compound master data with the planner's approval.

Day 8
levels

Held, with an owner9,120 sales rows with no customer are held for the sales-data owner, and none of them lands at an aggregate; 27 currency conversions for revenue key figures are missing a rate and go to finance.

Day 11
time profile

Weeks that add upActuals built at fiscal week from daily rows for 156 weeks; weekly and monthly totals match the daily rows for every plant, including the 53-week year.

Day 13
first load

Into the baseline, approvedMaster data, compound master data and key figures load in order into version BASELINE with a second-person approval; the reconciliation report matches counts and totals.

Day 19
write-back

The loop closes on three systemsConsensus demand posts to ECC and S/4HANA as planned independent requirements and to Oracle through the forecast interface; approved planned orders post to S/4HANA; every post acknowledged.

Day 22
hand-over

LiveThe combination register, the reconciliation report and the exception register are handed to the planning COE; the weekly cycle runs on its own.

Partner and certification status

Stated as it is

Program	What it gives you	Status
SAP PartnerEdge · listing	An SAP Store listing and, depending on tier, a certification badge	Tier decision · Q4 2026
Systems integrator delivery	Delivery by your SI or ours on the same fixed-scope offer	Available

Statuses are stated as they are and dated when they change. Badges appear only after they are granted.

Lifecycle

A SAP IBP integration uses every stage, Return included.

STEP 1

ConnectSAP, Oracle, WMS, files, lakehouses

STEP 2

Extracttable reads, BAPIs, CDS views, CDC

STEP 3

Transformat MRP volume, 150+ operators, Python

STEP 4

Loadon the run window, counts proved

STEP 5

Orchestratedeadlines, pause and resume, replay

STEP 6

Returnwrite-back, acknowledged

One engine underneath every page in this family. It reads from any source and writes to any target, runs batch loads or change-data streams, handles a nightly delta or a multi-terabyte migration, and is licensed by capacity, so the bill stays the same however many rows move. Lima's fabric answers questions on data in place; Lima Backbone moves, transforms and returns data on a deadline. When to federate and when to pipeline · The Backbone hub.

Terms on this page

Plain definitions

Planning areaIBP's container for master data types, key figures and the time profile a planning process runs on.

Planning levelThe set of attributes a key figure is stored against, such as product, location, customer and week.

Key figureA time series of planning quantities — sales history, forecast, stock — held per planning-level combination.

Compound master dataA valid combination of master data, such as a product at a location or a product for a customer.

Time profileIBP's calendar of days, weeks, months and quarters, usually fiscal.

VersionA named copy of the plan; scenarios are versions, and the baseline is the one the S&OP meeting reviews.

Control totalA sum computed on the source and the target and compared, alongside record counts.

Acknowledged writeA transaction the ERP has confirmed, with the confirmation stored and reconciled against what was sent.

Questions we hear

Asked before the first load.

How does Lima load IBP?

Through the integration channel your planning area uses — batch time-series integration, real-time order integration or the APIs — in IBP's planning-level format, on the cycle you set, with counts proved per load. Your IBP team keeps its planning areas and key-figure definitions.

We are on ECC and moving to S/4HANA. Does the integration survive the move?

Yes. Lima reads ECC and S/4HANA with the same methods, both can feed IBP during the transition, and the IBP feeds built on ECC continue after cut-over.

What happens to sales rows with no customer?

They are held with the others for that product and location, listed for the sales-data owner with the missing attribute named, and loaded once fixed. The load carries on with the rest.

Does Lima replace SAP's integration?

Where SAP's own integration already carries the S/4HANA core, it can stay. Lima carries the rest — the second ERP, the non-SAP sources, the planning master data — and the reconciliation.

What comes back?

Approved supply plans as planned orders and requisitions, consensus demand as planned independent requirements, and approved parameter changes, into ECC, S/4HANA or a non-SAP system — each write acknowledged and reconciled.

Can external forecasts and 3PL stock be blended in?

Yes. They are sources on the same pipeline, conformed to IBP's keys and aligned to its time profile and units before the load.