# FQM_FLOW Reconciliation & Troubleshooting in S/4HANA

Source: https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting
Author: Tan Gravam
Published: 2026-07-28
Updated: 2026-09-02
Reviewed: 2026-09-02
Summary: When a cash flow is missing or wrong in S/4HANA, the answer is in FQM_FLOW. A triage guide: why a flow is invisible, which source to check, when to rebuild.

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

1. **Should a flow exist?** — is the source document genuinely cash-relevant, and did the derivation that makes it so actually fire?
2. **Does the flow exist in `FQM_FLOW`?** — did the source application's integration write it into One Exposure?
3. **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's **Reconcile Cash Flows** app is not that tool: it matches forecasted flows (memo records) against the bank-statement flows that realise them — forecast versus actual, not source document versus One Exposure. The source-to-flow comparison is the one described here: the source application's own documents and reports on one side, the `FQM_FLOW` rows for the same scope and horizon on the other.

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

1. **Scope tightly.** One company code, one date range, one source application. A gap you can't localise is a gap you can't fix.
2. **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).
3. **Classify each difference** using the triage table: relevance, timing, mapping or rebuild.
4. **Fix the cause at the source or the config** — never by editing the position.
5. **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](https://gravam.com/blog/treasury-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.

***

_See also [One Exposure from Operations & FQM_FLOW explained](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

SAP S/4HANA — app names, transactions and reconciliation tools differ by release and between on-premise and Cloud; verify against the documentation for your system.

- SAP Help — One Exposure from Operations (SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/abd32554225fea6fe10000000a423f68.html
- SAP Help — Flow Builder (Cash and Liquidity Management) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/835cc0f9ff554154bf06245b70c4c79b.html
- SAP Help — Reconcile Cash Flows (forecast-to-bank-statement matching, SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/eb100328e8464540b2616356eec2f62f.html

## Questions this article answers

**Q: 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.

**Q: 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's Reconcile Cash Flows app does not do this comparison — it matches forecasted flows (memo records) against bank-statement flows, which is forecast-versus-actual rather than source-versus-One-Exposure. 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).

**Q: 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.