SAP Cash Management in S/4HANA

SAP Cash Management in S/4HANA is the redesigned solution for cash and liquidity — three areas: Bank Relationship Management (the part most of us still call Bank Account Management), Cash Operations (the daily position), and Liquidity Management (the forecast) — built on One Exposure from Operations, database table FQM_FLOW, as its single source of cash-relevant data. The word that matters is redesigned. If you're coming from classic Cash Management in ECC, do not assume your muscle memory transfers: the concepts survive, but the data model, the tools and most of the configuration are new. I've watched more than one project treat the S/4HANA move as a technical upgrade and then discover, in testing, that it's a re-implementation wearing an upgrade's clothes.

This page is the map. Like the treasury tables and transaction codes references it sits beside, every object named below — business function, app ID, IMG node, flow type, table, workflow task — is checked against SAP's own documentation, and anything I couldn't verify there is named in the exclusions at the end rather than quietly included.

First question: which scope are you licensed for?

Before the three areas, the fork that decides half the design. SAP ships cash management in two scopes, and they are not a marketing distinction — they are a Customizing setting plus a business function.

Basic cash management ships with S/4HANA. It gives you banks and house banks (a subset of fields), bank accounts and house bank accounts (common attributes only), a list view of accounts, import/export, IDoc replication, cash position and liquidity forecast monitoring, and memo records through the app or transactions FF63/FF65. SAP names the supported apps explicitly, and adds one sentence that has cost projects real money when it was discovered late: "liquidity item is not supported in the basic cash management capability." If your forecast design depends on liquidity items, you are not in basic scope, whatever the budget says.

Full scope — SAP S/4HANA Finance for cash management — needs FIN_FSCM_CLM switched on and Full Scope selected in Define Basic Settings. It adds bank account workflow, dual control and two-person verification, payment approvers and overdraft limits, bank fee import and monitoring, bank account review, cash pools and cash concentration, liquidity item derivation, liquidity planning, and powers of attorney for banking transactions. SAP's own caution deserves repeating verbatim in your design document: activating a business function cannot be reversed in a live system.

The three areas

Three questions, three parts. Keep them straight and the module stops feeling like a maze. One naming note worth absorbing: SAP's current documentation calls the master-data area Bank Relationship Management, with Bank Account Management as the process inside it. Consultants (me included) still say BAM. Both are right; only one of them is what you type into the help portal's search box.

The working apps

The Fiori app IDs below come from the Fiori apps reference, where each one was verified against SAP's app library, and the classic codes from the transaction codes reference. This is the day-one launchpad for a cash team:

If you build one launchpad tile group and no more, build the Cash Flow Analyzer one: SAP keeps extending F2332 as the integration point for the newer cash functions, and it carries cash position, liquidity forecast and actual cash flows in a single app.

The configuration spine

This is the part the overview articles skip, and the part a consultant actually needs. Almost all of it hangs off one IMG branch — Financial Supply Chain Management → Cash and Liquidity Management → Cash Management — and it is worth memorising as a spine rather than as a list:

Two named activities inside Data Setup earn their own line, because they are the ones people search for by symptom rather than by name: Activate Individual Source Applications and Activate Multiple Source Applications. Until a company code's source applications are activated, that company code's flows are simply not in cash management — and the symptom is a forecast that is right for eight company codes and empty for the ninth.

The data layer: One Exposure, Flow Builder, FQM_FLOW

The foundation under all three areas is the One Exposure from Operations hub — the single store of cash-relevant flows in table FQM_FLOW that S/4HANA Cash Management reads from. It has its own article, and a second on reconciling it when the numbers don't tie; here I'll only place the named objects around it.

The Flow Builder distinction is the one to get right early, because SAP states it as a one-way door: Flow Builder Plus is enabled by activating "Optimized data model and algorithm" in Define Basic Settings, and once activated, it is not possible to switch back to Flow Builder. That belongs in the same paragraph of your design document as the business function warning, for the same reason.

Flow types are how One Exposure knows what a flow is. SAP predefines them, and publishes the derivation for accounting-document items — which is exactly the sort of thing dump sites paraphrase and get wrong, so here it is as SAP documents it:

