If you're moving to SAP Cloud ERP, one decision will shape how smooth or how costly that migration turns out to be: what to do with accounts payable. AP is one of the most complex functions in any finance organization, and it doesn't fit neatly into SAP's "clean core" model. Get the call right, and your ERP stays standard, upgrades stay cheap, and AP runs smoothly from day one. Get it wrong, and you end up rebuilding AP logic inside the ERP as custom code that needs re-testing at every future upgrade.
Here's what's driving that risk, and what to do about it before your architecture is locked in.
Why AP trips up so many migrations
Clean core keeps the ERP standard by pushing customization out to certified extensions. That works for most functions — but AP's complexity (invoice formats, tax rules, matching, country-specific approval chains) doesn't go away just because you've committed to clean core. It has to live somewhere: back inside the ERP as custom code that undoes the clean core investment, or in a dedicated Invoice Lifecycle Management platform built to handle that complexity outside the core.
Why timing matters
This decision is cheapest to make while the blueprint is still open. Wait until after go-live, and every custom AP object needs re-testing at each SAP upgrade, every new country or acquisition reopens the same integration work, and exceptions the design never anticipated pile up as manual workarounds. Handling AP externally, before cutover, means clean data flows into the new ERP from day one, so AP isn't the workstream holding up go-live, and the same setup carries into future ERP moves without a rebuild.
The question to ask
Skip "how does AP fit into the ERP?" The better question is "where should AP complexity live, and who owns it?" Put it to your systems integrator directly, and get a clear answer before the architecture is set.
Read more here
