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 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 integrate through their own source-specific mechanism. So "what feeds One Exposure" is really several integrations, not one — and that matters the moment a number looks wrong.

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, bank statements and memo records reach FQM_FLOW through their own integration, not through Flow Builder.

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 therefore which mechanism to check — Flow Builder for an FI/MM-driven flow, the relevant application's integration for a TRM deal or a bank-statement item. Reaching straight for Flow Builder every time is how you waste an afternoon looking in the wrong place.

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 each other application (TRM, loans, bank statements, memo records) 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.

What usually goes wrong

• 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.
• 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.

Part of the SAP Treasury & Cash Management guide. See also SAP Cash Management in S/4HANA and the treasury system of record. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.