Why is a cash flow missing from the cash position in S/4HANA?

Because the flow never made it into FQM_FLOW — the single store One Exposure from Operations reads from. The usual causes are: the source document isn't flagged as cash-relevant (planning level, flow type or liquidity-item derivation didn't fire), the source application's integration into One Exposure isn't active or configured, the flow was generated but with a value date or account that puts it outside the view you're looking at, or the flows haven't been rebuilt after a configuration change. The position isn't wrong so much as reading faithfully from a store that's missing a row. Fixing it means finding which source should have produced the flow and why it didn't, not adjusting the position.

How do you reconcile FQM_FLOW against the source documents?

You compare what's in One Exposure (FQM_FLOW) against the operational documents that should have fed it — FI documents, purchase orders, sales orders, treasury deals, bank statement items — for the same scope and horizon. SAP provides reconciliation apps (such as Reconcile Cash Flows) to compare cash-management flows against their sources and surface differences. The discipline is to reconcile per source application: a difference is always 'this source produced X, One Exposure holds Y', so you isolate the source, then the document, then the reason (relevance, timing or a failed rebuild).

When should you rebuild the cash flows in S/4HANA Cash Management?

After anything that changes how flows are derived: new or changed liquidity-item or flow-type configuration, a corrected planning level, activation of a source application, or a data fix in the source. Because FQM_FLOW is derived operational data, SAP provides initialization, deletion and rebuild tools precisely so the store can be regenerated to match the current configuration. Rebuild is a deliberate, scoped operation — not a daily habit — and in a production system it's planned, tested in a non-production client first, and run for the narrowest scope that fixes the problem.

FQM_FLOW Reconciliation & Troubleshooting in S/4HANA

When a number is wrong in S/4HANA Cash Management, you don't debug the cash position — you debug FQM_FLOW. One Exposure from Operations made the module a single-source design: every cash-relevant flow lands in one store, and the position, the forecast and the reporting are all views of it. That's the good news and the whole troubleshooting method in one sentence. A position that doesn't tie isn't a broken position — it's a faithful view of a store that's missing a row, holding a stale one, or holding one with the wrong date. Find the row, and you've found the bug.

This is the guide the standard documentation doesn't quite write: not what One Exposure is, but what to do at 6pm when the position is short by a number nobody can explain.

The one mental model that makes this tractable

Every troubleshooting question collapses into three:

Should a flow exist? — is the source document genuinely cash-relevant, and did the derivation that makes it so actually fire?
Does the flow exist in FQM_FLOW? — did the source application's integration write it into One Exposure?
Is the flow in the view you're looking at? — value date, currency, bank account, liquidity item: a flow that exists can still sit outside the position or forecast slice on screen.

Almost every "the number is wrong" reduces to a no at exactly one of these steps. The skill is finding which one, fast — and resisting the urge to "correct" the position, which only hides the cause until it recurs.

Why a flow is invisible: the triage table

Work it top to bottom. Each row is a symptom, its usual cause, and where the answer lives.

Symptom	Most likely cause	Where to look
Document posted, but no flow at all	Source not cash-relevant — planning level / flow type / liquidity-item derivation didn't fire	Source document's cash-management assignment; derivation config
Whole source application missing	That source's integration into One Exposure isn't active or configured	One Exposure source/integration setup for that application
Flow exists but not in this position	Value/planning date puts it in a different horizon than the view	The flow's date fields vs the position's date basis
Flow in wrong liquidity item / bucket	Liquidity-item derivation rule maps it elsewhere	Liquidity-item derivation; the flow's assigned item
Right amount, wrong bank account	Account assignment on the source or house-bank-account mapping	Source document bank data; house bank account master
Number was right yesterday, wrong today	Config changed but flows not rebuilt, or a source correction not reflected	Change history of derivation config; rebuild status
Duplicated flow / double-counted amount	Two sources feeding the same economic event, or a partial rebuild left a stale row	Source of each flow; last rebuild scope

