Liquidity Items in SAP Cash Management

Liquidity items classify cash-relevant flows by their purpose — customer receipts, supplier payments, payroll, tax, financing — so the liquidity forecast can be read by category, not just as a wall of amounts. SAP's own definition is drier and worth having in your design document: liquidity items "represent the source and use of cash flows in your company" and "serve as an import dimension for financial planning and reporting". Here's why they matter more than they sound: a forecast that says "€40m out next month" is nearly useless; a forecast that says "€18m payroll, €12m suppliers, €6m tax, €4m financing" is something you can act on.

Liquidity items are attached to flows through derivation, and derivation is where projects win or lose this. This page names the objects — the Customizing activities, the query mechanism, the Origin codes and the apps — because "configure the derivation properly" is advice, and a list of the activities you configure it in is a reference.

Before anything else: the scope gate

Liquidity items are not available in every S/4HANA cash management installation. SAP's business function documentation says it flatly for the basic capability: "liquidity item is not supported in the basic cash management capability." They belong to the full scope — SAP S/4HANA Finance for cash management, business function FIN_FSCM_CLM, with Full Scope selected in the Customizing activity Define Basic Settings. The S/4HANA Cash Management overview covers that fork in detail.

I lead with it because it is the cheapest possible discovery and the most expensive possible surprise. A forecast design built on liquidity items, presented to a steering committee, in a system licensed for basic scope, is a bad afternoon.

Where they are configured

Everything below hangs off one branch: Financial Supply Chain Management → Cash and Liquidity Management → Cash Management → Liquidity Items.

Two more activities sit outside that branch and are easy to miss: Define Default Liquidity Items for Liquidity Analysis, under Cash Management → Data Setup, is the generic setting for the Flow Builder Plus program, and the Flow Builder side of the One Exposure pipeline is where the flows you are labelling come from in the first place.

Derivation: the part that is actually a mechanism

The concept is simple; the derivation is the work. SAP splits it into two layers, and the split is the thing to understand:

• If the liquidity item can be determined by the G/L account, use Define Default Liquidity Items for G/L Accounts. That is a lookup table and it covers a surprising amount of a real chart of accounts.
• If you need more complex logic — reading various fields of the accounting document rather than just the account — you define queries and query sequences.

For accounting documents, derivation runs against database table BSEG — the accounting document segment whose join with BKPF has its own article here. And the resolution order is documented, which means you can reason about a wrong result instead of guessing at it:

The system first tries to apply the assigned query sequences; if not successful, then it turns to the default liquidity items defined for G/L accounts.

Query sequences win. The default per G/L account is the fallback, not the baseline. Every "but the account is mapped correctly" support ticket I've seen in this area resolves to a query sequence quietly overriding the account default.

The Origin codes

Origin is the field that tells a query which structure it runs against, and it is the single most-misconfigured setting in the topic:

The mnemonic that keeps it straight: C and D are the two halves of an accounting document — the customer/supplier half and everything else — while X means "I am no longer looking at an FI document at all, I am looking at the hub". SAP states there are no default derivation rules for data integrated into One Exposure from source applications in the central system: for TRM, CML or FI-CA flows you must define queries and query sequences with Origin X, or those flows arrive with no liquidity item at all. That is the usual reason a forecast is well categorised for receivables and payables and blank for treasury deals.

The remote-system special case

Data arriving from remote systems splits again. Classic Cash Management data from remote systems is derived with Origin X like any other hub data. SAP Liquidity Planner actuals are different: their original liquidity item values are transferred into the One Exposure hub as they are — so the item must exist in both the remote and the central system, or the value arrives pointing at nothing. That is exactly what the Import and Export Liquidity Items activity under Cash Management → Tools exists for, and it is the reason that activity is not the administrative footnote it looks like.

Hierarchies: the reporting shape

Individual items are the label; the hierarchy is what makes a forecast readable. Hierarchies are maintained in the Manage Liquidity Item Hierarchies app, and SAP documents the mechanics that matter operationally:

• A hierarchy has an ID, a description and a validity period, and you can add new timeframes under an existing hierarchy ID to stage a planned reorganisation before it takes effect.
• Nodes are either a subnode (a liquidity item that can be a parent) or a liquidity item (a leaf, which cannot take children).
• Hierarchies can be saved in draft and must be activated: "Only activated liquidity item hierarchies can appear in related apps and be used in business."

The draft-and-activate pair is the feature to use rather than route around. It means the honest answer to "can we restructure the forecast categories without breaking this month's reporting" is yes — build the new hierarchy as a new timeframe, activate it when the period turns.

The apps that make it inspectable

F6459 is the one I'd put in front of a team on day one of a derivation clean-up: it lists the G/L accounts with their default liquidity items alongside the account group, the balance-sheet indicator and the open-item-management flag, which is exactly the evidence you need to see why an account behaves the way it does.

F6385 deserves a caution to go with it. A liquidity item transfer generates actual One Exposure flows — the original items are not necessarily changed, the shift is documented as its own movement, and the transfer's line items must net to zero. It is a correcting entry, not an edit. And if the underlying flows are later deleted or aggregated, the transfer's status goes to Invalidated and it can no longer be updated.

For reporting outside the apps, the released CDS views are I_LiquidityItem and I_LiquidityItemText for the master data, with the cash position and liquidity forecast cube I_LiquidityPositionCube and its query C_LiquidityPositionQuery above them.

Why it makes or breaks the forecast

This is the part that surprises people: the liquidity forecast's value doesn't come from the amounts — One Exposure has those. It comes from the categorization. Without good liquidity items, you have a forecast that can total but can't explain; with them, you have one that shows the drivers, supports analysis, and earns trust. It's the SAP expression of a truth from the forecasting side of treasury: a cash forecast is only useful when you can see what the cash is, not just how much.

Businesses change, too. Derivation rules that were complete at go-live drift as new flow types appear, and the "other" bucket quietly grows. Treating derivation as a maintained thing rather than a one-time setup is what keeps the 13-week forecast meaningful over years.

What usually goes wrong

• Incomplete Origin X coverage. FI flows are categorised, TRM/CML/FI-CA flows are not, because nobody defined the Origin X queries SAP says have no defaults.
• Query sequences fighting account defaults. The account mapping looks right and the result is wrong, because a sequence matched first.
• Liquidity Planner items existing in only one system. Actuals arrive with items the central system has never heard of.
• Hierarchies edited in place. Restructuring an active hierarchy instead of adding a timeframe, and breaking the current period's reporting to prepare for the next one.
• Everything in "other." A catch-all that swallows so much the categorization is meaningless — and no scheduled review to notice.

What I left out, on purpose

• The persistence behind liquidity items. SAP documents the released CDS views (I_LiquidityItem, I_LiquidityItemText); the physical tables of the derivation configuration are not documented anywhere I could verify, so no table names are printed here.
• Field-level query definitions. Which document fields are available to a derivation query varies by release and by the structures active in your system; a field list copied from one release is a liability in another.
• The Manage Liquidity Item Hierarchies app ID. SAP's page for it documents the app without printing an app ID, so it appears above without one rather than with a guess.

Design the liquidity item structure to match how the business actually thinks about its cash, get the Origin coverage complete across both FI documents and hub data, and maintain the rules as the business changes — and the forecast becomes the structured, trustworthy, explainable view it's meant to be. Liquidity items are small config with outsized consequence: they're the meaning layer over the amounts.

See also One Exposure from Operations & FQM_FLOW and the 13-week cash flow forecast.