# Migrating SAP Treasury from ECC to S/4HANA

Source: https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Migrating SAP treasury from ECC to S/4HANA: the simplification items that change (BP, bank accounts, One Exposure, TRM) and what the 2027 deadline means.

**Migrating SAP treasury from ECC to S/4HANA is not an upgrade — it's substantially a re-implementation, because S/4HANA redesigned key treasury areas, most of all Cash Management around [One Exposure from Operations](https://gravam.com/blog/one-exposure-from-operations-fqm-flow).** I've said this in passing across this guide, and it's worth its own article because it's the single most expensive misconception in SAP treasury right now: teams scope the treasury piece of an S/4HANA move as "lift and shift, just newer," and then discover in testing that significant parts had to be _rebuilt_. The concepts a treasurer knows carry over. The plumbing beneath them does not. Plan for the second sentence, not the first.

## Why it's not an upgrade

An upgrade implies the same thing, newer. But S/4HANA didn't just modernize treasury — in places it _redesigned_ it. The clearest example is [Cash Management](https://gravam.com/blog/sap-cash-management-s4hana): classic maintained its own summary records; S/4HANA rebuilds the whole thing on the [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) hub. That's not a reskin — it's a different foundation. When the foundation changes, "upgrade" is the wrong word and the wrong plan. A re-implementation-sized effort is also the moment some treasuries briefly reopen the [SAP TRM vs standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms) question — if you have to rebuild either way, the embedded-vs-best-of-breed call is on the table again.

## What actually changes

> The concepts survive; the plumbing is new. Position, forecast, deals, risk — a treasurer recognizes all of it. But how those concepts are stored, computed and reached has changed underneath, and configuration and data don't migrate themselves across a redesign.

