The AP Decision Your SAP Cloud ERP Migration Can't Afford to Get Wrong

In almost every SAP Cloud ERP program, there comes a point when AP suddenly becomes someone's problem. Not because it was forgotten, but because the assumptions made early about how invoice processing would work in the new environment turn out to be wrong. Formats vary. Mandates differ by country. Approval chains don't map cleanly. And the ERP team absorbs a wave of customization requests nobody budgeted for. 

This is almost always avoidable.

Where should AP complexity live in an SAP Cloud ERP migration? 

SAP Cloud ERP is built around clean core: minimal customization inside the ERP, complexity managed through certified BTP extensions. The problem is that AP is one of the most complex functions in any global enterprise, and that complexity doesn't disappear because you've committed to clean core. It has to go somewhere. 

In practice it ends up in one of two places: back inside the ERP as custom code, quietly undermining the clean core investment; or in a specialist Invoice Lifecycle Management platform that handles it outside the core and returns clean data back in. 

Clean core is not an accounting policy. It is an architectural commitment that keeps the ERP standard, so upgrades stay cheap and low risk. SAP's own guidance pushes extensions onto the Business Technology Platform rather than into the core, and that works for most functions. AP is an awkward exception. Invoice capture, format handling, tax determination, matching, and approval routing are exactly the high-variability logic that clean core is trying to keep out. Push all of that into BTP and you are rebuilding a specialist platform from scratch. Leave it in the core and undermine the reason you moved to clean core in the first place. 

The difference isn't technical. It's a decision, and most programs make it too late, under pressure, with the wrong framing. The right question isn't "how does AP fit into the ERP?" It's "where should AP complexity live, and who owns it?" 

What do you gain by keeping AP outside SAP Cloud ERP? 

The results speak for themselves: customers taking this approach see up to 10x fewer AP-related ERP customizations, and AP value that compounds before the ERP goes live. 

This is the difference between AP automation and Invoice Lifecycle Management. Basware does not just process invoices faster. It governs the full life of every invoice, across each country and each ERP, as one trusted record. That track record matters when you are committing to a multi-year program. 98% customer retention, $10T+ approved for payment, and 2.5 billion invoices processed give finance leaders an evidence base, not a promise. 

See how KION avoided ERP lock-in while gaining a flexible platform capable of managing the full invoice lifecycle, enabling capture, validation, compliance, and reporting across a multi-ERP landscape. Read the full case study.

When should AP go live in an SAP Cloud ERP migration? 

The architectural decision to externalize AP is cheapest to make while the blueprint is still open. Once the ERP is live, revisiting it is significantly more disruptive and expensive. 

Get it wrong and the bill arrives later, in pieces. Custom AP objects have to be re-tested at every SAP upgrade. Each new country or acquisition reopens the same integration work. Exceptions the design never anticipated pile up as manual workarounds, and the clean core you paid for quietly fills with the code you were trying to avoid. None of this shows up in the go-live plan. It shows up in the two years after, as run cost and change requests that were entirely avoidable. 

A specialist ILM platform can go live before the SAP cutover. AP value compounds while the migration is still running, a timing advantage no ERP-embedded solution can offer. Transformation budgets are active. Change management is deployed. The architecture is still being designed. All of that changes after go-live.

Standing up the platform before cutover also de-risks the migration itself. Clean, validated invoice data flows into the new environment from day one, so AP is not the workstream holding up go-live. And because the platform sits above the ERP, the same model carries into the next migration wave without a rebuild.

There is an AI dimension to the decision too. Keeping AP outside the core is where governed AI can run safely: the AI handles the volume, your team sets how far it goes, and every decision stays auditable and explainable. That is far harder to retrofit inside a clean core ERP once it is live. 

Put the question to your systems integrator directly. Where will AP logic live, in the core, in BTP, or in a specialist platform? What happens to that logic at the next upgrade, and at the next country rollout? How much custom development are we signing up for, and who maintains it? If the answer is a pile of custom objects inside SAP, you are paying to rebuild AP the hard way. The cleaner answer keeps the core standard and lets a purpose-built layer carry the complexity. 

If your program is underway, the AP architecture question belongs on the agenda now. 

Download the full strategic guide for the architecture decision, the business case, and the integration model behind keeping AP outside clean core: Modernizing Invoice Lifecycle Management in SAP Cloud ERP Landscapes.