# Liquidity Items in SAP Cash Management

Source: https://gravam.com/blog/liquidity-items-in-sap-cash-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-03
Reviewed: 2026-09-03
Summary: Liquidity items classify cash flows by purpose. The IMG nodes, the derivation queries, the Origin codes D/C/X and the apps — verified against SAP Help.

**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](https://gravam.com/blog/sap-cash-management-s4hana) 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**.

| Customizing activity | What it does |
| --- | --- |
| **Edit Liquidity Items** | Defines the liquidity items themselves |
| **Define Default Liquidity Items for G/L Accounts** | The simple case — the item is determined by the G/L account |
| **Define Queries for Liquidity Item Derivation** | The complex case — read fields of the document to decide |
| **Define Query Sequences** | Orders queries into a sequence |
| **Assign Queries to Query Sequences** | Binds the two together |
| **Import and Export Liquidity Items** (under … → Cash Management → **Tools**) | Creates liquidity items en masse across systems |

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](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) 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](https://gravam.com/blog/02-bkpf-bseg-join) 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:

| Origin | Runs against | Use it for |
| --- | --- | --- |
| `C` | Accounting document line items | Line items with account type **D** (customer) or **K** (supplier) |
| `D` | Accounting document line items | Line items with account types **other than** D or K |
| `X` | The One Exposure from Operations structure | Source-application data (TRM, CML, FI-CA) and classic Cash Management from remote systems |

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](https://gravam.com/blog/sap-transaction-manager).

### 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

| App | App ID | What it gives you |
| --- | --- | --- |
| Cash Flow Analyzer | F2332 | The forecast itself, sliced by liquidity item |
| Check Cash Flow Items | F0735 | The audit of individual flows behind the numbers |
| Check Liquidity Item on G/L Account | F6459 | Displays the default liquidity items set per G/L account, with the account's cash-relevant fields |
| Manage Liquidity Item Transfer | F6385 | Reclassifies flows between liquidity items, documenting the shift |
| Manage Liquidity Item Hierarchies | — | Hierarchies, timeframes, draft and activate |

`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.

> The health check for liquidity items: look at how much of the forecast lands in the catch-all / unassigned category. A little is normal. A lot means the derivation rules aren't keeping up with the business — and every flow in "other" is a flow the forecast can't explain. `Check Cash Flow Items (F0735)` is where you count it.

## 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](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) 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](https://gravam.com/blog/direct-vs-indirect-cash-flow-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](https://gravam.com/blog/13-week-cash-flow-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](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) and [the 13-week cash flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast)._

## Primary sources

Named objects verified against SAP S/4HANA 2025 FPS01 on-premise documentation. Liquidity items require the full scope of Cash and Liquidity Management (business function FIN_FSCM_CLM); SAP states they are not supported in the basic cash management capability. IMG paths are an on-premise/private-edition concern.

- SAP Help — Liquidity Items and Liquidity Item Hierarchies (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/dd0e6156c4b61e58e10000000a4450e5.html
- SAP Help — Business Function: Cash and Liquidity Management (FIN_FSCM_CLM) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c7999f525c5b224fe10000000a445394.html
- SAP Help — Managing Liquidity Item Hierarchies (Cash Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/fbb589ce1f3d40e4913aa45c2aa931e1.html
- SAP Help — Manage Liquidity Item Hierarchies (app) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/e8153e9f3c044856a1f990a550afa050.html
- SAP Help — Check Liquidity Item on G/L Account (app F6459) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/05c6682668aa464c966cd0941c365d88.html
- SAP Help — Manage Liquidity Item Transfer (app F6385) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/4c62e3d1af0348ce8af229bfd4f6e279.html
- SAP Help — CDS Views for Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/be968afbde79451abb255fe123b3a17b.html

## Questions this article answers

**Q: What are liquidity items in SAP?**

Liquidity items are a classification of cash-relevant flows by their purpose or nature — for example customer receipts, supplier payments, payroll, tax, or financing. SAP's own definition is that they represent the source and use of cash flows in your company and serve as an import dimension for financial planning and reporting. In SAP Cash Management they let the liquidity forecast be viewed and analyzed by category rather than as undifferentiated amounts. Each flow is assigned a liquidity item through derivation rules, and they roll up into hierarchies for reporting.

**Q: What is liquidity item derivation?**

Liquidity item derivation is the process by which SAP assigns a liquidity item to each cash-relevant flow, based on the attributes of the underlying document or transaction. SAP configures it in two layers: a simple default per G/L account, and — when the logic needs more than the account number — queries and query sequences that read fields of the accounting document. The system tries the assigned query sequences first and falls back to the default liquidity items defined for G/L accounts. Getting derivation right is critical: if the rules are incomplete, flows land unassigned and the forecast loses its analytical value.

**Q: What do the Origin values D, C and X mean in liquidity item derivation?**

Origin is the field that tells a derivation query which structure it runs against. SAP documents three values for it. Origin C applies to accounting-document line items with account type D (customer) or K (supplier). Origin D applies to accounting-document line items with account types other than D or K. Origin X means the derivation logic is executed against the structure of the One Exposure from Operations hub — which is what you use for data integrated from source applications such as Treasury and Risk Management, Consumer and Mortgage Loans or FI-CA, and for classic Cash Management data integrated from remote systems.

**Q: Why do liquidity items matter for the cash forecast?**

Because a forecast of undifferentiated amounts is nearly useless for decisions — treasury needs to know what the cash is: which inflows are customer collections versus financing, which outflows are payroll versus supplier payments versus tax. Liquidity items provide that categorization, so the forecast can be analyzed, trusted and acted on. They turn the liquidity forecast from a single number into a structured view of the drivers behind it, which is where its real value lives.