- **Cash Management** — redesigned around [One Exposure / `FQM_FLOW`](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), a new data model, not the classic summary records.
- **Tools** — much moves to **[Fiori apps](https://gravam.com/blog/sap-treasury-fiori-apps)**.
- **Bank accounts** — house bank accounts stop being configuration and become master data in [SAP Bank Account Management](https://gravam.com/blog/sap-bank-account-management-s4hana).
- **Business partner** — every customer and vendor has to be a [business partner](https://gravam.com/blog/business-partner-configuration-sap-treasury) before the conversion runs.
- **TRM** — the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) and [risk components](https://gravam.com/blog/sap-market-risk-analyzer) carry treasury forward, but configuration and postings still need rework and re-testing.

## The simplification items that touch treasury

SAP publishes every functional change in the Simplification List, one "S4TWL" item and SAP Note per change, and SAP Readiness Check reports which of them your system actually triggers. Most of the list is irrelevant to treasury. These are the ones that are not:

| Area | ECC (what you have) | S/4HANA (what replaces it) | What it means for the project |
| --- | --- | --- | --- |
| Business partner | Customers and vendors as separate masters; TRM counterparties already business partners | Business partner as the single entry point for customer and supplier data (S4TWL Business Partner Approach, note 2265093) | Customer/vendor integration (CVI) must synchronise all customers and vendors to BPs in ECC, before conversion. Decide first how records that exist as both customer and vendor, and as TRM counterparty, map to one BP |
| House bank accounts | Maintained with FI12 as transportable configuration in T012K | Bank account master data in Bank Account Management (FCLM_BAM_AMD); house banks via FI12_HBANK or the Manage Banks app, accounts via Manage Bank Accounts; master data, not transported | T012K accounts are migrated to BAM during conversion, by the central data migration activity or manually with FCLM_BAM_MIGRATION. Clean up missing or malformed account data before the migration, not after |
| Cash management foundation | Classic cash management and liquidity forecast built on FDES/FDSB records | S4TWL Cash Management – General (note 2270400): classic cash and liquidity management is not available; flows live in One Exposure (`FQM_FLOW`) | One Exposure is filled from existing documents by the data setup (FQM_INITIALIZE), and memo records need their own migration step: check which one your target release uses. Reconcile the first position against ECC before anyone trusts it |
| Cash position and forecast | FF7A / FF7B reports, Liquidity Planner | FF7AN / FF7BN and the Fiori Cash Position and Liquidity Forecast apps; Liquidity Planner superseded by Fiori liquidity management apps | The report users open every morning changes. Planning levels and groups survive in the back end, but layouts, grouping and authorisations are rebuilt |
| Cash management scope | One module | Basic scope included with S/4HANA; full scope (SAP S/4HANA Finance for cash management) via business function FIN_FSCM_CLM, which cannot be reversed | Decide the licence scope first: liquidity items, cash pooling, bank fee monitoring and BAM workflows need full scope. See [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana) |
| Treasury and Risk Management | Transaction Manager, Exposure Management 1.0, correspondence, position reports | TRM continues, but the list carries TRM items including Exposure Management 1.0, Simulation in Transaction Management, Drawable Bonds, Quantity Ledger Always Active for Money Market Transactions, Correspondence Functionality and Position Reports | Read each triggered note. Exposure Management 2.0 is the S/4HANA exposure component, so 1.0 users plan that move explicitly; correspondence and position reports usually need re-configuration and re-testing |
| Position management and valuation | TRM subledger posting to classic FI (BKPF/BSEG, new-G/L totals) | Valuation areas and posting logic carry forward, with the general-ledger side landing in the Universal Journal (ACDOCA) | Re-run key-date valuation (TPM1) and compare the posting journal (TPM20) against ECC for every [valuation area](https://gravam.com/blog/sap-trm-position-management-and-valuation); the numbers must tie, not just post |
| Pre-TRM treasury data | Enterprise 1.10, CFM 2.0 or 4.6C-era treasury structures | The TRM data model | SAP's migration guide requires converting customizing, master and transaction data with TPM_MIGRATION. Do that as its own project in ECC before the S/4HANA conversion, not inside it |
| Custom reads of classic tables | Interfaces and reports on FDES, T012K, BSEG and the BSIS/BSAS index tables | FQM_FLOW, FCLM_BAM_AMD and ACDOCA; the index and totals tables become compatibility views | A table still existing is not the same as it still being the right source. Inventory every custom read; the [BKPF/BSEG join guide](https://gravam.com/blog/02-bkpf-bseg-join) covers the accounting side |

Two cautions about the table. Item titles and notes change between releases, so confirm the list for your _target_ release rather than the one a colleague used. And the Simplification List tells you what changed, not how your processes should look afterwards; that design work is the re-implementation part.

## The 2027 date, stated accurately

The deadline driving most of these programmes is real but often misquoted. Per SAP's published maintenance timelines, **SAP ERP 6.0 on enhancement packages 6, 7 and 8 leaves mainstream maintenance on 31 December 2027**. After that, SAP offers optional **extended maintenance until 31 December 2030**, under a separate agreement at additional cost. Systems still on enhancement packages 0 to 5 already left mainstream maintenance at the end of 2025 and fell into customer-specific maintenance, which brings no new legal changes.

The **SAP ERP, private edition, transition option**, announced in February 2025, stretches support for ERP 6.0 to the end of 2033 only for customers who move to RISE with SAP and meet its conditions. It is not an extension for on-premise systems. For treasury planning that means a 2027 conversion window with a paid fallback to 2030, and anything later is a contractual decision rather than a technical one.

## Approach it as a transformation

The right frame is the one this whole site argues for: treat it as a [treasury transformation](https://gravam.com/blog/treasury-transformation-guide), not a technical task. That means:

- **Define the outcomes** — what you want the target treasury to do, not just "be on S/4." A re-implementation is also a chance to rescope: the [SAP Treasury Module Selector](https://gravam.com/tools/sap-treasury-module-selector) is a quick way to re-map your actual needs to components before you rebuild what you had by habit.
- **Plan real [data migration](https://gravam.com/blog/tms-data-migration)** — open deals, positions, master data, balances, all migrated and reconciled to the penny (deals and positions are unforgiving of migration errors).
- **Rework and re-test the configuration** — especially the [postings](https://gravam.com/blog/sap-transaction-manager) and the redesigned Cash Management; don't assume classic config carries.
- **Run a real [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems)** — rehearsed, at a clean [period boundary](https://gravam.com/blog/cutover-and-go-live-for-finance-systems), with a fallback.

## Test like it's new — because it is

The trap that catches migrations is _under-testing_ on the assumption that "it worked in ECC." But the [Cash Management redesign](https://gravam.com/blog/sap-cash-management-s4hana) means the position and forecast are computed differently, and reworked config means the postings can behave differently — so [testing](https://gravam.com/blog/testing-strategy-for-finance-systems) has to prove the numbers _reconcile_ in the new world, not trust that they did in the old one. Run real scenarios — a close, a payment run, a valuation — and check the totals. The migration's biggest risk is a number that was right in ECC and is subtly wrong in S/4 because something in the redesign wasn't re-tested.

## Why treasury moves to S/4HANA overrun

- **Treating it as a technical upgrade.** The core mistake — scoping "lift and shift" when the Cash Management redesign means re-implementation.
- **Underestimating the Cash Management change.** Assuming classic Cash Management carries over, when it's rebuilt on One Exposure.
- **Weak data migration.** Migrating open deals, positions and balances carelessly, so the opening picture is wrong.
- **Not re-testing the postings.** Trusting ECC's accounting behaviour instead of proving it in S/4, and finding a wrong number after go-live.

Scope the treasury piece of an S/4HANA move as the re-implementation it substantially is, migrate the deals and positions with care, rework and re-test the configuration — especially the redesigned Cash Management — and run it as a [transformation](https://gravam.com/blog/treasury-transformation-guide) with a real cutover, and it goes from a landmine to a controlled programme. The concepts you know will carry you; the assumption that nothing underneath changed is what sinks you. This is exactly the kind of finance-systems change [delivered without losing control](https://gravam.com/topics/finance-systems-delivery) — SAP treasury edition. The edition you land on shapes the migration path too: see the [deployment & edition comparison](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison).

***

_See also [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana) and [treasury transformation: a practical guide](https://gravam.com/blog/treasury-transformation-guide)._

## Primary sources

SAP ERP 6.0 (ECC) EHP 6-8 converting to SAP S/4HANA on-premise or private edition; simplification items named as they appear in the SAP S/4HANA Simplification List (2021-2025 editions) — confirm applicability for your target release with SAP Readiness Check. Cash Management follows the One Exposure model (business function FIN_FSCM_CLM for full scope). Maintenance dates per SAP's published ERP 6.0 timelines. Claims checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- SAP Help — Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/e7d3a052c3ad224fe10000000a445394.html
- SAP — Simplification List for SAP S/4HANA 2025 (S4TWL items for Business Partner, Cash Management and Treasury and Risk Management) — accessed 2026-09-25 — https://help.sap.com/doc/0df2ffddebab40cf9338488b2f18dc41/2025.latest/en-US/SIMPL_OP2025.pdf
- SAP Community (SAP) — Maintenance Timelines for SAP ERP 6.0 ("ECC") — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/maintenance-timelines-for-sap-erp-6-0/ba-p/13524564
- SAP News — New Offering to Help Navigate Complex RISE with SAP Transformations (SAP ERP, private edition, transition option), February 2025 — accessed 2026-09-25 — https://news.sap.com/2025/02/sap-erp-private-edition-transition-option-navigate-complex-rise-with-sap-transformations/
- SAP Community (SAP) — FAQ: CVI – Customer Vendor Integration for system conversion to SAP S/4HANA (note 2265093, S4TWL Business Partner Approach) — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/faq-cvi-customer-vendor-integration-for-system-conversion-to-sap-s-4hana/ba-p/13740757
- SAP Help — Switch Migration Program for House Bank Accounts (What's New in SAP S/4HANA 2020) — accessed 2026-10-18 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/e7cf1319b7b14ddebd3f717725fc2936.html
- SAP Community (SAP) — How to manually migrate House Banks during a system conversion using FCLM_BAM_MIGRATION — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-manually-migrate-house-banks-during-a-system-conversion-using-fclm/ba-p/13541790
- SAP KBA 2530138 — FAQ: S/4HANA Cash Management and data setup — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/2530138
- SAP Help — Exposure Management 2.0 (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/4c3af7c7b48f1ca9e10000000a42189e.html
- SAP Help (Support Content) — Treasury migration guide (TPM_MIGRATION for Enterprise 1.10 / CFM 2.0 / 4.6C treasury data) — accessed 2026-09-25 — https://help.sap.com/docs/SUPPORT_CONTENT/fiscm/3643836869.html

## Questions this article answers

**Q: Is migrating SAP treasury to S/4HANA an upgrade or a re-implementation?**

For treasury, it's much closer to a re-implementation than a technical upgrade. S/4HANA redesigned key treasury areas — most significantly Cash Management, which is rebuilt around the One Exposure from Operations hub rather than the classic summary records. So while it's part of a broader S/4HANA move, the treasury piece involves a genuinely new data model, new tools (Fiori apps), and reworked configuration. Teams that scope it as 'just upgrading treasury' consistently under-plan it and get caught out in testing.

**Q: What changes for treasury when moving to S/4HANA?**

The biggest change is Cash Management, which is redesigned around One Exposure from Operations (table FQM_FLOW) instead of maintaining its own separate summary records — a different foundation, not a reskin. Every customer and vendor must be synchronised to a business partner before conversion, house bank accounts become bank account master data in Bank Account Management, and classic cash management reports such as FF7A and FF7B give way to FF7AN, FF7BN and Fiori apps reading One Exposure. Transaction Manager and the risk components carry the treasury concepts forward, but configuration, data and testing all need genuine attention. The concepts a treasurer knows carry over; the plumbing beneath them is new.

**Q: When does SAP ECC mainstream maintenance end?**

For SAP ERP 6.0 on enhancement packages 6, 7 and 8, mainstream maintenance ends on 31 December 2027, with optional extended maintenance available at extra cost until 31 December 2030. Enhancement packages 0 to 5 already left mainstream maintenance at the end of 2025 and moved to customer-specific maintenance. The SAP ERP, private edition, transition option offers support to the end of 2033 only for customers who move to RISE with SAP under its conditions; it is not an extension of on-premise maintenance.

**Q: How should you approach an SAP treasury S/4HANA migration?**

Approach it as a transformation project, not a technical upgrade: define the outcomes, plan real data migration for open deals, positions and master data, rework and re-test the configuration (especially the postings and the redesigned Cash Management), and run a proper cutover. The single most important mindset is refusing to treat it as 'lift and shift' — because the Cash Management redesign in particular means significant parts have to be rebuilt and re-tested, and pretending otherwise is what turns these projects into overruns.