And the classification behind them is table-level, not conceptual: SAP determines "cash in transit" from G/L accounts maintained in payment-program account determination (T042I) or bank-to-bank transfer determination (T042Y) that are balance sheet accounts (SKA1-XBILK) and not reconciliation accounts (SKB1-MITKZ), or from accounts flagged cash-relevant (SKB1-XGKON) with open item management (SKB1-XOPVW); "cash" from accounts in house bank accounts (T012K) or cash-relevant without open item management. When a flow doesn't appear in the position and the reconciliation walk runs dry, that field list is the next place to look.

Bank Account Management, and the governance objects under it

BAM manages bank accounts as master data — every account, its attributes, its signatories — with review and, in full scope, workflow-driven opening, closing and change processes. It's the SAP home for the account-inventory and governance discipline every treasury needs: one controlled record of every account and who can act on it — the more so when In-House Cash replaces external accounts with internal ones, leaving fewer to govern in the first place.

Two attributes are mandatory on every bank account, and confusing them is a standing design error: the account type says what business operation the account is for and you define it yourself; the contract type says what the contractual relationship with the provider is, is predefined by SAP, and forms part of the logical key that uniquely identifies a bank account. Each account type is assigned to one contract type; a contract type can carry many account types.

The workflow objects, for when someone asks "who approves what, and where is that configured":

Account lifecycle status codes are equally concrete — Inactive (01), Withdrawn (99), Application Approved (22), Pre-Opening Preparation (24) among them — and they matter because "inactive bank accounts cannot be used in business operations" is the answer to a support ticket you will otherwise spend an afternoon on.

The cloud read path: released CDS views

Table access is an on-premise and private-edition concern. In S/4HANA Cloud you get released CDS views instead, and SAP publishes the list — which makes it the sanctioned read path for reporting and for SAP Analytics Cloud, exactly as FTI_TR_* is on the treasury side:

One precision on that last column, because SAP prints two of them and they are not interchangeable: ILPCUBE and CLPOSQ are extractor DataSources, while the 2C* names are the DataSources for use in SAP Analytics Cloud and other analytical clients. The pattern otherwise holds throughout: an I_* cube or dimension view, a C_* query view on top of it. If you're being asked to "just read the table" in a cloud system, this table is the polite answer.

What changed from classic

For those of us who cut our teeth on classic Cash Management, the honest map of what's different:

• The data model. Classic maintained its own summary records, updated as documents posted. S/4HANA reads from One Exposure instead — a genuinely different foundation, not a reskin.
• The tools. Much of the classic transaction-driven work moves to Fiori apps; the table above maps which app replaces which transaction.
• The organization. Reorganized into the three areas above, with the master-data half renamed Bank Relationship Management.
• The scope decision. Classic had no equivalent of the basic/full split, and the split is now a licence conversation with an irreversible switch in it.

The concepts a treasurer cares about — position, forecast, account control — all carry over. What changes is everything underneath, which is exactly why "we're just upgrading Cash Management" is the sentence that sinks the plan. The ECC-to-S/4HANA article covers which of your existing reads survive.

What I left out, on purpose

• The physical tables behind the apps, beyond the ones SAP names. FQM_FLOW, FDES, FDSB, FCLM_BAM_AMD and the FEB* bank-statement ring are documented and are in the tables reference. The rest of the cash-management persistence layer is not documented anywhere I could verify, so it isn't here.
• Fiori app IDs I couldn't pin. Several apps in this area (Manage Cash Pools, Monitor Bank Account Balances, Manage Liquidity Item Hierarchies among them) have SAP Help pages that document the app without printing an app ID. They're real and they're named above where relevant, but no ID is inferred for them.
• Cloud Public Edition scope items and release dates. Availability differs by edition and release, and a scope-item number stated from memory is exactly the kind of detail that ages badly. Check your own release notes.
• Liquidity planning with SAP Analytics Cloud. A different product boundary and a different article; naming it here without space to do it justice would be padding.

Where this guide goes next

This is the map; the next articles walk the territory — starting with One Exposure from Operations and FQM_FLOW, because until that clicks, everything else in S/4HANA Cash Management feels arbitrary. Then Flow Builder, liquidity items and derivation, planning levels, and the bank-statement and BCM side. When a number won't tie, the FQM_FLOW reconciliation & troubleshooting guide is the method; and for scoping a whole implementation, the module-selection roadmap sequences it.

See also what is SAP Treasury and Risk Management and building a daily cash position.