An S/4HANA migration touches nearly every finance process, but accounts receivable and cash application tend to get less planning attention than general ledger and reporting — partly because AR "already works" in ECC, and partly because it's tempting to treat the migration as a technical lift rather than a process redesign opportunity. That's a mistake. The migration is the best window you'll get to fix AR process debt that's usually been accumulating for years.
What actually changes in AR under S/4HANA
S/4HANA's Universal Journal consolidates FI and CO data into a single line-item table, and Fiori-based apps replace a number of the transaction codes AR teams have used for years. For cash application specifically, this generally means new posting and matching interfaces, changes to how open items and clearing are surfaced, and — for groups that adopt Central Finance or similar consolidation approaches — a period where AR data may be flowing from multiple source systems into a single S/4HANA instance.
The lift-and-shift trap
The path of least resistance in any ERP migration is to replicate the existing process configuration in the new system exactly as it was in the old one — same matching rules, same manual workarounds, same spreadsheet-based exception handling that grew up around ECC's limitations. It's the fastest way to get through go-live, and it's also how a migration project quietly re-creates every process problem the old system had, just running on newer infrastructure.
If your current AR process relies on manual remittance re-keying, a spreadsheet-based exception log, or a batch file integration that only runs overnight, migrating that same process into S/4HANA preserves all three limitations. The new system will run them faster, but it won't fix them.
Three things worth rethinking during migration
- Matching rules. This is the natural point to move from exact-match-only logic to confidence-scored matching that clears a meaningfully higher share of transactions automatically, rather than reconfiguring the same rigid rules in the new environment.
- Exception reporting. ECC-era exception tracking is often a manual export to Excel. S/4HANA's real-time data model is a natural fit for a live exception dashboard instead — worth building once, during the migration, rather than retrofitting afterward.
- Integration pattern. If your current cash application tooling talks to ECC via nightly batch files, the migration is the moment to move to a native, real-time integration instead of carrying the batch pattern forward into S/4HANA.
Sequencing it with the migration
AR process redesign doesn't need to happen in the same phase as the technical cutover, but it's worth planning deliberately rather than by default. Teams that get the best outcome typically validate new matching logic and exception workflows in parallel with the S/4HANA technical migration, so that go-live is a genuine improvement over the ECC-era process rather than a same-process, new-system transition — with the redesign work saved for a "phase two" that, in practice, often gets deprioritized once the technical migration is live and attention moves elsewhere.
Where PayConnect fits in an S/4HANA migration
PayConnect integrates natively with both ECC and S/4HANA, which means cash application automation can be validated against your current ECC environment before cutover and carried forward into S/4HANA without a second implementation project. For teams migrating from a batch-file cash application tool, this is also typically the point where they move to a real-time integration rather than replicating the old batch pattern in the new system.
The takeaway
An S/4HANA migration is a rare opportunity to fix AR process debt at the same time as the underlying technical platform changes. Treating it purely as a technical lift-and-shift means paying for a migration project without getting the process improvement that was available for roughly the same effort.