Mainstream maintenance for SAP ECC ends on 31 December 2027, and a move to S/4HANA usually takes 18 to 36 months (BDO). That means that manufacturers still on ECC are either mid-migration or about to start one that will run most of the way to the deadline.
While the integrator owns the migration, finance owns something narrower. The card spend, expense claims, supplier invoices and approvals that run through ECC every day have to keep working while the system under them is replaced. In most migration plans those are the processes frozen first and fixed last.
Why spend control is the first thing to freeze
An integrator's plan is built around the ledger. The general ledger, chart of accounts, open items and master data get mapped, cleansed, migrated and reconciled, and the consultants then spend their time testing that work and rehearsing the cutover. Everything else in ECC is judged on whether it will still work on S/4, and what has to change if it won't.
Spend processes do badly on that test because they're rarely standard. Approval routes, release strategies and invoice workflows in a manufacturing ECC system get customised over years to match how plants, purchasing and finance actually work.
Custom code is usually the hardest part of an SAP migration to carry across, and testing is where these projects bottleneck, so customised workflows sit at the back of the queue for remediation and re-testing.
At the same time, the project needs the old system to hold still. Once the integrator has copied ECC and started converting it, any change made to the live system has to be redone by hand in the S/4 project systems, so most programmes restrict changes to ECC for the length of the project rather than carry that double work. For finance that means no new approval route for a new plant, no card limit changes and no invoice capture until the migration is complete.
As a result, new needs will be handled around the existing system. For example a new supplier category gets an email approval chain, a new site runs on a shared card with no limit of its own, invoices get keyed in by hand or parked in a spreadsheet.
Every one of those workarounds produces hand-keyed data, which is where migration data errors come from. This then has to be cleansed and validated before it can be loaded into S/4.
Don't wait for go-live, and don't fold spend into the migration
Waiting for go-live and moving everything at once is the default, and it commits finance to frozen controls and spreadsheet workarounds for the whole project. The data cleanse still has to happen at the end, on a bigger pile.
Scoping procure-to-pay into the migration as its own workstream is a tempting fix, but it puts card, expense and invoice flows in competition with the general ledger for the same consultants and the same test windows. When the programme slips, the ledger keeps its slot and procure-to-pay moves later because it's lower priority.
Both options leave spend controls on the ERP project's timeline rather than the business's. The way to avoid that is to get the spend processes off the ERP's critical path altogether.
Take the workflows out, keep the ERP as the system of record
The better approach is to move the operational spend flows out of the ERP before the migration starts, and keep the ERP as the system of record by feeding accounting-ready entries back into it.
The split is simple:
- The spend layer owns the workflow (who can buy what, who approves, how it gets coded)
- The ERP owns the books
This allows finance to change a limit or an approval route mid-project because the control no longer lives in the frozen system, while the ledger keeps receiving the same coded entries it always did.
It also takes spend out of the integrator's plan almost entirely. Instead of a set of custom workflows to remediate and re-test, spend becomes a file of coded entries that is imported into whichever ledger is live. There is no interface to assess or re-test, only an import format to agree.
Key takeaways:
- Spend workflows in ECC are customised, so they are the last to be remediated and the first to be frozen.
- Workarounds during the freeze create hand-keyed data that has to be cleansed before it can move to S/4.
- Moving spend into the migration scope puts it in competition with the ledger, and it loses.
- A spend layer outside the ERP keeps controls changeable mid-project and reduces the migration's spend footprint to one import format.
Where Moss fits, and where it stops
Moss is a spend layer that sits outside the ERP. Cards, reimbursements and accounts payable run in Moss with their approvals, limits and coding, and coded entries are exported as a file for import into SAP, with the chart of accounts, cost centres and suppliers loaded into Moss the same way.
While Moss plays no part in the migration itself, it does handle the daily spend processes that used to depend on ECC's native modules, so finance's controls stop depending on a system under change restrictions.
Three things to do before the project starts
- Find the spend workflows in the custom code audit. The migration assessment lists every custom object and interface, so pick out the approval routes, release strategies and invoice workflows and decide which are moving out rather than being remediated.
- Set up the spend layer against ECC while changes are still allowed, and run at least one month-end with the export landing in the ledger.
- Agree the journal import format for S/4 with the integrator early, and who owns the import after cutover. It is a mapping exercise rather than an interface to build.
What go-live looks like
On cutover weekend, cards, expenses and invoice approvals run exactly as they did the week before, because none of them were in the migration. Afterwards the export is pointed at the S/4 import format instead of ECC's, and the first month-end on S/4 closes with the spend side already coded and no backlog of workarounds to clean up.
If you’re scoping a move, see how Moss connects to your ERP on our integrations page.
