SAP S/4HANA Cash Forecasting, End to End

Cash forecasting in SAP S/4HANA isn't a separate calculation. It's a view over One Exposure from Operations: flows from the source applications land in FQM_FLOW, a flow type labels each one forecast or actual, and a liquidity item says what the cash is for. The Cash Flow Analyzer and Liquidity Forecast apps read that store for the short and medium term, and SAP Analytics Cloud handles the longer-range plan. Everything that goes wrong with an SAP cash forecast goes wrong at one of those joints, and nothing in the standard setup measures whether the forecast was right. You have to switch that on.

The cash management map lists the objects. This page follows a single flow through them, from the document that creates it to the accuracy report that should, eventually, judge it.

The chain, stage by stage

Stages 1 to 3 are configuration. Stage 4 is where cash managers work every day. Stages 5 and 6 are where designs go thin, and they're the reason for this article.

Stage 1: where the forecast data comes from

The forecast is only as complete as the list of things feeding One Exposure. In practice that means:

• Open receivables and payables from FI, which Flow Builder turns into flows dated by the document.
• Purchasing and sales activity: MM documents through Flow Builder, and sales through its own source application.
• Treasury deals and loans: the expected flows from the contract, each through its own integration.
• Memo records for anything the system can't see yet (Manage Memo Records, F2986).
• Bank statements, which turn expected flows into confirmed ones.

Two consequences shape everything after this. First, a system forecast only reaches as far as the documents do. A receivable that hasn't been invoiced, a payroll run that hasn't been posted and a tax payment that's merely known about aren't in the store, so the further out you look, the more of the real cash picture is simply absent. That isn't a defect. It's why SAP puts a planning layer on top.

Second, a system forecast uses contractual dates, not behaviour. An open item enters the forecast on the date its document gives it. If a customer habitually pays three weeks late, the forecast doesn't know that, and the gap shows up in the next stage as an ever-growing overdue column. When a flow you expect is missing, the FQM_FLOW reconciliation guide is the method.

Stage 2: what counts as actual

SAP settles "forecast or actual?" with one field. SAP's documentation states that certainty levels indicate the reliability of a forecasted cash flow and are predefined by SAP, and that a flow type's flow level attribute determines the certainty level a flow gets. Flow types are derived automatically when accounting documents post, which is why assigning flow types to G/L accounts is structural rather than cosmetic.

The certainty level to know is ACTUAL, the one that represents an event that has really happened: cash confirmed by the bank, posted and reconciled. SAP's own write-up of the Cash Flow Analyzer lists the other certainty levels it treats as forecast in its overdue logic (MEMO, FICA, CMIDOC, TRM_O, TRM_D and SI_CIT), and SAP Help documents CMIDOC and ACTUAL as the levels used for classic Cash Management data arriving from distributed systems.

That gives you a working vocabulary that's more precise than "forecast" versus "actual":

The overdue column is the most underused number in SAP cash management. According to SAP's description of F2332, it sums the forecast certainty levels dated before the date you enter, and the first data column adds them onto that day's forecast. So an overdue column that grows every week is a forecast-quality metric sitting in plain sight: flows the system still expects, dated in the past, that nobody has confirmed, cleared or written off. If the cash team rolls those amounts into "today" without looking, the forecast inherits every stale expectation in the ledger.

Stage 3: what the cash is for

Amounts without meaning don't support a decision. Liquidity items give each flow its purpose (customer receipts, supplier payments, payroll, tax, financing). SAP describes them as an import dimension for financial planning, and that phrase is doing a lot of work. The liquidity item is the join key between the operational forecast in S/4HANA, the plan in SAP Analytics Cloud and the actuals you'll compare both against. Design it once, for all three, or you'll spend every month-end mapping one category structure onto another.

Two health checks belong in the forecast runbook: the share of flows landing in the unassigned item (Check Cash Flow Items, F0735, is where you count it), and whether TRM, loans and other hub data have derivation rules at all. SAP ships no default derivation for data that source applications integrate into One Exposure, so without rules those flows arrive with no liquidity item.

Stage 4: the short and medium term in the apps

Two apps carry the operational forecast:

• Cash Flow Analyzer (F2332) reads everything it shows from FQM_FLOW. It's the flexible one: any horizon, any grouping, drill-down to the flow, with actual, position and forecast in one place. For most cash teams it's the daily working tool.
• Liquidity Forecast (F0512A) is the trend view. SAP describes it as forecasting the liquidity trend for the following 90 days, with drill-down by dimensions such as company code, currency and liquidity item.

