# Planning Levels and Groups in SAP Cash Management

Source: https://gravam.com/blog/planning-levels-and-groups-in-sap
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-03
Reviewed: 2026-09-03
Summary: Planning levels ride on G/L accounts, groups on business partners — and both land in BSEG. The IMG nodes, the rebuild activity and the flow types beside them.

**Planning levels and planning groups are how SAP classifies items for cash management — signalling whether a flow is cash-relevant and where it belongs, by its certainty and proximity to cash.** The enduring idea is simple and worth holding onto regardless of release: not every flow is equal in the cash view. Money sitting in a bank account is _certain_ and belongs to the [cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position); an invoice a customer _might_ pay next month is _expected_ and belongs to the [forecast](https://gravam.com/blog/13-week-cash-flow-forecast). Levels and groups route each flow to the right one — levels through the accounts, groups through the business partners.

This page names the objects: what SAP's own definitions say, which IMG activity configures what, where the values land in the database, and what to run when you change an assignment after go-live.

## SAP's own definitions, which are better than the folklore

Worth quoting, because both sentences carry design information the usual summaries drop:

- **Planning level** — "reflects typical financial transactions, for example, posting to a bank account, posting to a clearing account, confirmed or unconfirmed payment notes, and so on. **It explains the origin of the data and thus enables you to better estimate its reliability.**"
- **Planning group** — "represents a group of customers or vendors with particular characteristics, behaviors or risks. With this attribute, you can break down incoming and outgoing payments **according to the amount, the probability of the cash inflow or outflow, and the type of business relationship**."

Read those two together and the design brief writes itself. A planning level answers _where did this number come from and how much do I trust it_. A planning group answers _who is on the other side, and how do they behave_. Everything else in this article is the plumbing for those two questions.

## The configuration

| Setting | Where |
| --- | --- |
| Planning levels & planning groups | IMG → Financial Supply Chain Management → Cash and Liquidity Management → Cash Management → **Planning Levels and Planning Groups** |
| Planning level assignment | On the relevant **G/L accounts** — SAP names bank accounts, bank clearing accounts and payment request accounts |
| Planning group assignment | In the **customer and vendor master records** |
| Rebuild after a change | IMG → … → Cash Management → **Data Setup** → **Rebuild Planning Levels, Groups, Dates in Accounting Documents** |
| House bank / account field status | Financial Accounting → AR/AP → Business Transactions → Incoming Payments → Incoming Payments Global Settings → Make and Check Document Settings → **Define Field Status Variants** |

SAP's sequencing instruction is explicit and often ignored: configure planning levels and planning groups **before** you use SAP S/4HANA Finance for cash management. Doing it afterwards is possible — that's what the rebuild activity is for — but it is a data-repair exercise rather than a setup step.

## Planning levels

**Planning levels** are assigned to **G/L accounts** — particularly bank accounts, bank clearing accounts, and payment request accounts. The level on the account determines how items posting there appear in the cash view: a bank account carries a level meaning "this is actual cash," while a bank-clearing account (payments in transit) carries one meaning "on its way." As money moves through the chain of accounts — clearing to settled — the planning levels are what express its changing certainty in the position.

The payment-request account is the row people forget, and it's the one that matters to a treasury team: [treasury settlements run as payment requests](https://gravam.com/blog/sap-treasury-transaction-codes), so if the payment request accounts carry no planning level, treasury's own outflows are the ones missing from the position.

## Planning groups

**Planning groups** work the other side — assigned to **customer and vendor master records**, classifying the _expected_ flows from those business partners. SAP's definition gives you the three dimensions to group by: amount, probability of the flow, and the type of business relationship. That's a more useful design prompt than "group by significance", because it says out loud that a planning group is partly a **probability** statement, which is exactly what a [direct forecast](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) needs from its inputs.

> The clean way to remember it: **levels ride on accounts, groups ride on business partners.** Levels classify the money you can see (actuals, by account); groups classify the money you expect (from customers and vendors). Between them, every flow — certain or expected — gets placed.

## Where the values actually land: BSEG

Here is the part that turns this from a concept into something you can debug, and it is the answer to "does any of this still work the same way in S/4HANA": **planning level and planning group are fields on the accounting document segment, database table `BSEG`.** SAP says so in the documentation of the Data Setup activity that repairs them:

> With the Data Setup function, you can rebuild the **Planning Level** and **Planning Group** fields in database table `BSEG`. When you change the assignment of planning levels to G/L accounts, or the assignment of planning groups to customers or vendors, you can execute the Data Setup function to fill in the updated planning level and planning group information into the existing BSEG records.

Three consequences worth carrying into a project plan:

1. **The values are stamped at posting time.** Change the assignment on an account or a business partner and every document already posted keeps the old value until you rebuild.
2. **The rebuild is a named, supported activity**, not a note-based repair — _Rebuild Planning Levels, Groups, Dates in Accounting Documents_ under Cash Management → Data Setup. It sits beside its siblings _Rebuild Flow Types in Accounting Documents_ and _Rebuild Liquidity Items in Accounting Documents_, which do the same job for the other two classifiers.
3. **`BSEG` is where you look when the position is wrong**, and it's the same table the [BKPF/BSEG join article](https://gravam.com/blog/02-bkpf-bseg-join) covers. Two neighbouring fields belong in the same query: `HBKID` (house bank) and `HKTID` (house bank account), which SAP documents inserting into `BSEG` through _Insert House Bank and House Bank Account Data to Accounting Documents_. And because both are optional fields in payments and bank statements by default, SAP suggests making them mandatory for bank and bank-clearing G/L accounts via **Define Field Status Variants** — one of the cheapest data-quality wins in the whole module.

## The classifier that joined them: flow types

The honest S/4HANA answer isn't "planning levels might have changed"; it's that they were **joined** by a second classifier. S/4HANA Cash Management is built on [One Exposure from Operations](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), and One Exposure classifies by **flow type**: "flow types classify the lifecycle of cash flows, for example, it distinguishes forecasted cash flows from confirmed cash flows. Only transaction data that is assigned with flow type information can be consumed and used in Cash Management applications."

SAP predefines the set, and publishes both the numbers and the derivation:

| Category | Flow types |
| --- | --- |
| Receivable/payable | 600000, 600001 (regular increase); 600200, 600201 (unallocated increase) |
| Revenue/expense | 600500, 600501 (increase); 600510, 600511 (decrease) |
| Tax | 300000, 300001 (increase); 300010, 300011 (decrease) |
| Cash in transit | 800006 (incoming), 800008 (outgoing) |
| Cash | 900006 (incoming bank confirmed), 900008 (outgoing bank confirmed) |
| Payment request | 700000 (incoming), 700001 (outgoing) |

And the categories are determined from account configuration, not from judgement — which is why two systems with the same chart of accounts can behave differently:

- **Receivable or payable** — items from invoices with account type `K` (vendor) or `D` (customer).
- **Cash in transit** — 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 accounts flagged cash-relevant (`SKB1-XGKON`) **with** open item management (`SKB1-XOPVW`).
- **Cash** — G/L accounts maintained in house bank accounts (`T012K`), or flagged cash-relevant **without** open item management.

Accounting documents containing items other than these are not handled by the Financial Operations integration into One Exposure at all. If you need an exception in, the activity is **Assign Flow Types to G/L Accounts** under Cash Management → Flow Types — with SAP's own caution attached: do not assign flow types to a G/L account characterised as a reconciliation account.

So the mental model for a modern build: **planning level and group say how reliable a flow is and who it is with; flow type says what stage of its life it is in.** Both are stamped on the document, both have a rebuild activity, and both are prerequisites for the [S/4HANA cash position and forecast](https://gravam.com/blog/sap-cash-management-s4hana) to be right.

## What usually goes wrong

- **Wrong levels on accounts.** Bank and clearing accounts carrying levels that misplace their items, so the position or forecast is subtly wrong — and nobody notices until a treasurer questions a number they already knew.
- **No planning level on payment request accounts.** Treasury's own settlements go missing from the position, which is a memorable way to lose credibility with the people who asked for the system.
- **Assignments changed without a rebuild.** New configuration, old documents, and a position that is right going forward and wrong looking back.
- **Neglected planning groups.** Business partners left in a default group, so the forecast can't distinguish expected flows by probability or relationship — the exact breakdown SAP designed the field for.
- **House bank fields left optional.** `HBKID`/`HKTID` empty on the postings that needed them, and a bank-level view of the position that doesn't reconcile.

## What I left out, on purpose

- **Specific planning level codes and their meanings.** These are customer configuration, not SAP-delivered constants; any list of "the standard levels" is somebody's project, not a standard.
- **The Cloud Public Edition configuration path.** The same settings exist there, reached through configuration apps rather than SPRO; naming a specific app from memory is how references go stale.
- **How planning levels interact with each source application in One Exposure.** SAP documents the accounting-document path in detail (above) and treats the others separately; I've kept to what's documented rather than generalising a rule across source applications.

Understand levels and groups as the _certainty and counterparty classifier_ — levels on accounts, groups on partners, both stamped into `BSEG` — and flow types as the _lifecycle classifier_ that One Exposure needs, and the cash position and forecast populate correctly. When they don't, the rebuild activities under Cash Management → Data Setup are the first place to go, not the last. The [ECC-to-S/4HANA article](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana) covers what else changes underneath a migration.

***

_See also [One Exposure from Operations & FQM_FLOW](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) and [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana)._

## Primary sources

Named objects verified against SAP S/4HANA 2025 FPS01 on-premise documentation. IMG paths and BSEG field names are on-premise/private-edition concerns; in SAP S/4HANA Cloud Public Edition the same settings are reached through configuration apps, not SPRO. Flow type numbers are SAP's predefined set — confirm against your own system before designing on them.

- SAP Help — Planning Levels and Planning Groups (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/12106156c4b61e58e10000000a4450e5.html
- SAP Help — Build Key Information in Accounting Documents (Cash Management Data Setup) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/91779647befa432ba9c1d4c67e6e83e0.html
- SAP Help — Flow Types (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/a00d6156c4b61e58e10000000a4450e5.html
- SAP Help — Field Status (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/ff106156c4b61e58e10000000a4450e5.html
- SAP Help — Set Up Cash Management Data (SAP S/4HANA, One Exposure) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/1ab55956b967c841e10000000a44147b.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

## Questions this article answers

**Q: What are planning levels in SAP cash management?**

A planning level reflects a typical financial transaction — posting to a bank account, posting to a clearing account, a confirmed or unconfirmed payment note — and SAP's documentation says its purpose is to explain the origin of the data so you can better estimate its reliability. Planning levels are assigned to relevant G/L accounts, in particular bank accounts, bank clearing accounts and payment request accounts, so that items posting to those accounts are routed to the right place in the cash position or liquidity forecast. They classify by certainty and proximity to cash.

**Q: What is the difference between a planning level and a planning group?**

A planning level is assigned to G/L accounts and controls how items on those accounts appear in the cash position and liquidity forecast. A planning group is assigned to customer and vendor master records and classifies expected flows from those business partners; SAP defines it as a group of customers or vendors with particular characteristics, behaviours or risks, letting you break down incoming and outgoing payments by amount, by the probability of the inflow or outflow, and by the type of business relationship. Levels work through the accounts; groups work through the business partners.

**Q: Where are planning levels and planning groups configured in S/4HANA?**

Under Financial Supply Chain Management, Cash and Liquidity Management, Cash Management, Planning Levels and Planning Groups in the implementation guide. SAP's instruction is to configure them before you use SAP S/4HANA Finance for cash management. You then assign planning levels to the relevant G/L accounts and specify the planning group in the customer and vendor master records. A separate Data Setup activity, Rebuild Planning Levels, Groups, Dates in Accounting Documents, refills those fields on documents that were already posted.

**Q: Do planning levels still apply in S/4HANA cash management?**

Yes, and the mechanism is documented rather than assumed. Planning level and planning group are fields on the accounting document segment, database table BSEG, populated from the G/L account and the business partner master when the document posts. SAP ships a Data Setup activity called Rebuild Planning Levels, Groups, Dates in Accounting Documents that refills those BSEG fields when you change the assignments. Alongside them S/4HANA adds flow types, which classify the lifecycle of a cash flow for One Exposure from Operations, so the two classifications coexist rather than replace one another.