The EPM Integration Nobody Budgets For

Every planning platform demo looks the same. Drivers on the left, a beautiful P&L on the right, a slider that changes headcount and reflows the forecast in real time. Pigment, Anaplan, Adaptive, TM1, OneStream. The demo is always the model.

The implementation is never the model. It is the integration, and it is the line item that gets cut in the statement of work because nobody can picture what it does.

What actually breaks

A planning model is a set of structures: entities, accounts, cost centers, products, periods. The ERP has its own set of the same structures. They are never identical. The ERP has the legal view. The plan has the management view. Between them sits a mapping, and that mapping is where every planning platform failure I have seen actually lives.

The pattern is predictable. Go-live is fine because someone built the mapping by hand and checked it. Then the ERP changes. A new entity is created for an acquisition, a cost center is split, a chart-of-accounts cleanup renames forty accounts. The mapping does not change, because nobody owns it. Actuals load into the plan with a gap. Finance finds it three weeks later when the variance report makes no sense, and the fix is a spreadsheet.

Six months in, the planning platform has a shadow reconciliation process next to it, and the team is spending more time on the load than on the plan.

Treat the mapping as a product

The fix is organizational before it is technical. The mapping layer between the ERP and the planning model needs an owner, a version history, and a validation step. Same as any data product.

Owner means one named person who is notified when the ERP master data changes. Not a team. A person.

Version history means every change to the mapping is recorded with who, when, and why, so a broken load can be traced to the change that broke it.

Validation means the load does not reach planners until totals reconcile to the ERP at the level finance cares about. Usually that is entity and account by period. If the totals do not tie, the load fails loudly and someone is paged, instead of the plan quietly absorbing a gap.

The integration engineer is the role

This is why the finance systems roles at AI labs read the way they do. They ask for planning platform depth and integration engineering in the same person: REST APIs, SQL data models, pipelines into the warehouse, validation rules. The company is growing fast, entities are multiplying, and the plan has to stay tied to the books through all of it.

That job is not about knowing Pigment or Anaplan. It is about knowing that the plan is only as trustworthy as the mapping under it, and building the mapping so it survives the next reorganization.

A practical order

Inventory the structures on both sides and document the mapping as it exists today, including the exceptions living in people's heads. Assign the owner. Put the mapping under version control, even if that is a table with an audit trail. Add the reconciliation check to the load. Then, and only then, expand the model.

Most teams do it in the opposite order, because the model is what the demo showed them.