One Exposure from Operations & FQM_FLOW Explained

One Exposure from Operations is the hub at the centre of S/4HANA Cash Management — a single store (the table FQM_FLOW — where it sits among the treasury tables) where every cash-relevant flow lands, so the cash position, the liquidity forecast and the reporting all read from one source. If you understand nothing else about S/4HANA Cash Management, understand this: SAP replaced the old world of cash management keeping its own separate summary records with a single hub that everything feeds and everything reads. Get this one idea and the whole module stops feeling arbitrary. Miss it, and you'll spend the project fighting symptoms — a position that doesn't tie, a forecast missing flows — without seeing the cause.

What it actually is

Every treasury architecture needs a single source of truth for its numbers. One Exposure from Operations is SAP's answer to that need for cash: instead of many systems each keeping their own view of cash-relevant activity, they all feed one hub, and everything downstream reads from it. FQM_FLOW is where that hub lives — the table that holds the flows.

That's the concept in a sentence. The reason it's worth an article is that the implications are large, and the documentation states the concept without walking you through them.

Why it exists

Classic Cash Management maintained its own summary records, updated as documents posted. It worked, but it meant cash management held a derived, separate copy of reality — and separate copies drift, need reconciling, and quietly disagree with the source. Anyone who ran classic knows the feeling: the position looks wrong, and now you're reconciling cash management's records back to the documents that fed them.

One Exposure narrows that class of problem sharply. Instead of cash management holding its own parallel summary, there's one store of flows — fed from the operational sources — that the position and forecast read directly. It's the system-of-record discipline applied inside SAP: one collection point everything downstream trusts, rather than competing summaries maintained in parallel.

What it does not do is make reconciliation disappear. FQM_FLOW is still derived operational data: it's populated from the source applications, and SAP ships initialization, deletion and rebuild tools precisely because those flows can need regenerating or reconciling when configuration or postings change. The win isn't "nothing to reconcile ever" — it's "one place to reconcile, not many disagreeing copies."

What feeds it

The value of the hub is only as good as what lands in it — so the first question on any implementation is what flows into FQM_FLOW, from where, and by which route? The sources are the operational systems that generate cash-relevant activity: financial documents, purchasing and sales activity, treasury deals from TRM, loans, manual/memo records, and bank statement items, among others. Each relevant flow is collected into the store so the whole cash picture is built from one consolidated set.

The important nuance is that they don't all arrive the same way. FI and MM documents are turned into flows by Flow Builder; the other applications each activate as their own source application with its own integration. So "what feeds One Exposure" is really several integrations, not one — and that matters the moment a number looks wrong.

The route matrix below is a map of the main ones — for a flow that's missing or wrong, it tells you which integration to check first. SAP's own list of source applications is longer than this; treat the table as the routes you meet most, not a complete inventory:

The pattern the matrix encodes: Flow Builder owns the FI/MM route; the other applications each bring their own. But don't turn that into "Flow Builder is never involved elsewhere", because the forecast and the actual take different paths. TRM and loans feed One Exposure with the expected flows from the deal or contract; when that deal settles and posts, the resulting FI document is Flow Builder's territory — SAP documents the financial-accounting Flow Builder analysing the document flow back to the source (original) document. Bank statements are the same shape: end-of-day statements are their own source application, but a statement that posts produces FI flows built by Flow Builder, and which branch you get depends on posting category and transfer mode. Intraday statements don't have a route of their own at all — they arrive as memo records.

So the question to ask first is whether you're chasing a forecast flow or a posted one. Forecast points you at the source application; posted points you at FI, and therefore at Flow Builder. Verify the exact routes for your release against SAP's documentation, since integration details differ by release and edition.

The practical consequence: if a source isn't feeding One Exposure correctly, the flow simply isn't in the position — and it fails silently, exactly like the interface failures that plague any treasury landscape. Knowing what feeds the store, and by which route, is knowing what your numbers are made of.

Flow Builder

Flow Builder (and Flow Builder Plus) is the mechanism that generates flows from FI and MM documents and writes them into One Exposure. It's the bridge between the accounting/logistics world and the cash store — but it's not the single pipe for everything. Treasury deals, loans and sales activity each activate as their own source application and feed their expected flows in directly, without Flow Builder.

Where that framing gets people into trouble is the word "instead". Those integrations carry the forecast. The moment the underlying deal, loan or statement actually posts, you have an FI document, and FI documents are Flow Builder's job — SAP's financial-accounting Flow Builder traces the document chain back to the source (original) document, so the flow keeps the account assignment it really came from. So a TRM-originated number can legitimately be a Flow Builder question; it depends on whether you're looking at what's expected or what's posted.

That distinction is practical, not pedantic. When people ask "why is this flow in the position?" or "why isn't it?", the first move is to identify which source the flow should come from and which stage it's at — the source application's integration for an expected flow, Flow Builder for anything that has already hit FI. Reaching straight for Flow Builder every time is how you waste an afternoon; assuming it's never involved outside FI/MM is how you waste the afternoon after that. The full method — why a flow is invisible, which source to check, when to rebuild — is in the FQM_FLOW reconciliation & troubleshooting guide.

Actuals and forecast in one place

Because the hub holds cash-relevant flows with their timing, One Exposure naturally supports both the actual cash position and the forward-looking liquidity forecast — they're different views over the same underlying flows rather than two separate builds. That's a big part of why the S/4HANA design is cleaner than classic once you understand it: the position and the forecast stop being two things you maintain and become two lenses on one source.

The model that makes it click

Hold these three sentences and most of S/4HANA Cash Management falls into place:

1. There is one store of cash-relevant flows — One Exposure, in FQM_FLOW.
2. Several integrations fill it — Flow Builder for FI/MM and for anything that has posted to FI, and each other application (TRM, loans, SD, bank statements, memo records) feeding its expected flows through its own route.
3. The position and forecast are views of it, not separate copies you maintain — though the store itself is still derived and can be rebuilt.

Everything else — liquidity items, planning levels, the reporting — hangs off that spine.

Where One Exposure bites

• Treating it as a black box. Trusting the hub without understanding what feeds it, so a missing or wrong source is discovered late, as a wrong position.
• Not knowing the sources. No clear picture of what flows into FQM_FLOW, so no one can explain — or fix — a number that looks off.
• Carrying classic assumptions across. Expecting cash management to hold its own reconciled records, and being confused when the model is "views over one hub" instead.
• Under-scoping the integrations. Assuming Flow Builder brings in everything, so the TRM, loan or bank-statement flows that feed One Exposure through their own routes get missed — and go-live reveals flows that never arrive.
• Ruling Flow Builder out too early. The mirror-image mistake: assuming Flow Builder is never involved outside FI/MM, so a posted TRM, loan or statement flow — which reaches FQM_FLOW as an FI document, built by Flow Builder — gets chased in the wrong integration.
• Assuming it never needs reconciling. Treating FQM_FLOW as if it can't drift because it's "the single store" — when it's derived data with initialization, deletion and rebuild tools for exactly the cases where it does.

Understand One Exposure as the single store, know which integration feeds each flow into FQM_FLOW, and treat the position and forecast as views of it — and S/4HANA Cash Management stops being a maze and becomes a clean, single-source design. It's the idea the whole module is built on, and the one the documentation most assumes you already have.

See also SAP Cash Management in S/4HANA and the treasury system of record.