The pattern to internalise: a wrong number is almost never a Cash Management bug — it's a source, a derivation rule, or a rebuild that didn't run. Cash Management is doing exactly what it was told.

Reconcile per source, never in aggregate

The instinct when a position is off is to reconcile the position against the bank or the ledger. That tells you that there's a gap, not where. One Exposure's whole point — many sources, one store — gives you a better method: reconcile each source application against its flows in FQM_FLOW, one at a time.

FQM_FLOW is fed from several sources — financial accounting, purchasing and sales, Treasury and Risk Management, loans, bank statement items, memo records — each through its own integration, not one universal pipe. So a difference is always specific: "FI produced these documents, One Exposure holds these flows, here's the delta." SAP ships reconciliation apps (for example Reconcile Cash Flows) precisely to compare cash-management flows against their sources and surface the differences.

Reconcile the source to its flows, not the position to the bank. The position tells you there's a problem; the source-to-flow reconciliation tells you which document, in which application, for which reason.

A working order of attack:

Scope tightly. One company code, one date range, one source application. A gap you can't localise is a gap you can't fix.
Reconcile that source to its flows. Use the reconciliation app for the source; list documents with no matching flow (and flows with no matching document — that's your duplicate/stale hunt).
Classify each difference using the triage table: relevance, timing, mapping or rebuild.
Fix the cause at the source or the config — never by editing the position.
Re-reconcile to prove the delta is gone, then move to the next source.

Duplicates and stale flows: the quieter failure

A missing flow is loud — someone notices the position is short. A duplicate or stale flow is quiet: the position looks plausible, just wrong, and nobody questions a number that isn't obviously broken. Two causes dominate:

Two sources for one economic event. The same underlying cash movement integrated by two paths, so it lands twice. This is a design/configuration question — which source owns that flow — and it ties directly to naming a single system of record for each data domain.
A partial or failed rebuild. Flows deleted and regenerated for one scope but not cleanly, leaving orphans from the old derivation alongside the new ones.

Hunt these from the flow side: flows in FQM_FLOW with no matching current source document are your candidates. They rarely surface on their own — you have to go looking, which is why a periodic source-to-flow reconciliation belongs in the operating routine, not just the incident.

When (and how) to rebuild

Because FQM_FLOW is derived operational data, SAP provides initialization, deletion and rebuild tools — and the reason they exist is the reason you sometimes need them: change how flows are derived, and the existing store no longer matches the rules. Rebuild after:

new or changed liquidity-item or flow-type configuration,
a corrected planning level or derivation rule,
activating a source application's integration,
a data correction in the source that should reflect in cash.

Rebuild is a deliberate, scoped operation, and in production it earns real caution:

Test the rebuild in a non-production client first — same config, representative data — and reconcile the result before you touch production.
Scope it as narrowly as the fix allows. Company code, date range, source. A full-store rebuild is a last resort, not a reflex.
Reconcile before and after. Know the delta you expect to close; prove you closed it and nothing else moved.
Plan it like a change, not a click — timing, approval, a way back. A rebuild that runs at the wrong scope in a live system creates exactly the duplicate-and-stale mess this article is about.

What good looks like

Teams that stay out of trouble treat One Exposure as what it is — a derived single store — and build the habits that follow from that:

A periodic source-to-flow reconciliation across the active sources, run on a schedule, so drift is caught small.
One owner per flow: every economic event integrated by exactly one path, decided on purpose, not discovered in an incident.
Rebuilds as controlled changes, tested and scoped, with before/after reconciliation as the evidence.
Troubleshooting from the store outward — should it exist, does it exist, is it in the view — instead of correcting the symptom on the position.

Do that, and "the position is wrong" stops being a mystery and becomes a lookup: which source, which document, which of three reasons. Skip it, and you'll keep adjusting a position that was only ever telling you the truth about a store you hadn't looked at.

Part of the SAP Treasury & Cash Management guide. See also One Exposure from Operations & FQM_FLOW explained and SAP Cash Management in S/4HANA. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.