Don't read the ninety days as a promise of coverage. Near the front of that window, most of the cash that matters already has a document, a deal or a memo record, so a document-driven forecast is a reasonable instrument. Towards the back, less and less of it does: next month's sales aren't invoiced yet. That's why the later weeks of a 13-week forecast can't be assembled from the system alone. They need planning input, with the system's actuals as the anchor.

"

A document-driven forecast can only see cash that already has a document. Past the point where the documents run out, the forecast is a plan, and it needs a planning tool.

Stage 5: SAP Analytics Cloud for the long range

SAP's answer for the long range is liquidity planning in SAP Analytics Cloud, delivered as SAP Best Practices content ("Liquidity Planning for SAP S/4HANA Cloud"). Stripped of the marketing, here's what SAP's documentation and its own descriptions of that content establish:

• Once the connection between S/4HANA and SAC is set up, liquidity plans are built in SAC on data sources integrated from S/4HANA. The actuals come from the same One Exposure world the apps read.
• The content compares versions such as Forecast, Actual, Optimistic Forecast and Pessimistic Forecast, so variance between plan and outcome is part of the design rather than an afterthought.
• There are two ways to generate the forward view: a predictive approach using SAC's Smart Predict on historical cash flows, and a rule-based approach that turns financial plans into liquidity using distribution, currency and shift rules (for example DSO, DPO and VAT timing). Both are followed by manual adjustment of the liquidity items the models don't predict well.
• In SAP S/4HANA Cloud Public Edition, plan data travels back from SAC through the Manage Financial Plan Data Jobs for SAP Analytics Cloud Integration app and its scheduling counterpart. SAC is the source, S/4HANA the target, and liquidity planning is among the supported targets.

The design decision that matters most isn't in any of those bullets. Decide which horizon each layer owns, and don't let them overlap unmanaged. A common, defensible split: the S/4HANA apps own the operational horizon, built from documents; SAC owns the months beyond, built from plans and models; and the handover point is a fixed rule, not a mood. Where the two overlap, one of them has to be the forecast of record. Otherwise treasury and FP&A will each quote a different number and both will be right about their own system. That's the ownership question in SAP clothes.

Smart Predict is SAP's own machine-learning layer on this problem. It deserves the same scrutiny as any model in the forecast, which the AI cash forecasting teardown sets out: model output feeds the forecast, a named human owns the forecast.

Stage 6: measuring accuracy, which you have to switch on

This is the gap most SAP designs leave open. Measuring forecast accuracy means comparing what you forecast for a date, some weeks before it, with what actually happened on it, by category and by horizon. One Exposure answers the second half easily: filter on ACTUAL. It can't answer the first half by default, because the store holds the current state of each flow. By the time a receivable has cleared, the flow that forecast it has moved on.

SAP's fix is the snapshot function, and it's easy to miss:

SAP states the purpose plainly: snapshot exists so a cash manager can see what was forecast at a point in time and justify yesterday's decision. That's also exactly what an accuracy measure needs. The method follows:

1. Fix your measurement horizons (say one, four and thirteen weeks).
2. For each target date, read the forecast as it stood at the snapshot one, four and thirteen weeks earlier.
3. Read the ACTUAL flows for the same date.
4. Compute variance, bias and hit rate by liquidity item, because the category is where the fix lives.

Two design consequences are easy to get wrong. Retention has to match the longest horizon you measure. If you clean up snapshots weekly, there's no thirteen-week accuracy to report. And snapshot volume grows with lifetime, which is why SAP ships the cleanup program: decide the retention with your basis team at design time, not after the table has grown.

For the SAC horizon the same logic runs through versions. Freeze the forecast version each cycle, keep it, and compare it with the Actual version once the period closes. A plan that is overwritten every month can be kept current, but it can never be judged.

What I would decide

• Treat the liquidity item structure as the forecast's schema, shared by the S/4HANA apps, SAC and the accuracy report.
• Monitor the overdue column weekly and give someone the job of clearing stale forecast flows.
• Give each horizon one owner: documents and apps for the operational window, SAC for the long range, with a written handover rule.
• Switch snapshot on at go-live if you're on full scope, with retention set by the longest accuracy horizon you intend to report.
• Measure accuracy by liquidity item and horizon from the first month, because an accuracy history can't be rebuilt afterwards.

The forecast in S/4HANA is only ever as good as what flows into FQM_FLOW and how honestly the result is scored against actuals. The platform handles the first part. You have to switch on the second.

See also planning levels and planning groups in SAP and direct vs indirect cash flow forecasting.