What breaks in accounts payable during an S/4HANA migration
Senior Manager Content Marketing at Medius
- Introduction
- Open invoice balances rarely reconcile cleanly at cutover
- Vendor master records carry their problems into the Business Partner model
- Historical invoice archives get harder to reach after ECC is decommissioned
- Approval hierarchies get rebuilt, not carried over, during the parallel run
- SAP's own clean core guidance points to where AP logic belongs
- Keeping AP logic outside the ERP core during migration
- Frequently asked questions
SAP's mainstream maintenance for ECC ends December 31, 2027, and that deadline has already reshaped how a large share of the installed base is planning the next 16 months. According to SAPinsider's 2026 benchmark research, 55% of organizations report deploying S/4HANA in some form, but only 34% call the transition complete. AI capability has overtaken the deadline as the top reason companies cite for moving, but 39% still name the 2027 cutoff as a primary driver.
Accounts payable rarely gets a seat at the table when these programs are scoped. Migration teams plan around the general ledger, the universal journal, and controlling. AP shows up later, usually when someone realizes invoices still have to get paid during cutover and no one has been assigned to own that part of the plan.
That gap is where things break. Four problems show up in nearly every AP-adjacent migration, and they rarely make the risk register until they cause a payment delay, a vendor complaint, or an audit finding:
- Open invoice balances that don't reconcile cleanly at cutover
- Vendor master records that carry duplicates and bad data into the new Business Partner model
- Historical invoice archives that get harder to reach once ECC is decommissioned
- Approval hierarchies that have to be rebuilt, not copied, during the parallel run
Open invoice balances rarely reconcile cleanly at cutover
Every AP department carries a tail of aged open items: partial payments, blocked invoices, disputed amounts, and credits that were never applied. Those balances have to move from the ECC ledger into S/4HANA's universal journal without duplicating a payment or dropping one, and the AP subledger has to tie back to the general ledger at the cutover date.
Most programs try to clear as much of the subledger as possible before go-live, which turns the weeks before cutover into an unusually heavy payment cycle stacked on top of normal invoice volume. Whatever doesn't clear gets migrated and reconciled by hand. Goods received not invoiced balances are a reliable problem area here, because a mismatch in that clearing account usually points back to a receiving or purchasing issue rather than an invoice error, which means the three-way match has to be untangled with another department before anything can be resolved.
Then there's the blackout. Invoices don't stop arriving while the system is unavailable, so someone holds them and works through the backlog after go-live, in a system the team is touching for the first time. The small discrepancies that come out of that window are what turn into vendor calls, short payments, and duplicate payment investigations weeks later, once the migration team has already moved on to the next workstream.
Vendor master records carry their problems into the Business Partner model
S/4HANA requires vendor master data to convert to the Business Partner object through Customer/Vendor Integration, and that conversion doesn't clean up bad data on its own. Records that fail validation have to be corrected before the conversion completes, which means data quality problems that were merely annoying for a decade in ECC turn into blocking issues on a migration timeline.
Years of duplicate vendors, inconsistent tax IDs, and stale banking details come along for the ride unless someone deduplicates first. Deciding which of three near-identical records is the real supplier isn't a technical question. It's an AP question, and the people who can answer it are the same people processing invoices through cutover. Migration plans consistently underestimate that workload, partly because it doesn't look like migration work. It looks like supplier data management, and it keeps paying off long after go-live.
The cost of skipping the cleanup isn't only messy reporting. Duplicate vendor records carrying conflicting bank details are exactly the gap that misdirected payments and vendor fraud exploit, and the middle of a system transition, when normal approval habits are already disrupted, is the worst possible time to be working from a vendor file nobody fully trusts.
Historical invoice archives get harder to reach after ECC is decommissioned
How much history comes along depends on the migration approach. A system conversion carries existing data forward. A new implementation typically brings open items and a limited window of history and leaves the rest behind. In both cases, the invoice documents themselves, meaning the scanned images and emailed PDFs that came in through invoice capture and were attached through ArchiveLink, get handled as a separate decision from the transactional data, and often by a different group of people.
AP needs those documents for years after payment, for audits, tax reviews, and vendor disputes. Retention requirements commonly run 7 to 10 years depending on jurisdiction. While ECC is live, pulling a copy takes seconds. Once the legacy system is archived or shut down, the same request often becomes an IT ticket and a wait, and that cost multiplies across every vendor calling about an invoice from two years ago.
Archiving strategy usually gets decided as a storage and compliance question. The part that gets missed is retrieval: who in AP will need a document, how often, and how quickly. That is a much cheaper question to answer before the legacy system goes dark than after.
Approval hierarchies get rebuilt, not carried over, during the parallel run
S/4HANA's flexible workflow doesn't map one-to-one onto ECC's release strategy and workflow configuration, so approval routing has to be redesigned and retested rather than migrated as-is. In many ECC environments, the real approval matrix was never fully in the system to begin with. Thresholds, delegations, and exception routing live in custom tables, in spreadsheets, and in the head of whoever has run AP the longest.
That work usually collides with a second source of change. Organizational restructuring, revised spending thresholds, and new delegation of authority rules tend to arrive with a major ERP project rather than ahead of it. So the team isn't porting an approval hierarchy. It's designing a new one, documenting it for audit, and testing every routing path and substitution rule before go-live.
All of that happens while both processes are live. Invoices still have to be approved and paid on the old path while the new one is being validated, which doubles the workload in the exact window when AP has the least slack to absorb it.
SAP's own clean core guidance points to where AP logic belongs
SAP defines clean core as a set of principles for keeping the ERP system close to its standard, vendor-supplied state rather than layering it with custom code and point-to-point integrations. SAP's stated reasons for this come down to a few consistent benefits:
Faster access to upgrades and new capability, without re-testing custom code first
Lower technical debt and lower long-term maintenance cost
More reliable system performance
Cloud flexibility that doesn't depend on modifying the core
SAP's own recommendation is to extend functionality through cloud-based tools built for that purpose, such as SAP Business Technology Platform, rather than modifying the core system directly. That guidance applies directly to accounts payable. Custom-built matching rules, approval routing, and invoice capture logic layered into ECC over the years are precisely the kind of core customization SAP is telling customers to move away from, and they're also precisely what breaks or has to be rebuilt at every major migration. The four problems above aren't a coincidence. They're what happens when AP logic lives inside a system that's due for a rebuild.
AP is a particularly poor fit for the core for one reason: it changes constantly. New suppliers, new payment terms, shifting tax rules, and e-Invoicing mandates that move on their own timelines all generate change requests. When that logic sits inside the ERP, every one of those changes becomes a core modification that has to be re-tested at the next upgrade. When it sits outside, the ERP stays standard and AP keeps moving at its own pace.
Falling behind on e-invoicing mandates puts your business at risk.
Mandatory e-invoicing is expanding fast across Europe, Latin America, and the US. This global cheat sheet helps finance teams track what's coming and when.
Keeping AP logic outside the ERP core during migration
The alternative is to handle invoice capture, coding, matching, approvals, and vendor communication in a dedicated AP platform that connects to SAP rather than living inside it. Medius Connect is built for that role: it's a pre-packaged connector, not a custom integration project, and Medius holds SAP Silver Partner and SAP PartnerEdge Build Program status specifically for this kind of SAP integration work. It can go in during the ERP project or after it, with minimal IT involvement either way.
Because the platform supports both SAP ECC 6 and S/4HANA, it can run against the existing system now and connect to the new one at cutover. The AP team keeps working in the same place while the ERP underneath them changes, which is a materially different experience than learning a new invoice process during the same week as go-live.
The practical effect during a migration is that cutover doesn't touch the AP process, because the AP process was never built inside the core to begin with. Open items keep moving through approval and payment on the same platform before, during, and after go-live. Vendor records get deduplicated and validated outside the Business Partner conversion, not as a side effect of it. Invoice history stays accessible to the AP team regardless of what happens to ECC on the back end. AP teams running this way go into their S/4HANA migration treating it as an ERP project, not an AP project, which is what it should have been the whole time.
Companies with roughly 16 months left before the ECC deadline are deep in planning right now. The ones that treat AP as an afterthought will spend part of that runway firefighting reconciliation gaps and rebuilding approval workflows twice. The ones that move AP logic outside the core first get to spend it on the migration itself, which is a better use of 16 months either way.
Buying AP automation for a large organization? Use this first.
With so many platforms out there, it's hard to know what actually matters. This enterprise buyer's checklist cuts through the noise and helps you evaluate what counts.
Frequently asked questions
Mainstream maintenance for SAP ECC ends December 31, 2027. Extended maintenance is available after that through the end of 2030 for an additional fee, currently about a 2% uplift on existing support costs, with further extensions negotiable on request. Staying on ECC past 2027 is possible, then, but it means paying more to run a system that is no longer where SAP is putting its development effort.
Open items have to be reconciled and carried from the ECC ledger into S/4HANA's universal journal at cutover. Aged items, partial payments, blocked invoices, and unapplied credits are the ones that cause problems, because they often require manual review. Getting this wrong produces duplicate payments, missed payments, and vendor disputes that surface weeks after go-live.
Before is generally easier. Implementing AP automation ahead of the migration means invoice capture, matching, and approvals are already running outside the ERP core when cutover happens, so the AP process does not have to be rebuilt and tested at the same time as the ERP. Platforms that use a pre-packaged connector can also be deployed during or after the project.
Clean core means keeping the ERP close to its standard state instead of layering custom code and point-to-point integrations into it. Custom AP logic built inside ECC, including matching rules and approval routing, is exactly the kind of customization the approach discourages. Moving that logic to a platform outside the core aligns AP with SAP's guidance and removes it from the upgrade path.
Not directly. S/4HANA uses flexible workflow, which does not map one-to-one onto ECC's release strategy and workflow configuration, so approval routing has to be redesigned and tested rather than copied. Reorganizations and updated spending thresholds frequently happen alongside the ERP project, which adds to the redesign work.
It moves to an archive, and day-to-day access usually gets slower. AP teams that could pull an invoice image in seconds often have to submit an IT request instead. Retention requirements typically run 7 to 10 years depending on jurisdiction, so it is worth confirming how AP will retrieve documents for audits and vendor disputes before the legacy system is shut down.
