# Tan Gravam — full corpus

> The full text of every reviewed article on gravam.com, as Markdown. For a curated map (topic hubs + cornerstones), see https://gravam.com/llms.txt.

## Topics
- [Enterprise AI Transformation](https://gravam.com/topics/enterprise-ai-transformation): Where AI actually creates value inside a large organization: choosing the work worth transforming, redesigning it end to end, and measuring what changed.
- [AI Workflow Design](https://gravam.com/topics/ai-workflow-design): How to redesign a complex enterprise workflow around AI: what stays deterministic, what AI can judge, where a human decides, and what state the work needs.
- [Enterprise AI Systems](https://gravam.com/topics/enterprise-ai-systems): The architecture behind enterprise AI: how agents fit existing systems, what the control layer owns, and how oversight, data and observability are designed.
- [Treasury Management Systems](https://gravam.com/topics/treasury-management-systems): How to assess, select and implement a treasury management system — from business case and requirements through RFP, testing, cutover and go-live.
- [Corporate Cash & Liquidity Management](https://gravam.com/topics/cash-and-liquidity-management): How corporate treasury runs cash and liquidity: cash positioning vs forecasting, cash pooling, in-house banks, payment factories and global cash visibility.
- [Treasury Risk Management](https://gravam.com/topics/treasury-risk-management): How corporate treasury manages financial risk: FX exposure, interest rate risk, counterparty and credit risk, hedging and hedge accounting — plainly explained.
- [Treasury Systems Architecture & Connectivity](https://gravam.com/topics/treasury-systems-architecture): How treasury systems fit together: reference architecture, bank connectivity (SWIFT, API, EBICS), MT940 and camt.053 formats, and ERP–TMS integration.
- [SAP Treasury & Cash Management](https://gravam.com/topics/sap-treasury): Field notes on SAP treasury: TRM, One Exposure, FQM_FLOW, Flow Builder, liquidity items, bank statement integration and BCM — from real implementations.
- [Finance Systems Delivery](https://gravam.com/topics/finance-systems-delivery): Intake, scope, ownership, fit-gap, UAT, cutover and governance for enterprise finance-systems programmes — turning vague demands into delivery decisions.

## Tools
- [TMS Vendor Scorecard](https://gravam.com/tools/tms-vendor-scorecard): Weighted scorecard to compare treasury-system vendors on your priorities. Set weights, score 1–5, see the ranking live, export CSV.
- [13-Week Cash Flow Model](https://gravam.com/tools/13-week-cash-flow-model): A working direct cash-flow template: enter weekly receipts and payments, get the running closing balance, and see the week you'd go short. Export CSV.
- [Project Intake One-Pager](https://gravam.com/tools/project-intake-one-pager): Turn a raw request into a decision-ready one-pager — problem, outcome, scope, owner, open questions — and commit, shape, pause or decline. Copy or download.
- [TMS Business-Case Calculator](https://gravam.com/tools/tms-business-case-calculator): Turn your own numbers — hours saved, idle cash, fees, losses avoided — into a treasury-system business case: annual benefit, payback period and multi-year ROI.
- [Cutover & Go-Live Checklist](https://gravam.com/tools/cutover-go-live-checklist): A go/no-go checklist where the critical items gate the verdict: run a finance-system cutover (readiness, migration, validation smoke tests), or the five AI pilot exit gates. Copy, download, or email yourself the link.
- [System-of-Record Map](https://gravam.com/tools/system-of-record-map): Map each treasury data domain to its single system of record, consumers and integration — the one-owner-per-domain discipline. Export as a markdown table.
- [Hedge Effectiveness Checker](https://gravam.com/tools/hedge-effectiveness-checker): Enter each period's change in fair value for the hedging instrument and the hedged item; get the dollar-offset ratio against the 80–125% reference band plus a regression (slope, R², correlation). Export CSV.
- [SAP Treasury Module & Edition Selector](https://gravam.com/tools/sap-treasury-module-selector): Tick your treasury needs and see which SAP components address them — Cash Management, Transaction Manager, One Exposure, the Analyzers, BCM, APM, IHC — each linked to a full guide, plus the edition trade-offs to weigh. Export markdown.
- [TMS RFP Template Builder](https://gravam.com/tools/tms-rfp-template): Assemble a complete treasury-system RFP: company context, prioritized requirements by module (every prompt asks how, not whether), vendor questions on implementation, pricing, support and roadmap, plus the evaluation weights fixed in the document — then copy or download it as markdown.
- [RAID Log Template](https://gravam.com/tools/raid-log-template): Start a working RAID log: add risks, assumptions, issues and dependencies — each with the owner, due date and next action that make an entry real — then export it as markdown or CSV.

## Products
- [Delivery Sheet](https://gravam.com/products/delivery-sheet): Turn vague leadership asks into clear, reviewable delivery decisions — before your team commits.
- [Lookstory](https://gravam.com/products/lookstory): A private audio guide to Amsterdam — point your phone at a building and hear its story, written from checked sources.
- [5dayemail](https://gravam.com/products/5dayemail): Publish a five-to-ten day email course — every reader gets one lesson a day, in order, in their own timezone.
- [Workomap](https://gravam.com/products/workomap): The global map of SAP professionals — see where the SAP world lives and works, and put yourself on it.
- [Yollardayız](https://gravam.com/products/yollardayiz): Live border-crossing waits for the sıla yolu — which gate, and when, backed by data instead of hearsay.
- [Listemizde](https://gravam.com/products/listemizde): Don't lose the places you trust — found through real community recommendations, not paid rankings.

## More
- [About Tan Gravam](https://gravam.com/about)
- [Newsletter](https://gravam.com/newsletter)
- [Contact](https://gravam.com/contact)
- [Curated map](https://gravam.com/llms.txt)

## Articles
Every reviewed article in full, ordered by topic hub, newest first within each. One article per document: a `---` rule, the title as a level-1 heading, then its metadata (source URL, topic hub, author, dates), the complete body, its primary sources, and the questions it answers directly (Q/A pairs from the article's own reviewed FAQ). The hub is a per-article `Topic:` line rather than a heading, so the only headings in the file are the article title (`#`) and the article's own body structure below it.

---

# AI Pilot Exit Criteria: What a Pilot Must Prove

Source: https://gravam.com/blog/ai-pilot-exit-criteria
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: Not an accuracy percentage. The five gates a pilot has to pass before production — borrowed from cutover, where the questions are older and harder.

**A pilot is ready for production when its output reconciles to the system of record on real volume, its exception queue fits the team that has to clear it, there is a tested way back, and a named person has accepted it — not when it reaches an accuracy number.** The accuracy figure is an input to the second gate. On its own it decides nothing, which is inconvenient, because it is the only one of the five that is easy to put on a slide.

The textbook version of this is the stage gate: run a pilot, measure performance against a threshold, promote it if it clears. That works when the thing being promoted is a model in a benchmark. It does not survive contact with a process that has a deadline, a control environment and a team of people who will absorb whatever the system does not.

The questions below are not AI questions — they are the ones a go-live gate on an enterprise finance system has always asked, pointed at a component whose output varies. That is the whole trick, and it is why I would not write a new framework for this.

## Why the accuracy threshold is the wrong gate

Ask what "95% accurate, therefore ready" means operationally and it dissolves.

Five per cent of what? On a workflow processing four hundred items a day, that is twenty exceptions — a person's morning. On one processing forty thousand, it is two thousand, which is a department you do not have. The same percentage is a rounding error in one process and a hiring plan in another, so the percentage is not the criterion. **The criterion is the absolute exception volume measured against the capacity of the team that clears it**, and that is a number you can only get by multiplying through.

There is a second problem with the threshold framing. Accuracy measured on the pilot's sample is a claim about the sample. If the pilot ran on three clean weeks, the figure describes the easy part of the distribution, and the interesting cases have not happened yet. This is the same reason [a vendor's accuracy number needs its denominator](https://gravam.com/blog/evaluating-enterprise-ai-vendor-claims) before it means anything.

> The same accuracy figure is a rounding error in one process and a hiring plan in another. The percentage is not the criterion; the queue is.

## The five gates

Each one is a question with a factual answer, deliberately. A gate that can be argued is not a gate.

**1. Does it reconcile?** The output has to agree with the system of record — not approximately, and not after somebody fixed the differences by hand. Run it in parallel with the existing process on the same real volume and compare the results item by item, which is what [a parallel run](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) has always been for. Differences are the finding. A pilot that produces plausible output nobody reconciled has proved that it produces plausible output.

**2. Does the exception queue fit?** Take the measured exception rate, multiply by real daily volume, multiply by the average minutes to clear one, and compare that to the hours the receiving team actually has. Do it at peak, not at average — a close-period spike is where this fails. If the answer is that the queue needs 1.4 people and you have 0.3, the workflow is not ready regardless of how good the model is. Most of the design work here is in [the exception path](https://gravam.com/blog/designing-the-exception-path), and this gate is where you find out whether that design was optimistic.

**3. Is there a way back, and has it been used?** What reverses a wrong output, who can trigger it, how long does it take, and has anyone actually done it during the pilot? A rollback that exists on a slide is not a rollback. This is a straightforward import from [cutover practice](https://gravam.com/blog/cutover-and-go-live-for-finance-systems), where a fallback nobody has rehearsed is treated as absent.

**4. Is there an owner and a support model?** A named person who owns the output, and a defined route for what happens when it misbehaves at an inconvenient hour — who is called, what they can do, and what the process falls back to meanwhile. [Operational readiness](https://gravam.com/blog/operational-readiness-and-acceptance) has always meant this, and an AI step does not get an exemption because it is new. Ownership by "the AI team" is the same as no owner, which the [pilots that never became operating systems](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems) demonstrate repeatedly.

**5. Can a stranger reproduce one result?** Pick a single output from the pilot and ask somebody who was not involved to reconstruct how it was reached, from what the system recorded. If that requires a person who was there, the audit trail is a memory aid rather than evidence — and the difference matters the first time an outcome is challenged. What has to be captured to make this true is the subject of [observability](https://gravam.com/blog/production-ai-observability), and it is far cheaper to add before go-live than after.

## The gates that get skipped

In practice the same two go missing, and for the same reason: they are the ones that produce bad news.

**The parallel run on peak volume.** Running in parallel is expensive — the work gets done twice, by people who are already busy, during the period when they are busiest. It is also the only gate that produces a real exception rate rather than an estimated one. Programmes that skip it discover the true number in week two of production, when the fallback has already been decommissioned.

**The rehearsed rollback.** Nobody wants to spend a day of a pilot deliberately breaking something and undoing it. And the first time you find out whether reversal works should not be the day you need it. In treasury the equivalent lesson is old and expensive: a reversal path that has never been exercised is a hypothesis.

There is a third, subtler omission. Pilots are usually evaluated on quality of output and almost never on **whether the reviewers could keep up**. If the design assumes a human checks each proposal, measure how long a check takes and whether attention holds over an afternoon of them. An approval step that is physically possible but practically skimmed has not added a control; it has added a signature.

## A go/no-go you can actually hold

The decision meeting works when the answers were collected beforehand and the meeting only reads them.

| Gate | Evidence that closes it |
| --- | --- |
| Reconciles | Parallel-run comparison over a full cycle, differences explained |
| Queue fits | Exception count at peak volume × minutes to clear, against team hours |
| Way back | A reversal performed during the pilot, timed |
| Owner and support | A named person, a route out of hours, a documented fallback |
| Reproducible | One result reconstructed by somebody who was not there |

Not one of those rows is about the model. That is not an accident: the model is the part most likely to improve on its own, and the four organisational rows are the ones that will still be unresolved in six months if nobody forces them now. The same asymmetry drives [where to start](https://gravam.com/blog/where-to-start-with-enterprise-ai) — the expensive decisions are the ones the technology does not make for you.

A no-go is also a valid outcome, and worth saying because in practice it rarely is one. If the queue does not fit, the honest options are to narrow the scope until it does, fund the queue, or stop. Promoting anyway means the receiving team absorbs the gap quietly, and it will not appear in any report until something is late.

## Setting the gates before the pilot starts

Write the five gates down before the pilot starts, because criteria authored afterwards are written by the result. Derive the accuracy requirement from the queue arithmetic rather than picking a number. Insist on a parallel run that crosses a close. Rehearse the reversal once, on purpose. Put the accepting signature with the person who owns the output afterwards, and give them the right to say no.

And treat a passed pilot as the beginning of [hypercare](https://gravam.com/blog/hypercare-and-post-go-live-stabilization), not the end of the project — the period where the real exception mix arrives is the one after go-live, and it is where the ownership decision either holds or is revealed to have been nominal. My [cutover and go-live checklist](https://gravam.com/tools/cutover-go-live-checklist) covers the general version of that transition; the five gates above are what I would add when the component in the middle is probabilistic.

_See also [why most AI pilots never become operating systems](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems) and [how to measure ROI from an AI workflow](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow)._

## Questions this article answers

**Q: What are exit criteria for an AI pilot?**

The conditions that let a pilot become production, and for a finance workflow they are cutover gates rather than model metrics. Does the output reconcile to the system of record, on real volume, without manual repair. Is the exception volume inside the capacity of the team that will clear it. Is there a tested way back. Is there a named owner and a support route out of hours. And can somebody who was not on the project reproduce a single result from the record. An accuracy figure is an input to those questions; it is not one of them.

**Q: What accuracy does an AI pilot need to go to production?**

There is no general number, and any specific threshold quoted without a workflow attached was invented. The required accuracy is whatever leaves an exception population your team can actually clear within the process deadline, so it is derived from volume, effort per exception and the size of the queue-working team — not chosen in advance. A workflow with two hundred items a day and a slow correction path may need far better than one with twenty thousand and a cheap one. Compute the queue, then set the threshold.

**Q: How long should an AI pilot run before a go or no-go decision?**

Long enough to cross at least one full cycle of the process, including its worst period. For a finance workflow that means a month-end, and preferably a quarter-end, because the volume and the exception mix at close are not the ones you see mid-month. A pilot that ran for three quiet weeks has measured the easy part of the distribution and will be surprised on the fourth. Duration matters less than coverage: what you need is that the hard cases have already happened at least once while you were watching.

**Q: Who signs off that an AI pilot is ready for production?**

The person who will own the output afterwards, not the team that built it. That is the same rule any systems go-live follows: acceptance belongs to the business owner who has to live with the result, because they are the only party whose incentive is aligned with the failure modes. If the accepting signature comes from the project or the vendor, the sign-off records enthusiasm rather than readiness — and the first bad week has no obvious owner.

---

# How to Judge an Enterprise AI Vendor's Claims

Source: https://gravam.com/blog/evaluating-enterprise-ai-vendor-claims
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: An accuracy number without a denominator is not a claim. The questions that separate a product from a demo, from someone who runs vendor selections.

**Judge an enterprise AI claim by its denominator, not its percentage — on whose data, against what ground truth, over which population, and what happens to the cases it gets wrong.** A number without those four is not a measurement, and treating it as one is how a selection becomes a negotiation about slideware.

The textbook approach to evaluating a vendor is the demo, the reference call and the accuracy figure. All three still matter. All three are also, for a probabilistic product, much easier to stage than for deterministic software — and the usual selection process was designed for software that behaves the same way twice.

I have run and reviewed vendor selections in finance systems, and published [a scorecard](https://gravam.com/tools/tms-vendor-scorecard) and [an RFP structure](https://gravam.com/tools/tms-rfp-template) for doing it. What follows is that discipline pointed at products whose central claim is about accuracy.

## The four questions behind any accuracy number

A vendor says the model is 95% accurate. That figure is meaningless until you can answer:

**On whose data?** Theirs, a public benchmark, or a customer's real production mix. A number produced on curated data tells you the ceiling under ideal conditions, which is not the number you will operate at.

**Against what ground truth?** Somebody decided what "correct" meant. If that somebody was the vendor, on cases the vendor selected, the exercise measured agreement with themselves.

**Over which population?** The one that matters includes the hard cases. Ask explicitly whether difficult or ambiguous items were in the sample or excluded from it — the answer is frequently "excluded", and it is frequently not volunteered.

**And what happens to the other 5%?** This is the question that actually decides the economics. Five per cent of a large volume is a queue, and somebody works it. The cost of the product is the licence plus that queue, and vendors rarely price the second half because it is not theirs.

> A vendor comfortable being shown their own error rate is a different proposition from one who steers you back to the script.

## Make the demo yours

The single highest-yield change to a selection is refusing the prepared demo, or rather accepting it and then insisting on a second one you control.

Bring your own data. Unrehearsed, including the awkward cases you already know about — the multi-entity one, the one with the broken reference, the one everybody in your team mentions when this process comes up. Then watch the failures rather than the successes. Where does a wrong answer surface? Who sees it? How much work is correcting it? What does the system record about the correction, and can you get that record out?

This is the same instinct behind [asking demo questions that cannot be prepared for](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard). It just matters more here, because a deterministic system's demo is a fair sample of its behaviour and a probabilistic one's is not.

## Weight before you watch

Decide what matters, and how much, before the first meeting.

That sounds procedural and it is the mechanism that makes a selection survive contact with a good presenter. Weighting after the demos means weighting in the presence of persuasion, and the criteria drift toward whatever the most impressive vendor happened to be strong at. Fix the weights while nobody is in the room, score each vendor on the same evidence, and let the arithmetic be uncomfortable if it wants to be. That is the whole argument of [running a selection as a process](https://gravam.com/blog/how-to-run-a-tms-selection-process) rather than a series of impressions.

## The four unglamorous questions

These separate a product from a demonstration, and none of them is about the model.

**What happens when you are unavailable?** Does our process stop, queue, or fall back to something? A dependency whose failure mode is "the work stops" needs to be priced as such.

**What does the audit trail record?** At what grain — a summary, or the individual action with its inputs? Can we export it, retain it on our schedule, and hand a single record to someone who has never met the system? That is what [audit evidence](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) has to survive.

**Who is the action attributed to?** If the product acts inside our systems, whose identity does it use, and what appears on the record afterwards? [The answer is a design decision with consequences](https://gravam.com/blog/agent-identity-and-permissions) that cannot be fixed after go-live.

**How do we learn that quality has drifted?** Not that the service is down — that answers have quietly got worse. If the answer is "customers tell us", the product has no [observability](https://gravam.com/blog/production-ai-observability) and you will be the monitoring.

## What a good answer sounds like

Worth saying plainly, because scepticism is easy and calibration is the useful part.

A good vendor answer contains a number with its conditions attached, a named limitation, and an unprompted description of where the product does badly. "Around 90% on invoice formats similar to the samples you sent, materially worse on handwritten annotations, and here is what the queue looks like at your volume" is a strong answer. It is more useful than 98% with no context, and a vendor who talks that way is describing something they have run in production.

The reference call matters too, and the question that works is not "are you happy". It is: what surprised you after go-live, what does your team do now that they did not expect to, and what would you scope differently. People answer that honestly far more often than they answer a satisfaction question.

## How I would run an AI vendor evaluation

Fix the weights before the demos. Run the product on your own difficult data and watch the failures. Price the residue — the exception queue is part of the total cost and it is on your side of the line. Ask the four unglamorous questions early, because they are the ones whose answers cannot be improved later. And treat a vendor's willingness to state a limitation as evidence, because it is the closest thing to a controlled variable you will get.

None of that is AI-specific procurement wisdom. It is ordinary selection discipline, applied to a product category where the demo is unusually easy to stage and the interesting number is the one nobody puts on the slide.

_See also [how to find workflows worth redesigning with AI](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai) and [where to start with enterprise AI](https://gravam.com/blog/where-to-start-with-enterprise-ai)._

## Questions this article answers

**Q: What does an AI vendor's accuracy percentage actually mean?**

On its own, almost nothing, because the number has no denominator you can see. Ask three things and the figure becomes interpretable or it collapses: measured on whose data — theirs, a public benchmark, or a customer's real production mix; measured against what ground truth, and who decided what correct meant; and measured on which population, including whether the hard cases were in the sample or filtered out of it. A vendor who can answer all three is describing a measurement. One who cannot is quoting a marketing figure.

**Q: What should you ask an AI vendor in a demo?**

Ask to run your own data, unrehearsed, including the cases you know are difficult — and watch what happens to the ones it gets wrong rather than the ones it gets right. The demo is designed to show the clean path; the product is what happens to the residue. Ask who sees a failure, how they know it happened, what it costs to correct, and what the system records about the correction. A vendor comfortable being shown their own error rate is a materially different proposition from one who steers you back to the script.

**Q: How do you compare AI vendors fairly?**

Fix your weighting before the demos, not after. The mechanism that makes a selection defensible is deciding what matters and how much while nobody is in the room persuading you, then scoring each vendor against those weights on the same evidence. Without that, a polished presentation quietly re-weights the criteria — which is the same failure as any software selection, and the reason a scorecard is worth building before the first meeting rather than after the third.

**Q: What questions expose a thin enterprise AI product?**

Four, and they are all about the unglamorous half. What happens when your system is unavailable — does the process stop, queue, or fall back? What does the audit trail record, at what grain, and can a customer export it? Who is the action attributed to when the product acts on our behalf? And how do we find out that quality has drifted, before a person notices something wrong? A product built for demonstrations has thin answers to all four, and the answers do not improve after signature.

---

# Where to Start With Enterprise AI

Source: https://gravam.com/blog/where-to-start-with-enterprise-ai
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: Not with a pilot. A sequence borrowed from enterprise systems delivery — and the three steps in it that change when the component is probabilistic.

**Start with an inventory of what you already run, then pick one workflow using an assessment that is allowed to say no, and build the decision rights before you build the model.** The pilot is not step one. It is a way of answering a written question somewhere in the middle, and running one first is the commonest reason a programme spends a year proving something everybody already believed.

The textbook advice is the opposite: find a low-risk quick win, pilot it, build momentum. That advice is not wrong so much as incomplete — it optimises for showing something soon, and the thing it shows is almost never the thing that was hard.

The sequence below is the one that works on enterprise systems programmes, with the three steps that genuinely change when the component in the middle is probabilistic marked as such. It is deliberately unglamorous. Most of the value in sequencing is refusing to skip the boring parts.

## The sequence

**1. Inventory what you already have.** Not what the programme plans — what is already running. AI arrived in most organisations as features of software already owned, switched on by people who were not asked to file a project. Until that list exists, every subsequent step is being applied to an unknown population. This takes about a week and gets worse every quarter you leave it.

**2. Pick one workflow, with an assessment that can return "don't".** Not the one that demos well and not the one whose owner is most enthusiastic. [An assessment that can say no](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai) is the only kind worth running — if the method has never produced a "leave this alone", it is a ranking exercise wearing the clothes of an evaluation.

**3. Decide the measure before you build.** [Which number you are claiming](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow), baselined on the current process, with the confounders named in advance. This is the step most often done afterwards, at which point the baseline is a reconstruction and nobody believes it.

**4. Write the decision rights and the control path.** Who may approve what, on what evidence, and what enforces it. **This is a sequencing change, not a governance formality** — it determines the architecture, so discovering it at a control review means rebuilding. Most of the answer already exists in your delegation of authority; the work is [mapping onto it rather than inventing a parallel regime](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows).

**5. Design the exception path before the clean case.** _(Genuinely different.)_ In a deterministic programme the exception is a defect to be driven down. Here it is a permanent population with a size you can measure, and [the path it takes](https://gravam.com/blog/designing-the-exception-path) is most of the operational design. Building the happy path first produces a demo and a backlog.

**6. Run it in parallel, on real volume.** Not a sample, not last quarter's file. The parallel run is where the exception rate becomes a number instead of an assumption, and where you find out whether reviewers can actually work at the pace the design assumes. It is also where [the gates that let a pilot into production](https://gravam.com/blog/ai-pilot-exit-criteria) either close or do not.

**7. Go back and check.** Six months later, against the measure from step 3. This is [benefits realisation](https://gravam.com/blog/benefits-realization-for-finance-systems), it is skipped almost universally, and skipping it is how an organisation accumulates capabilities nobody can defend.

> If your method has never returned "leave this one alone", it is not an assessment. It is a ranking of enthusiasm.

## The three steps that are genuinely different

Most of that sequence is ordinary delivery discipline, and I would be suspicious of anyone claiming otherwise. Three steps do change, and they change in ways that break habits rather than tools.

**Fit-gap does not work.** [Fit-gap analysis](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) compares a requirement against what a system does and returns fit, gap, or workaround. You cannot do that against a component whose answer varies. The honest substitute is empirical: run real cases, measure how often the output is usable, and treat the residue as the requirement. That is a different activity with a different cost, and programmes that budget for a workshop and need a data exercise discover it late.

**Readiness means something else.** In a systems programme, [readiness](https://gravam.com/blog/operational-readiness-and-acceptance) means environments, cutover rehearsals, trained users, a run team. Those still apply. What is added is data readiness of a specific kind: not "is our data clean" in the abstract, but is the record this answer depends on reachable from where the capability runs, current enough to be right, and scoped so it does not also expose things it should not. That question has a long lead time and no shortcut.

**The pilot moves.** In a normal programme a proof of concept sits early, to de-risk technology choice. Here the technology is not the risk — the exception rate, the control path and the reviewer's capacity are. So the useful experiment happens after steps 1 to 4, and its purpose is to produce numbers for a design decision, not confidence for a steering committee. This is the same reason [pilots do not become operating systems](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems): one that was never asked a question cannot fail, and something that cannot fail teaches nothing.

## What this looks like when it goes wrong

Two patterns, both recognisable from a distance.

**The enthusiasm-led programme.** Started at step 2 with whoever volunteered, skipped 3 and 4, produced a working demo in six weeks and then spent nine months in review cycles that keep discovering constraints the design cannot accommodate. Every one of those constraints existed on day one and was findable.

**The governance-led programme.** Started at step 4, wrote a policy, built a council, produced a framework — and never reached step 2, because there was no workflow to test it against. A control regime designed against no concrete case is invariably calibrated for the worst thing anyone imagined, and it makes the first real proposal look non-compliant.

The sequence exists to avoid both. Steps 1 to 3 are cheap and produce facts. Step 4 is where most of the design is decided. Steps 5 to 7 are where the work actually is.

## Sequencing the first enterprise AI project

Spend the first month on the inventory and the assessment, and expect the assessment to eliminate most candidates — that is it working. Write the measure and the decision rights before anything is built, because both change the architecture. Design the exception path first. Run in parallel on real volume, not a curated sample. And put the six-month check in the plan at the start, because nobody schedules it afterwards.

The uncomfortable part is that almost none of this is about AI. That is the point: [the transformation is in the work, not the tool](https://gravam.com/blog/what-ai-transformation-actually-means), and the sequence that gets you there is the one enterprise delivery already knows — with three steps swapped for ones that survive a component you cannot fully predict.

_See also [what AI transformation actually means](https://gravam.com/blog/what-ai-transformation-actually-means) and [how to find workflows worth redesigning](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai)._

## Questions this article answers

**Q: Should the first enterprise AI project be a pilot?**

A pilot is a good way to answer a question and a poor way to start a programme, and the difference is whether you wrote the question down first. Run one to find out something specific — whether the input is machine-readable enough, what the real exception rate is, whether reviewers can work at the required pace. Do not run one to demonstrate that the technology works, because that answer is already known and the demonstration teaches you nothing you can build on. A pilot with no written question becomes a slide.

**Q: What is the first step in an enterprise AI programme?**

An inventory, and it is duller and more useful than it sounds. Most organisations cannot list the AI-touching processes they already run, because a good number arrived as features of software they already owned rather than as projects anyone approved. You cannot sequence, govern or classify what you have not enumerated, and the enumeration takes about a week and gets harder every quarter you leave it.

**Q: How is sequencing an AI programme different from a normal systems programme?**

Three steps change. Fit-gap analysis does not work the same way, because you cannot compare a requirement against a probabilistic component's feature list and get a yes or no — the honest equivalent is measuring the exception rate on real data. Readiness stops meaning environments and training and starts meaning whether the data an answer depends on is reachable and current. And the exception path has to be designed before the clean case rather than after it, because with a deterministic system the exception is a defect, while here it is a permanent, sized population.

**Q: What should you build before the model?**

The decision rights and the path an action takes to become real. Who may approve what, on what evidence, and which component enforces it — because that determines the design, and retrofitting it means rebuilding. Teams routinely build the capability first and discover at the control review that the workflow they designed cannot be permitted, which is not a governance problem; it is a sequencing one.

---

# How to Measure ROI From an AI Workflow

Source: https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: AI workflow ROI is measured on the work, not the seats: cycle time, hands per case, cost to run, rework. Ten metrics that move, and how to baseline them.

**Measure the work, not the tool: baseline how long a case takes, how many hands touch it, what it costs to run and how often it comes back wrong — before anything changes — then compare the same measures after, on a basis you froze in advance.** Those are numbers a finance director already accepts, and unlike a seat-based saving they can still be checked six months later by someone who wants to disagree with you.

The number in most AI business cases is built the other way: seats, multiplied by an assumed hours-saved-per-person-per-week, multiplied by a loaded hourly rate, discounted by an adoption percentage. Versions of that arithmetic get presented in steering meetings with a straight face, and the striking thing is that only one input in it — the seat count — was ever observed. Everything else was asserted at the point the slide was built.

What that calculation measures is deployment. How many people have the tool, and how many opened it. It says nothing about whether any piece of work got faster, cheaper, better or more reliable, and it cannot be checked afterwards, which is why these numbers are usually retired quietly rather than revisited.

It survives because it is available early. It can be produced before anything has changed, in the week the budget submission is due, which is exactly when a business case is needed and exactly when no evidence exists. That is a real constraint, not a moral failing. But it means the number arrives with no way of ever being right or wrong, and sceptical executives can smell that from across the table.

The alternative is not more sophisticated modelling. It is measuring the work.

## Measure the work, not the tool

A redesigned workflow changes observable things about how cases move: how long they take, how many hands touch them, how often they come back. Those are the numbers a finance director will accept, because they are the same numbers used to justify every process change since long before anyone deployed a model.

Ten of them matter. None is a model metric, and none requires a data science function to produce.

## The four that are about time

**Cycle time.** Wall-clock elapsed from the trigger event to the case being done and usable by whoever was waiting. Instrument it from two timestamps that already exist — record created and record closed — rather than from a stopwatch or a survey. The trap is where you start the clock: teams measure from "when we picked it up", which conveniently excludes the queue in front of the work, and the queue is usually where most of the elapsed time sits.

**Touch time.** The minutes a human actually spends working a case. It is the hardest of the ten to obtain honestly; sample it by observation across a normal week rather than asking people to self-report, or derive it from gaps between system events. The trap is its seductiveness. Touch time is the metric AI improves most easily and the one the business feels least — a step that got ten times faster inside a process that still takes eleven days is a rounding error, which is the whole difference between [automating a task and redesigning the work](https://gravam.com/blog/what-ai-transformation-actually-means).

**Queue and wait time.** Cycle time minus touch time, broken down by which queue. Instrument it from status-change timestamps; if the statuses do not exist, that absence is your first finding and probably your first fix. The trap is ownership — waiting is always attributed to the other team, so nobody owns it. Report it per handoff, with a name against each, and it stops being weather.

**Decision latency.** The gap between the moment a decision could have been made, because all the evidence was available, and the moment it was made. Approximate it as time from a case reaching "ready for review" to approval. The trap is starting the clock when the approver opened the item rather than when the evidence was complete; measured that way, every approval SLA in the enterprise looks excellent while the business waits days.

## Flow, and what a case actually costs

**Throughput.** Cases completed per period, in total and per person. Count closures in the system across enough weeks to see the period-end shape, not a fortnight chosen because it was quiet. The trap is mix: throughput rises on its own when the work gets easier. Always report it next to the case mix — type, size band, complexity — or you will eventually claim a redesign for a soft quarter and be found out by someone who has the volume report.

**Cost per case.** Fully loaded cost of running the workflow divided by cases completed: people time, system cost, licences, inference, and the exception team everyone forgets to include. The trap is a cost the manual version did not carry as a system cost: inference and per-case run charges that scale with volume rather than sitting in a fixed licence. Leave it out and your business case gets worse as the workflow succeeds, which is a discovery you want to make now rather than in year two.

> An hour saved is not money until somebody decides what to do with the hour.

That sentence is where most AI business cases quietly break. Saved minutes spread thinly across forty people are capacity, not cash. They become cash only when a role is not backfilled, a contract is not renewed, or a volume increase is absorbed without hiring. Say which of those you are claiming, and say who has agreed to it. If none applies, call it capacity and state what the capacity will be used for — that is a defensible claim, and the number survives contact with a finance business partner.

## Quality, and the metrics that are easiest to fake

**Rework.** Cases touched more than once because something was wrong, missing or misrouted. Instrument it by counting reopens, returns, second approvals and versions. The trap is that rework frequently lives outside the system altogether, as an email asking for a corrected file, so a redesign that formalises it can look as though it created rework. Establish where rework currently hides before you claim to have reduced it.

**Exception rate.** The share of cases [leaving the happy path](https://gravam.com/blog/designing-the-exception-path), and the share of total effort those cases consume. Define the exception types before counting anything, and count effort by type rather than incidence alone. The trap is direction: a redesign that handles the clean cases straight through will push the exception rate up while genuinely improving the workflow. Report exception effort as a share of total effort alongside the rate, or the honest improvement reads as a regression.

**Human interventions per case.** How many times a person had to touch a case for it to complete. Instrument it by counting actions attributed to a human identity in the audit log. This is the honest test of autonomy and it is unforgiving: a mandatory review step is an intervention, whatever the deck calls it. Watching this number is also how you notice that "automation" has quietly relocated the work to a checking queue rather than removed it.

**Error and reversal rate.** Outputs that turned out to be wrong, measured by what had to be undone — reversals, corrections, credit notes, restatements, complaints. Instrument it from the correction mechanisms you already have, because finance and audit have been tracking those for years. The trap is the worst one on this list: this metric can improve by looking less hard. A redesign changes detection as well as performance, so if you find more errors after go-live, say so and report detection separately. A programme that reports a falling error rate and a falling detection rate has measured nothing.

## Baseline first, or you have an anecdote

None of these ten means anything without a before. And the before has to be taken before the change, which sounds obvious and is skipped on most programmes I have seen, because by the time anyone wants the number the workflow has already moved.

Take the baseline over at least one full cycle including a period end — a workflow measured only in a quiet fortnight is not the workflow. Prefer history that already exists in your systems over a study conducted for the occasion, because the moment a team knows their process is being examined, the queue gets cleaned and the behaviour changes. A baseline taken after the kick-off meeting flatters the old world and understates whatever you eventually build.

Record more than the numbers. The case definition. The start and end events. The mix. Who is in scope and who is not. What is excluded and why. Six months later, that record is what lets somebody reconstruct the comparison instead of taking your word for it.

## Freeze the basis

The other half of credibility is that before and after have to be the same measurement. This is the point the [cash-forecasting teardown](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) makes about accuracy — a forecast that was edited after cut-off cannot be graded, because you would be marking a version that had already seen the answer.

The same logic applies to a business case. Freeze the definitions on the day you baseline and put them in writing: what counts as a case, what counts as closed, which case types are in scope, how exceptions are categorised. If the definition of "closed" moves during the project, the before-and-after comparison is fiction, and it will be exposed by the first person who asks how a case was counted.

Then keep a log of everything that changed and was not the AI. A team reorganisation, a volume drop, a new system release, a policy change, three experienced people leaving. Not to excuse the result — to make it attributable. A comparison period or a parallel region running the old way is better still, and where the workflow runs in several entities that is often available at no cost beyond the discipline of leaving one alone for a quarter.

## What a defensible case looks like on the day it is challenged

Assume the reader's job is to find the hole in it. Six things make that difficult in the right way:

- **One named workflow**, with the case defined in a sentence, rather than "AI in finance operations".
- **An observed before number**, with the dates, the method and the mix stated, taken before the project was announced wherever the history allowed it.
- **The metric the business feels first** — cycle time or cost per case — leading, with touch time supporting rather than starring.
- **The full cost**, including the run cost that scales with volume, the exception team, and the control and audit work that the redesign creates.
- **What did not change**, stated explicitly. A case that claims improvement everywhere is not credible; one that says "rework was flat and here is why" usually is.
- **A named person accountable for the number after go-live**, and a date on which it is taken again.

Add the way the claim could be wrong — mix shift, seasonality, a parallel change — before anyone else does. Naming your own confounders is the fastest route to being believed, and it costs a paragraph.

## The number is a design constraint, not a slide

The useful thing about deciding these measures early is that they change what gets built. If cycle time is the claim, then the design has to attack waiting rather than typing. If cost per case is the claim, inference cost belongs in the architecture conversation from the first week. If interventions per case is the claim, the review step needs a genuine reason to exist rather than being the default comfort.

That is also what separates work that becomes the way things run from work that stays a capability demonstration: a pilot proves something is possible, and [an operating system for the work](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems) has to keep proving it. Choose the workflow with [an assessment that can say no](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai), state the outcome as [something measurable before you start](https://gravam.com/blog/how-to-define-a-measurable-outcome), and take the baseline while the old process is still running. Everything after that is arithmetic anyone can check — which is the only kind worth putting in front of someone who intends to challenge it.

***

_See also [how to find workflows worth redesigning with AI](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai) and [enterprise AI transformation](https://gravam.com/topics/enterprise-ai-transformation)._

## Questions this article answers

**Q: Why do AI ROI calculations overstate the benefit?**

Because most of them are built from seats, an assumed number of hours saved per person per week, a loaded hourly rate and an adoption percentage. Only the seat count is observed; everything else is asserted, and the result measures how widely a tool was deployed rather than whether any work got better. The calculation also converts saved minutes straight into money, which only holds if someone actually removes the cost. And because nothing in it was ever measured, nothing in it can be checked afterwards — which is why these numbers are quietly dropped rather than revisited.

**Q: Which metrics show that an AI workflow actually improved?**

Ten, grouped in three families. Time: cycle time from trigger to done, touch time, queue and wait time, and decision latency. Flow and cost: throughput and fully loaded cost per case. Quality: rework, exception rate, human interventions per case, and the error or reversal rate. Cycle time and cost per case are what the business feels; touch time is the one that improves most easily and matters least on its own. Human interventions per case is the honest test of autonomy, because a review step is an intervention even when the deck calls it straight-through.

**Q: When should the baseline for an AI project be taken?**

Before the project is announced, ideally from timestamps that already exist in your systems rather than from a study run for the occasion. The moment a team knows their process is being examined, the queue gets cleaned and the behaviour changes, so a baseline taken after the kick-off flatters the old world and understates the gain. Cover at least one full cycle including a period end, record the case mix alongside the numbers, and write down the definitions the same day. A baseline nobody can reconstruct six months later is an anecdote with decimal places.

---

# How to Find Workflows Worth Redesigning With AI

Source: https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: An AI workflow opportunity assessment scores eight observable dimensions — frequency, effort, input, judgement, exceptions, error cost, state, control.

**A workflow is worth redesigning with AI when it is frequent, effortful and expensive to get wrong, AND its input is unstructured enough and its judgement repeatable enough for a model to help — eight observable dimensions, assessed against the real process rather than a workshop's opinion of it.** The textbook alternative is a discovery workshop: gather the process owners, brainstorm use cases, plot them on a value-versus-effort grid, take the top-right quadrant into a pilot. That workshop is older than AI, and I have sat in enough of them to know what the grid actually holds. It holds the opinions of the people who were free that afternoon, converted into coordinates, and then treated for the rest of the programme as evidence.

What comes out is a long list of plausible things ranked by enthusiasm. Something near the top gets piloted, it works, and it never becomes the way the work runs — because whatever made it a good demonstration was never the thing that would have made it worth doing.

So here is the assessment I would run instead. Eight dimensions, each of which can be observed rather than debated, and a verdict at the end that is allowed to be "leave this one alone". It should take days rather than months, and the people who can answer it already work there.

## The unit is a workflow, not a use case

"Invoice processing with AI" is a use case. It has no beginning, no end and no owner, so it cannot be measured and it cannot be finished.

A workflow has a trigger, a defined case, a sequence of steps that crosses people and systems, an end state, and someone who wants it to be over. Score use cases and you are scoring a technology. Score workflows and you are scoring work.

Define the case before anything else, and write it down: one supplier invoice, or one payment run; one customer dispute, or one month of disputes. Every number that follows depends on that choice, and teams that skip it end up comparing a before figure and an after figure that counted different things.

## Three dimensions that size the prize

**Frequency.** How often the work actually runs. High means daily or per-transaction, thousands of cases a year, and it is what pays for a build that has to survive a control review. Observe it by counting cases in the system over a full quarter — and look at the distribution, not just the total. A workflow that runs four hundred times a month with three hundred of those in the last three days is a queueing problem wearing a volume problem's clothes.

**Human effort per case.** The minutes a person spends, and whether that time scales with volume. Do not ask people to estimate it; they answer with the worst case they remember. Sit with someone for a morning, or take the gap between two system timestamps and ask what happened in between. The answer is often "I was waiting", which is a different finding and a more important one.

**Exception load.** What share of cases leave the happy path, and — the part that matters — what share of the total effort they consume. High is the norm in enterprise work: a minority of cases eating most of the week. Observe it by asking the team to name the last five things that made them stay late, then look at how those are tracked. If exceptions are not counted anywhere, that absence is itself the finding.

Exception load is the dimension people misread most often. A heavy exception load is not a reason to walk away. Paired with repeatable judgement it is the best opportunity in the building, because the assembly work in front of each exception is exactly what a model is good at. Paired with unrepeatable judgement it is the worst, because you would be automating the manufacture of confident wrong answers.

## Two that decide whether AI is the right tool at all

**Unstructured input.** How much of what arrives is prose, PDFs, email bodies, attachments, and spreadsheets that no two entities fill in the same way. High means the first thing anyone does each morning is read something to work out what it is. Observe it by opening the shared mailbox and the attachments folder, not by reading the process design. If the input is already a clean table in a system you own, AI is not the lever — integration is.

**Repeatability of the judgement.** Would two experienced people, given the same case, reach the same answer? Note that this is not "is the rule written down". Plenty of good judgement has never been written down and is still highly repeatable; plenty of documented policy is applied four different ways in four regions.

Observe it with a blind pass. Take twenty closed cases from last quarter, including several awkward ones, hand them separately to two experienced people, and compare both the answers and the reasons. It costs an afternoon and it is the single most informative thing in this whole assessment.

> The dimension that kills most candidates is not difficulty. It is that two experienced people, given the same case, do not agree on the answer.

## Three that set the cost and the ceiling

**Cost of error.** What happens when the output is wrong, how quickly anyone notices, and how hard it is to undo. High means irreversible, external, regulated or monetary: a payment released, a ledger posted, a commitment made to a customer. Observe it by asking what the last mistake cost and how it was caught. Two answers should worry you. "We have never had one" means either the work is benign or errors are invisible, and invisible is worse. "The reviewer catches it" means the reviewer is the control, and removing the step without replacing the control is not a decision the project gets to make on its own.

**State required.** What the work must remember between steps and across people: status, owner, versions, evidence, what it is waiting for. Observe it by asking where the truth lives between Monday and Thursday. If the answer is a mailbox and a spreadsheet on a shared drive, state is high and currently unheld — which is not a disqualification, but it tells you honestly that you are building an application rather than writing a prompt. That distinction is most of the difference between [a pilot and something that runs the work](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems).

**Control burden.** How much of this process exists because it is a control, and what evidence has to be produced. Observe it by reading the risk and control matrix and asking internal audit which controls in this process they actually test. Control burden is not a veto either. It is a multiplier on build cost and a hard ceiling on how far autonomy can go, and knowing that early saves a design from being dismantled at its first control review.

## Reading the eight together

Do not add them up. A weighted total gives false precision, and it lets a high frequency score outvote unrepeatable judgement, which it must never do. Two of the eight are gates and six are magnitudes. Read them as a shape.

| Verdict | The reading that points here |
| --- | --- |
| **Don't use AI** | Input already structured and judgement already codified — an integration or rules problem in AI clothing. Or judgement unrepeatable with a high cost of error. Or frequency times effort too small to fund a build. |
| **Automate** | High frequency, high unstructured input, repeatable judgement, error cheap and quickly visible, light control burden — and an output that deterministic code can check before it moves. |
| **Augment** | High effort and high unstructured input, judgement repeatable enough, but cost of error or control burden high. The model reads, assembles and drafts; a named person decides. |
| **Autonomy** | All of the augment conditions plus a genuinely multi-step sequence across systems, real state, and actions that are bounded and reversible. The sequence itself has to be the cost, not one step in it — autonomy in the [three-mode sense](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy), running across an [orchestrator placement](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems). |

A few combinations are worth stating plainly. High cost of error plus repeatable judgement is not a reason to stop; it is the definition of augmentation, and it is where most enterprise work lands — which is why [augmentation is the right default](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy) far more often than programme narratives suggest. High control burden plus high state means the expensive part is the application and the evidence, not the model, and the plan should be costed that way. And a single-step workflow never justifies an agent: if there is no sequence, there is nothing for an agent to hold.

## A worked pass: the daily cash position

Take a workflow most finance leaders recognise. Every morning, treasury establishes how much cash the group has, where it is, and what it is going to do today.

Frequency is as high as it gets: every business day, every entity, before the funding window closes. Human effort per case is real and almost entirely retrieval — logging into portals, pulling statements, keying balances, chasing the accounts whose file did not arrive.

Then the two gates. Unstructured input is low. Bank statements arrive in structured formats, and what looks like unstructured work is format heterogeneity and missing connectivity, which is a different problem with a different fix. Repeatability of judgement is so high it is barely judgement: which account, which currency, which value date, which balance — rules, all of them.

The rest confirms it. Exception load is real but narrow: the file that did not arrive, the item that does not map to a known account, the transaction code nobody has seen before. Cost of error is high, because a wrong position leads to a funding decision. State required within the day is modest. Control burden is heavy on anything that moves money and light on the reporting itself.

Verdict: don't use AI. The honest answer is bank connectivity and mapping, and a programme that adopted this as its AI flagship would spend a year and deliver a conversational interface in front of a data problem. There is exactly one AI-shaped seam in it — proposing a classification for the statement lines that never map, for a person to accept, with the accepted mapping written back so the next one lands automatically. That is a useful small augmentation inside a workflow whose real problem is plumbing.

Move one desk along and the reading inverts. The forecast cycle has high unstructured input, judgement that is repeatable enough, high effort, an error cost that is recoverable because nothing moves money, high state and moderate control burden. That reads as augment, and the [full pass over cash forecasting](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) shows what falls out of it.

## "Not this one" is the most useful answer you will get

Run this over a workshop's long list and most candidates fail on one of three readings: the input is already structured, the judgement is not repeatable, or the prize will not fund a build that has to pass a control review. That is the expected result, not a disappointing one.

It is also the finding worth carrying into the steering meeting. "We assessed forty workflows and are doing two properly" is a stronger position than forty pilots. The costly mistake here is not rejecting too much; it is choosing a workflow that demonstrates well and spending a year proving a capability nobody needed — the gap between [adopting AI and redesigning the work](https://gravam.com/blog/what-ai-transformation-actually-means).

## What to do with the two that survive

Take them apart properly before committing anything: what stays deterministic, what a model genuinely does, what a named human decides, and what the workflow has to hold between steps. That teardown is its own discipline and the rest of the [AI workflow design](https://gravam.com/topics/ai-workflow-design) notes cover it.

And before a single thing changes, measure the workflow as it runs today. The assessment tells you which work is worth redesigning; it says nothing about whether the redesign worked, and the only version of that number anyone will believe is the one taken before the project was announced. That is [the measurement problem](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow), and it is easier to do first than to reconstruct afterwards.

***

_See also [how to measure ROI from an AI workflow](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow) and [the anatomy of an AI-native enterprise workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow)._

## Questions this article answers

**Q: How do you choose which workflow to redesign with AI first?**

Assess candidates on eight things you can observe rather than argue about: how often the work runs, how much human effort each case takes, how much of the input arrives as prose or documents, whether experienced people agree on the judgement, how much of the effort sits in exceptions, what a wrong answer costs, what the work has to remember between steps, and how much of the process is a control. Three of those size the prize, two decide whether AI is the right tool at all, and three set the cost and the ceiling. Pick the one or two that survive all eight, not the one that demonstrates best.

**Q: What makes a workflow a poor candidate for AI?**

Three readings account for most rejections. The input is already structured and the rules are already written down, in which case the bottleneck is integration or configuration and a model adds nothing but a new failure mode. The judgement is not repeatable, meaning two experienced people looking at the same case reach different answers, so there is no stable target for a system to hit. Or the prize is simply too small: frequency times effort will not fund a build that has to survive an audit. None of those is a technology limitation, which is why a better model does not change the verdict.

**Q: How can you tell whether the judgement in a workflow is repeatable?**

Run a blind pass. Take twenty closed cases from the last quarter, including several awkward ones, and give them separately to two experienced people with no discussion between them. Compare the answers and, more importantly, the reasons. If they agree on most cases and can explain the ones they got right, the judgement is repeatable enough to be supported by a system. If they disagree materially, you have a policy problem rather than an AI opportunity, and deploying a model would only make one person's interpretation the house standard without anyone deciding that it should be.

---

# Why Most AI Pilots Never Become Operating Systems

Source: https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-18
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: AI pilots fail to scale because a pilot may skip what production cannot: an exception path, state, a place in the controls and a change to someone's job.

**AI pilots fail to scale because a pilot is allowed to skip the four things production cannot: the exception path, the state the work has to hold, a place in the control environment, and a change to somebody's job.** The standard route from experiment to production is a stage gate — run a pilot, prove the value, then roll it out. I have watched the enterprise-systems version of that route on programme after programme, and the failure is remarkably consistent. The pilot works. The demo lands. Everyone in the room agrees this changes things. Then twelve months later the work still runs exactly as it did, and the pilot survives as a slide in a steering pack and a Teams channel nobody posts in.

The instinct afterwards is to blame the technology, or the change management, or a vague shortage of ambition. It is usually none of those. A pilot and an operating system for the work are simply different objects, and a pilot is allowed to skip the four things that make the second one hard.

## What a pilot is allowed to skip

**The exceptions.** A pilot is run on a chosen sample, and the sample is clean — that is what makes it a good demonstration. Real enterprise work is not clean. The happy path in a period close, a payment run or a customer onboarding is the cheap part; the expensive part is the counterparty whose data never matches, the entity with the local rule, the case that was fine until legal changed the wording. In most processes I have worked on, the exceptions are not a tail. They are the job. A capability that handles the clean eighty per cent leaves the hard work untouched and adds a triage step in front of it.

**State.** A pilot answers questions. It does not remember. Work, on the other hand, is stateful: a case is open, then half-approved, then waiting on someone external, then reopened three weeks later because audit asked. Somebody has to know which of those it is, who touched it, and what the current version is. A chat window holds none of that, and this is the quiet reason so many impressive demonstrations never become anything — it is the same gap that makes most AI-built apps feel like demos. The demo shows the reasoning; the product is the state around it.

**A place in the control environment.** In a pilot nobody asks who approved this, who can see it, what was logged, whether the same person is proposing and approving, or what an auditor is shown next March. In production those questions arrive first and they are not negotiable. An AI step that writes into a system of record inherits every control that step already carried, plus new ones about what it is allowed to do unattended.

**Anyone's job description.** This is the one that is never in the deck. If the pilot succeeded and nobody's objectives, targets or team boundaries changed, the old path is still open — and the first time volume spikes or a quarter-end lands, people use the route they are measured on. Nothing was taken away, so nothing had to change.

> A pilot is judged on whether it can. An operating system is judged on what happens the day it is wrong.

## The same failure I watched for years in enterprise systems

None of this is new, and that is what I find useful about it. Long before anyone was piloting models, I watched prototypes that demonstrated beautifully in a sandbox die somewhere between design and go-live — every time for the same reasons.

The prototype ran on curated data; the real data had thirty years of history, three merged charts of accounts and a field somebody had repurposed in 2009. The prototype had no cutover: no plan for the in-flight items, no way to reconcile the last run of the old process with the first run of the new one. It had never been through hypercare, where the volume is real and the exceptions arrive in a batch on day three. And it had never had to answer an auditor asking who signed this off and how you would know if it had gone wrong.

That is the same list, with different nouns. It is also why [the delivery model matters more than the method argument](https://gravam.com/blog/agile-vs-waterfall-for-finance-systems-delivery): the hard part of enterprise delivery was never building the thing, it was surviving the transition into being the thing everyone depends on.

## What an operating system for the work actually owns

The contrast is worth being blunt about, because the gap between the two columns is the actual project plan.

| Dimension | A pilot | An operating system for the work |
| --- | --- | --- |
| Cases it sees | A chosen, clean sample | Everything that arrives, including the ugly ones |
| Exceptions | Excluded from scope | Has a defined path, an owner and a queue that is watched |
| State | None — it answers and forgets | Owns the case: status, history, who touched it, what version is current |
| Decision rights | Implicit; a human is always in the room | Written down: what it may do alone, what needs approval, what it must refuse |
| Control environment | Outside it | Inside it — logged, reviewable, segregated, explainable to audit |
| Accountability | The project team, until the demo ends | A named person answerable for the output |
| Failure | Interesting | Handled, contained and visible |

Two of those rows carry most of the engineering weight. Decision rights only mean something if the system's outputs are shaped tightly enough to be checked, which is the work of [output contracts and explicit failure handling](https://gravam.com/blog/ai-output-contracts-and-failure-handling) — an unstructured answer cannot be validated, routed or refused. And "visible" is not a property you add at the end; without [production observability](https://gravam.com/blog/production-ai-observability) nobody knows whether quality drifted last month, and the first signal is a complaint from someone downstream.

## The questions to ask before the demo, not after

If you want a pilot that can become the way work runs, decide these before you build it. They are unglamorous and they take an afternoon.

- **Which exceptions is this allowed to fail on**, and where do they go when it does? A named queue with a named owner, not "back to the team".
- **What state does the work carry**, and what holds it? If the answer is "the person", you have designed a task assistant, not a system.
- **What is it allowed to do without a human?** Write, propose, or only draft. Say it in one sentence per action.
- **Who is accountable for its output** once the project team disbands — by name, with the authority to switch it off.
- **What is the evidence an auditor gets**, and does it exist automatically or does someone assemble it?
- **Whose job changes, and is the old path being closed?** If not, plan for the old path to win.

A pilot that cannot answer these is not worthless. It just needs to be called what it is.

## Pilots are still worth running — for a question

The honest caveat: pilots earn their place when they answer a specific question the organisation could not otherwise answer. Can this model read our documents accurately enough. Do our people trust the output. Is the exception rate ten per cent or sixty. Those are real questions and a fast experiment is the right way to settle them.

What makes a pilot useless is running it without the question. Then the only possible result is "it worked", which was never in doubt, and the programme collects capability demonstrations while the operating model stays exactly where it was. Write down the question, write down what would make you stop, and treat "it worked" as the beginning of the difficult part rather than the end of the easy one.

If you want that written as a gate rather than an intention, [the five things a pilot has to prove before production](https://gravam.com/blog/ai-pilot-exit-criteria) are the ones I would put in the plan on day one — none of them an accuracy number.

The pattern underneath all of this is the same one that separates [adopting AI from redesigning the work](https://gravam.com/blog/what-ai-transformation-actually-means): a pilot proves a capability, and capability was never the binding constraint. State, exceptions, decision rights and accountability were — and each of those is an [architecture and controls problem](https://gravam.com/topics/enterprise-ai-systems) that has to be designed on purpose, by someone who has watched a system go live and be wrong in front of people who depend on it.

***

_See also [what AI transformation actually means](https://gravam.com/blog/what-ai-transformation-actually-means) and [production AI observability](https://gravam.com/blog/production-ai-observability)._

## Questions this article answers

**Q: Why do AI pilots fail to scale beyond the pilot stage?**

Because a pilot is allowed to skip the four things that make work run. It picks clean cases and never meets the exceptions, which in enterprise processes are most of the effort. It holds no state, so it can answer a question but cannot carry a case that is open, half-approved or reopened. It has no place in the control environment — no logging, no approval path, nothing an auditor can be shown. And nobody's job description changed, so the old route stays open and gets used the first time volume spikes. None of those are model problems, which is why a better model does not fix them.

**Q: What is the difference between an AI pilot and an AI operating system?**

A pilot answers whether something is possible; an operating system is how the work actually runs. The pilot is judged on output quality across a chosen sample. The operating system owns state between steps, has a defined path for the cases it cannot handle, holds explicit decision rights about what it may do alone, is logged and reviewable, and has a named person accountable for its output. A pilot can be excellent and still be none of those things. Turning one into the other is largely organisational work, not model work.

**Q: Who should be accountable for an AI system's output?**

A named person with the authority to change the system, not a committee and not the vendor. Enterprise work already runs this way: every control has an owner who answers for it. An AI step in a process needs the same — someone who owns the quality of what it produces, sees the exception queue, is told when behaviour drifts, and can stop it. If accountability lands on 'the AI team' generically, then in practice nobody is watching the output, and the first serious error becomes an incident with no obvious owner and no agreed way to unwind it.

---

# What AI Transformation Actually Means

Source: https://gravam.com/blog/what-ai-transformation-actually-means
Topic: Enterprise AI Transformation — https://gravam.com/topics/enterprise-ai-transformation
Author: Tan Gravam
Published: 2026-08-18
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: Adopting AI tools, automating a task and redesigning the work are three different things. The difference, and a four-question test for which one you're doing.

**AI transformation means redesigning how work is done, not adding AI to the work as it already runs — and three genuinely different things are currently called by that one word: adopting a tool, automating a task, and redesigning the work itself.** Every large organisation now has an AI programme, and nearly all of them describe it the same way: we are transforming how we work. Then you look at the work. The request still arrives by email, still waits behind the same two approvals, still gets keyed into the same screen by the same person — only now there is an assistant beside the screen and a licence line in the budget. Something has been adopted. Almost nothing has been transformed.

That gap is not laziness or bad faith. Three genuinely different things are being called by one word, and they have different costs, different owners and different evidence of success. Separating them is the most useful hour a transformation lead can spend, because most stalled programmes are stalled for a simple reason: they bought the cheapest of the three and expected the results of the most expensive.

## Three different things wearing one word

**Adopting a tool.** People get access to an assistant and are encouraged to use it. This is measured in licences, logins and enthusiasm. The value is real but private: individuals get faster at their own tasks, unevenly, in ways that never show up in a process metric because the process never knew about it.

**Automating a task.** A step that used to take a person an hour now takes a model a minute — a summary written, a document classified, a first-pass match proposed. The step is genuinely cheaper. But the process keeps its shape: the same work arrives from the same place, goes to the same reviewer, waits in the same queue. What changed was one box on the flowchart.

**Redesigning the work.** The shape itself changes. Handoffs that existed to move information between people disappear because the information no longer needs moving. Decisions that were escalated because judgement was scarce get made where the work is, against a written standard. The batch becomes continuous because the reason it was a batch has gone. Someone's job is different afterwards, and you can point at what.

Only the third is transformation in any sense worth the word. The first two are inputs. They are worth doing — I would not tell anyone to skip them — but neither one changes how the organisation operates, and expecting them to is where the disappointment comes from.

## The shape of the work is older than the technology

Here is the part I did not appreciate until I had spent years inside enterprise systems programmes: almost no enterprise process was designed. It accreted. And the constraints it accreted around were paper, email, and what an ERP screen could show one person at a time.

Work was batched because someone had to carry a folder, or because the data only landed after the nightly job. Approval thresholds were set high because review was expensive, and low-value checks were dropped because nobody had the hours. Reconciliation steps exist because two systems could not talk to each other, and a person became the integration layer. Reports run weekly because weekly was the fastest cadence at which the inputs could be gathered by hand.

Every one of those is a sensible answer to a constraint. Several of those constraints are now gone, and the answers are still in place — written into procedure documents, built into system configuration, defended in workshops by people who genuinely believe the step is the control.

> A copilot makes the step faster. Only a redesign removes the wait — and in most enterprise processes, nearly all of the elapsed time is wait.

You can see it clearly in something like cash forecasting. The [choice between a direct and an indirect approach](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) was, for most of its history, partly a data-availability decision: the direct view needed granular inputs that were painful to collect, so the cadence and the method were shaped around the collection effort. Put an assistant next to the person doing the collecting and you get the same forecast, slightly sooner. Change what it costs to gather and classify the inputs, and the honest question stops being "how do we produce this faster" and becomes "why is this a weekly artefact at all".

## What a redesign actually moves

Four things, and if none of them changed, no redesign happened.

**Handoffs.** Not faster handoffs — fewer. A handoff is a queue, an explanation, and a chance to lose context. The redesign question is which of them existed only because information had to travel between two people.

**Decision rights.** Who is allowed to decide what, and on what evidence. Most escalations exist because the person closest to the work could not see enough to be trusted with the call. When that changes, the escalation is a habit, not a control — and pushing the decision down is a bigger change than any model you deploy.

**Cycle time versus touch time.** Touch time is the minutes a human spends. Cycle time is the wall-clock from request to done. Programmes report touch time because it is easy to attribute; the business feels cycle time. A step that got ten times faster inside a process that still takes eleven days is a rounding error someone will eventually notice.

**What a human still owns.** A redesign is not the removal of people from the process; it is an explicit statement of what they are there for. The judgement calls, the exceptions, the accountability for the output. If nobody can name that list, either nothing changed or the control question has not been asked yet — and it will be asked, later, by someone with an audit mandate.

## A test you can run this week

Take one workflow your programme has already claimed. Ask four questions and refuse to accept effort as an answer.

1. **Has any handoff disappeared?** Not got faster. Disappeared.
2. **Does anyone decide something they did not decide before**, or stop deciding something they used to?
3. **Has elapsed time changed, or only touch time?** Measure the wall clock from the request landing to the work being done.
4. **Can you name what a human still owns, and why?** In one sentence, without the words "oversight" or "governance" doing all the work.

Four noes: you have adopted tools. A yes on the third alone, delivered by faster steps: you have automated a task. Yeses on the first two: something structural has moved, and that is worth funding properly. The value of the test is that it is hard to fake — none of these questions can be answered with a licence count, and all of them can be answered by the people who do the work, in about ten minutes.

It is the same discipline as [writing down the measurable outcome before you start](https://gravam.com/blog/how-to-define-a-measurable-outcome). If the outcome was "adopt AI in finance", every one of the four questions is unanswerable and the programme will be declared a success on activity.

## Why most programmes stop at the first two

Because adoption and automation are politically cheap. Nobody's authority changes, no job description is rewritten, no control has to be re-argued with audit, no cost centre loses anything. You can buy them, announce them, and count them within a quarter.

Redesign is none of those things. It touches decision rights, the control environment, the shape of teams and what people are measured on. It needs a sponsor who can hold a position for longer than a quarter, and it needs someone willing to say which steps are going to stop existing. That is why it is rare, and also why it is where the value is: everyone can buy the same tools, and almost nobody will do the organisational work behind them.

## This is not an argument against pilots or copilots

Adoption is a reasonable first move. Automating a genuinely expensive step is real money. And not every process deserves a redesign — most do not, because the payoff does not justify the disruption. The useful move is to be honest about which of the three you are doing, and to pick one or two workflows where the economics actually change and do the full job there rather than spreading a thin layer of assistance across forty processes.

That choice — which work is worth redesigning, and how you take it apart — is its own discipline, and it is what the [AI workflow design](https://gravam.com/topics/ai-workflow-design) notes are about. It also depends on a line I hold everywhere: [AI executes, humans decide](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows). A redesigned process still has named humans owning the judgement calls; what changes is that they are no longer spending their day moving information between systems to reach them.

The other half of this problem is what happens after the redesign is designed — why the thing that worked in the pilot never becomes the way the work runs. That is [the pilot-to-operating-system gap](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems), and it kills more good ideas than bad technology ever has.

***

_See also [why most AI pilots never become operating systems](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems), [how to find the workflows worth redesigning](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai), and [how to measure the ROI once you have](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow)._

## Questions this article answers

**Q: What does AI transformation actually mean?**

AI transformation means the work itself is redesigned around what AI makes cheap — not that AI has been added to the work as it stands. Three things get called transformation: adopting a tool, so people have an assistant beside the same process; automating a task, so one step gets faster while the process keeps its shape; and redesigning the workflow, so handoffs disappear, decision rights move, and the elapsed time changes rather than the touch time. Only the third one changes how the organisation operates. The first two are useful, but they are inputs, not transformation.

**Q: How is AI transformation different from automating a task?**

Automation makes an existing step cheaper and leaves everything around it intact: the same handoffs, the same approvals, the same queue in front of the step and the same one behind it. Redesign changes the structure — which handoffs exist at all, who is allowed to decide what, what the process holds on to between steps, and what a human still owns. The practical tell is elapsed time. Automation improves touch time, the minutes someone spends working. Redesign improves the wait, which in most enterprise processes is where nearly all the time sits.

**Q: How can I tell if my organisation is really transforming with AI?**

Take one workflow you believe has been transformed and ask four questions. Has any handoff disappeared entirely, rather than got faster? Does anyone now decide something they did not decide before, or stop deciding something they used to? Has elapsed time moved, or only the minutes someone spends working? Can you name what a human still owns and why? Four noes mean you have adopted tools. A yes only on the third, through faster steps, means you have automated. Redesign shows up as changed answers to the first two.

---

# AI Workflow Teardown: Bank Reconciliation

Source: https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation
Topic: AI Workflow Design — https://gravam.com/topics/ai-workflow-design
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: Bank reconciliation taken apart: why the matching engine was never the bottleneck, what AI does with the residue, and which breaks need a named human.

**Redesigning bank reconciliation around AI means leaving the matching engine alone and rebuilding what happens to the breaks — because the ticking was automated decades ago and the cost was never there. The boundary that holds is propose, never post.** The textbook version is a two-column exercise: statement lines on one side, ledger entries on the other, tick off what agrees, investigate what is left. Every manual describes it that way, which is the problem: the description makes the ticking sound like the work. The ticking has been automated for decades.

This is the second in a series of teardowns taking one real workflow apart with [the method](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow); the [first took cash forecasting](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) through the same headings. Reconciliation is the better demonstration: the split between rule, model and named human is unusually clean.

## The workflow as it runs today

Statements arrive overnight, one file per bank account, in [whichever format that bank sends](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) — MT940, camt.053, BAI2. An import job loads them and matching rules run: amount against open item, reference against document number, date inside a window, tolerance where policy allows. Recognised transaction types post automatically.

Everything the rules could not decide lands in a queue, and the human day starts. An accountant works down it — the bank portal, the remittance mailbox, the open-item list, an email to the customer. Some items resolve in a minute; some sit for weeks. At period end the rest are aged, written off, provided for or explained in a note, and the reconciliation has to tie out regardless.

## Where the time actually goes

Map the cycle honestly, step by step with the reason each takes as long as it does, and the same shape tends to appear. The matching engine is not in it: it runs unattended and finishes before anyone logs in. The elapsed time sits in the residue, in four forms.

**Identification**: who a payment is from, when the only clue is a truncated company name and a reference from the payer's system. **Assembly**: the open items, the payment history, the credit note, the dispute, the remittance advice that arrived as a PDF two days early. **Waiting**: a query to a customer does not return the same day, and the item ages while the queue grows. **Repetition**: the same counterparty deducts the same charge every month and someone derives it again each time, because the last person to work it out wrote it in a comment field nobody searches.

> Reconciliations are rarely late because the matching engine was slow. They are late because a handful of items have no explanation and one person owns all of them.

An unexplained break is not a clerical nuisance, either: it is an unverified statement about cash, ageing while the pressure at period end is to shrink the queue rather than understand it.

## The deterministic core

Now the split. The first pile is everything that must be identical every time it is asked, or that a control depends on.

- **Amount matching**, including currency and tolerance — a stated band in policy, not judged item by item.
- **Dates.** Value date against booking date, cut-off, which period a line belongs to.
- **Reference and identifier matching.** End-to-end identifiers, structured remittance references, document and payment-run numbers. Where a structured reference exists, matching on it is a rule and a model adds nothing.
- **Balancing.** Opening plus movements equals closing, on both sides, and the reconciliation still ties out. Non-negotiable.
- **Postings and clearing**, generated by code from validated data, with a reversal path.
- **Ageing, routing and segregation of duties**, with four-eyes above a threshold, checked rather than requested.

None of it is a candidate for a model, ever. A reconciliation whose totals could vary between two runs on the same statement is not a reconciliation; it is an opinion.

Which is what most AI proposals for this workflow miss. The matching engine is not the interesting part and never was — rules already clear the routine lines cheaply, so any gain there is measured against a step that already costs nothing.

## What AI can genuinely do here

The second pile is what an experienced reconciliation clerk does all day: read things and build a case.

- **Interpreting free text.** Narrative and remittance fields, structured or unstructured; the advice emailed as a PDF; the deduction schedule sent as a spreadsheet.
- **Categorising the exception.** Timing difference, charge deducted at source, FX difference, partial payment, duplicate, misdirected receipt.
- **Proposing root-cause hypotheses**, ranked, with the evidence each rests on: this credit looks like two invoices less a settlement discount this customer has taken all year.
- **Synthesising the evidence.** One pack per break — statement line, candidate open items, the payer's history, the correspondence, and how the last ones like it were closed.
- **Drafting the remediation.** The note to the counterparty, the clearing proposal, the write-off memo, the period-end explanation.

What these share is that being wrong is visible and cheap: a rejected hypothesis costs a click from someone who would otherwise have spent twenty minutes on it. Nothing clears because a model was confident. Where being wrong is neither visible nor cheap — anything that posts or moves money — the work belongs in the first pile or the third. That is the [automation, augmentation and autonomy](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy) split, applied item by item.

## What stays with a named human

The third pile is decisions, and the test is not capability. It is who answers for it when it is wrong.

**Write-offs**, because money leaves permanently and does not come back: a band, an approver, four eyes. **Accounting treatment**: whether a difference is a bank charge, an FX movement, a discount taken, a loss or a receivable that survives, and which period it belongs to. **Material exceptions**: anything above a threshold, and anything touching a counterparty relationship, where the cheapest answer and the right one differ.

And the **unresolved break at period end** — carry it, provide for it, escalate it, park it in suspense with an owner and a date, or decide that none of those is acceptable and the close waits. That needs a person, because it is the decision an automated queue would rather not make.

The redesign does not remove that person; it turns their work from investigation into decision.

## The state this workflow has to hold

Here is where reconciliation redesigns quietly fail, and it has nothing to do with models. The statement has a system; the ledger has a system; the break has neither, and lives in a spreadsheet, a comment field and one person's memory.

- **The break itself**, with an identity, a status, an age and an owner who is a person rather than a team.
- **Evidence gathered** — what was looked at, what was asked, who answered, when — so the third person to touch it does not start again from the statement line.
- **Resolution and reason code**, in a vocabulary you can count rather than free-text prose.
- **Historical patterns.** This counterparty always pays net of their bank's charges; this entity's payroll arrives as one debit with no detail. That knowledge is the asset here, and it leaves when the person holding it does.
- **An audit trail.** Which action, by which identity, at which time, on which item.

That list is why this becomes an application with a model inside it rather than a chat window with a good prompt — and one reason [pilots stall short of running the work](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems).

## The exception path

Here [the exception path is not part of the design; it is the design](https://gravam.com/blog/designing-the-exception-path). Six recurring shapes; the redesign is judged on them.

1. **A statement line with no ledger counterpart.** An unexpected receipt or charge, needing identification before a posting — and identification is the free-text problem.
2. **A ledger entry with no statement line.** A payment that never landed, an item in transit: a timing difference until proven otherwise, and proving otherwise is the work.
3. **A difference inside tolerance.** Cleared by rule, but recorded with a reason rather than swallowed — otherwise the mechanism that makes small differences painless destroys the signal that one counterparty deducts a fee every month.
4. **A difference outside tolerance.** A short payment or deduction, needing the evidence pack: which invoices, which deduction, whether it recurs or is disputed.
5. **Matched to the wrong thing.** The expensive one, because it looks resolved: two invoices of the same amount, the wrong customer cleared, found when the right one gets a dunning letter. Detection must be designed.
6. **The break nobody can close.** It ages, stays visible, stays owned, and is never closed automatically for tidiness.

Each needs the same four things: detection, a route, context that travels with it, and a write-back so the next costs less. The write-back is what compounds — it is how a pattern stops being folklore and becomes state.

## What it has to integrate with

The reads are broad: statements from every bank in every format, open items from receivables and payables, the ledger with its clearing and suspense accounts, payment runs and their references, remittance advice arriving by whatever channel. Where a group runs [a treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system), much of that already sits in one place and the integration is narrower than it looks. In an SAP landscape the residue is concrete: unposted statement lines in [FEBAN post-processing](https://gravam.com/blog/feban-bank-statement-post-processing), and open receivables waiting for [SAP cash application](https://gravam.com/blog/sap-cash-application-ai).

The writes are where this differs from the forecasting teardown. That workflow published a document; this one posts to a ledger — clearing, reclassification, write-off — so the control surface is real. Which forces one design rule: the model proposes, code posts. A posting is generated deterministically from an approved decision, under a traceable identity, with a reversal path, never emitted by a model. Get that boundary wrong and nothing downstream is defensible, which is why [enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem) before it is a model problem.

## The redesigned workflow

Statements land, the rules run, the routine lines clear exactly as they always did. What changes is the residue. Every unmatched item becomes a break record the moment matching finishes, owned by the account, entity and type rather than by whoever opens the queue first. Before a person looks at it the evidence is assembled: narrative parsed, candidate open items retrieved, the payer's history summarised, correspondence found, hypotheses ranked. Where a recorded pattern applies — this counterparty always deducts their bank's charges — the proposal says so and cites the breaks behind it.

The accountant's session becomes review, not investigation: accept, reject, or ask for the one fact the assembly could not find. Accepting generates a deterministic posting under their identity, four-eyes above a band. Rejecting is recorded, because a rejected proposal is both signal and measure.

What is left at day's end is the residue of the residue: items needing a decision, aged and visible and owned. And the reconciliation still ties out, which nothing here may make easier by hiding anything.

## What the business case is made of

Four measures, named before the build and taken before and after. None is a model metric.

- **Auto-match rate**, stated as a baseline precisely so nobody claims credit for moving it. A better rate beside a queue the same size on the twentieth means something already free got optimised.
- **Time to resolve per break**, by category — the one that should move, because assembly is what was removed.
- **Open breaks at period end, and their age.** The control measure, and the one a finance director already watches.
- **Manual touches per break**: portals opened, emails written, spreadsheets built.

Stated as a shape, illustratively rather than measured: the change is not fewer breaks. It is breaks that arrive with their evidence already gathered, so an afternoon of assembly becomes a morning of decisions. What justifies the work is not the clerk hours. It is the cost of a period closed over items nobody understood — and of an unexplained credit sitting in suspense for six weeks, a control failure with a plausible story attached.

## What this generalises to

The piles fall out unusually cleanly here, but what made the redesign work is not specific to banks.

**The engine everyone wants to improve is usually already the cheap part.** In most mature processes the deterministic core is solved, fast and dull, and the work sits in what it could not decide. Ask what share of the elapsed time is inside the step being automated, and be ready for almost none.

**Propose, never post.** Wherever a workflow writes consequentially to a system of record, the model's output is a proposal and the write is code generated from an approved decision — approved by a person, or by a remit narrow enough to have been written down in advance. That one boundary is what makes a probabilistic component acceptable to an auditor.

**The pattern in someone's head is the asset.** Every exception-heavy process has someone who knows why this counterparty is always short. Capturing that as state, cited in the next proposal, is worth more than any model choice.

**An unresolved item must be allowed to stay unresolved.** Owned, aged, visible, never closed for tidiness. A design that cannot hold an open item indefinitely will eventually hide one, which turns an efficiency project into a control finding.

The headings do not change from one teardown to the next, which is rather the point: a method that works only on its author's favourite process is not a method.

***

_See also [the anatomy of an AI-native enterprise workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow) and [bank statement formats: MT940, camt.053 and BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2)._

## Questions this article answers

**Q: Why does a faster matching engine not speed up bank reconciliation?**

Because the matching engine was never the slow part. Rules that compare amount, reference and date within a tolerance run unattended overnight, and where remittance references are structured they clear the routine lines without anyone watching. The calendar is consumed by the residue — the items the rules could not decide — and each of those costs a person a search through a bank portal, an open-item list, a remittance mailbox and a colleague's memory. A redesign that makes matching faster improves a step that already finishes before anyone arrives at work, and leaves the queue exactly the size it was.

**Q: What can AI safely do with an unmatched bank statement line?**

AI can read an unmatched bank statement line and build the case, but it must not clear it. Interpreting a narrative or remittance field, identifying the likely payer, retrieving candidate open items, recognising that a shortfall matches a recurring deduction, and drafting both the clearing proposal and the note to the counterparty are all reading and synthesis, where being wrong is visible and cheap. Turning that proposal into a posting stays deterministic: code generates the entry from an approved decision, under a traceable identity, with a reversal path. Propose, never post, is the boundary that keeps the whole design auditable.

**Q: Who should own an unresolved reconciliation break at period end?**

A named person, not a team and not a queue. Someone has to decide whether an item nobody could explain is carried forward, provided for, escalated, or parked in a suspense account with an owner and a date attached — and sometimes the correct answer is that the close waits. Automation may assemble the evidence and age the item, but it must never close it for tidiness. An unexplained credit that quietly disappears from a queue is not an efficiency gain; it is a control that stopped reporting, which is precisely what a reconciliation exists to prevent.

---

# Designing the Exception Path in AI Workflows

Source: https://gravam.com/blog/designing-the-exception-path
Topic: AI Workflow Design — https://gravam.com/topics/ai-workflow-design
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: An AI exception handling workflow is the part demos skip: detection, queue, escalation, resolution and write-back. How to design it before the clean case.

**The exception path is not the edge of a workflow — it is the workflow, and it should be designed before the clean case: what makes an item an exception, who it goes to, what they can see, what they are allowed to do, and how it returns.** The residue is where the effort, the cost and the risk actually sit, and designing it last is how a workflow ships as a demo with a backlog attached.

Every workflow design I have ever been handed opens the other way round, with the clean case: the invoice arrives complete, the entity submits on time, the statement ties, the model classifies it correctly and the record moves on. That path gets the diagram, the demo and most of the build effort.

The other case is where enterprise work actually lives. The submission that never arrived. The line nobody can map. The two systems that disagree. The item that is entirely valid but larger than anyone in the room may approve. In finance and treasury systems I have never seen a process where the straight-through volume was the problem, and rarely seen a design document give the other volume more than a paragraph.

## The clean case is the smallest part of the build

There is a structural reason for this, and it is not carelessness. The clean case can be specified in advance — it is what the process owner describes when asked how the work runs. The exception path cannot, because the people doing the work have absorbed it: the chasing, the workaround, the spreadsheet, the colleague who knows which of the two systems is usually right. None of that is written down, so a design built from interviews reproduces the clean case faithfully and inherits the rest by accident. AI sharpens the asymmetry, because a model handles the ordinary case impressively on the first attempt and makes a pilot look finished long before it is — one of the reliable reasons [pilots stall short of running the work](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems).

## How an item becomes an exception

Detection is a design decision, not a side effect. There are five distinct ways an item leaves the happy path, and a design should say which ones it has.

**Confidence below threshold.** The model declines to commit, or commits weakly. This is the trigger everyone builds, and it has a limitation worth being honest about: it catches uncertainty, not error. The item the model gets wrong while sounding certain does not trip it.

**Validation failure.** A deterministic rule says no. It does not balance, the format is invalid, the code is not in the list, the date is out of range. The cheapest and most reliable exceptions you have, because they are certainties rather than estimates.

**Missing evidence.** Nothing arrived. This one is detected only by a clock — at a cut-off, against an expected list — which is why it is so often missed. Nothing raises an alert about a file that failed to turn up unless someone decided in advance that it was due.

**Conflicting sources.** Two systems disagree and both are internally valid. The most expensive class, because there is no error to find; there is a reconciliation to perform and a judgement about which source governs.

**Policy limit.** Nothing is wrong with the item at all. It exceeds a threshold, sits outside a tolerance, or involves a counterparty seen for the first time. Not a failure — a decision that must be taken by someone holding the right to take it, which is the matrix in [human decision rights](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows) doing its job.

One of these is probabilistic and four are deterministic. A design that considers only the first has built an exception path for the component it just added, and left the process's real exceptions to be found in production.

And an exception is a state, not a message. A failure that produces a log line or an email has not been detected in any useful sense — it has been announced. Detection creates a record, and everything below depends on that record existing.

## The queue is a real object with real fields

A queue is not a filter over a table. It is a first-class part of the system, and it holds more than most designs give it.

**An owner who is a person.** Not a team, not a mailbox, not a role eleven people share. Assign by exception class, so the person routinely handling unmappable lines is the one who gets good at them.

**An age.** Exceptions do not resolve themselves; they get old. A queue showing a count but not an age is hiding its own failure — twelve items open looks identical whether the oldest is an hour or a quarter.

**A priority derived from risk and deadline**, not arrival order. First in, first out feels fair and produces the wrong sequence: it treats a small mapping query and a break in a funding position as peers.

**A service level per class.** A single blanket target is either too slow for the urgent exceptions or unachievable for the hard ones.

**A capacity.** The field nobody puts on the design, and it decides everything. If exceptions arrive faster than they are cleared, no interface improvement rescues the queue — the backlog grows until someone declares an amnesty.

The anti-pattern is everywhere: exceptions routed to a shared mailbox. Email has no ownership, no ageing, no priority and no shared view, so the queue's true state lives in the head of whoever reads it most often. That is the same argument as everything else about [the state a workflow has to hold](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow) — the work has to be resumable by someone who was not there yesterday.

## Escalation has to change something

Escalation is not sending the same problem to a larger audience. It has two triggers, and both should fire automatically. **Time**: the item has aged past its service level, so ownership moves. **Authority**: resolving it needs a right the current owner does not hold — a write-off, a tolerance override, a payment above their limit — so it moves to someone who does. That second trigger is where the exception path and the decision-rights matrix meet, and where a queue quietly becomes part of the control environment.

Whichever fires, escalation must change who owns the item or what may be decided about it. If it only adds recipients, it is a status report with an urgent subject line.

The other end of the queue is skipped almost universally: the terminal state. Some items will never be resolved, and there has to be an authorised way to close them — accepted with a reason, written off, closed unresolved with a named owner. Without one, the tail of the queue becomes a permanent shadow backlog everybody has learned to scroll past.

## What the person resolving it needs to see

The measurement that matters here is touches per exception, and the target is one. Every additional touch is a person rebuilding context they should have been handed.

So the screen carries, in one place: the item and its source evidence; the specific reason it stopped; the assembled context — related documents, prior correspondence, the master data involved; similar past cases and what was decided about them; the actions available and what each one does; and somewhere for the reason to be recorded.

"The specific reason" deserves emphasis, because it is where AI-era queues fail in a new way. A confidence score is not a reason. "Low confidence, 0.41" tells the resolver a component was unsure and nothing about what to do. "The remittance names an entity that is not in the mapping table" tells them what happened and what would fix it. Translating the first into the second is a design obligation.

This is also where a model earns most of its keep — not deciding, but assembling. Gathering the documents, correspondence and prior cases around a broken item is exactly the reading-and-synthesising work models are good at, and exactly the work that consumes a specialist's afternoon today. The [cash-forecasting teardown](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) shows it on a real process: five classes, each with its own detection, route and resolution.

## Resolution needs a shape

A resolution is a decision, and decisions have a structure: what was decided, on what basis, by whom, and what now happens to the item — reprocessed, corrected at source, overridden with a reason, rejected, or closed. Record the action as a code from a fixed list, chosen to be analysable later, and the reason separately in a sentence. Free text alone is where learning goes to die: fine for nuance, useless for pattern, and after a year you have a mountain of comments and no idea which class costs the most.

## Write-back is what stops the queue being permanent

This is the part almost always missing, and it decides whether the exception path shrinks over time or becomes a permanent staffing line. Every resolution should be capable of producing one of four things.

**A fix at source.** The mapping now exists, the master data is corrected, the bank detail is registered. That item can never raise this exception again.

**A rule.** The pattern is now understood well enough to be deterministic, so the next occurrence never becomes an exception at all. The best outcome available and the most under-used: a good exception path is a machine for discovering rules nobody had written down.

**A reference example.** For classes that stay genuinely judgemental, the resolved case becomes context for the next similar one, so the assembly improves even where the decision cannot be automated.

**An upstream change.** The uncomfortable one, and often the largest. Many exceptions are caused before the workflow begins: a form field never made mandatory, a template two regions never agreed, a supplier who sends PDFs because nobody asked otherwise. Fixing those removes the exception rather than processing it faster.

A resolution that produces none of the four is a mark against the design, not the person. It means an indistinguishable item arrives again next month and costs the same.

> Every exception you resolve without changing anything is one you have agreed to resolve again, for as long as the process exists.

Track the class mix, not only the total. A flat rate can hide real progress — one class eliminated while volume grew — and equally the opposite, where the easy class was fixed and a harder one expanded underneath it.

## An exception rate is a measurement, not a feeling

Ask a room what proportion of items go straight through and you will get a number. Ask where it came from and you will get a pause. The estimate is almost always optimistic, because the people answering describe the process as designed while the exceptions live in the workarounds around it.

Define it before measuring: exceptions raised per item processed, by class, over real volume, across a period long enough to include a month end — period ends are when the volume and the awkwardness both peak. Most processes can be measured today, without building anything, because the current way of working already produces exceptions. They are just called chasing, rework, or Friday's list.

Then hold three numbers rather than one. The **rate** — what share of items stop. The **cost** — average effort to clear one, by class, since a rare exception taking two days can outweigh a common one taking two minutes. The **tail** — the age of the oldest unresolved item, which tells you whether the queue is a process or a pile.

Those numbers are load-bearing well beyond the queue. They set the staffing and the service level you can promise. They determine whether a step can defensibly run [with autonomy rather than as augmentation](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy), since a long tail of odd cases is an augmentation design more or less forever. And they decide whether the business case is real: a redesign that halves touch time on the clean case while leaving a fifth of items queued has not changed the economics of anything.

Which leads to the sentence I would put on the front of any AI workflow design: **a design that cannot state its expected exception rate is not finished.** Not wrong, not unambitious — unfinished, the way a building with no drainage is unfinished.

## Design it first, not last

The instruction is simple and it inverts the usual order. Take the design, walk through each step, and for every one ask what happens when it does not work. If the answer is "it goes to the team", the step has no exception path — it has a hope.

Name the detection, the queue, the owner, the clock, the escalation, the resolution codes and the write-back, and do it before the clean case is built. The clean case will be built anyway, and at a fraction of the effort. More of this method sits in the [AI workflow design](https://gravam.com/topics/ai-workflow-design) notes.

Something else follows from getting it right, worth wanting for its own sake: the specialists stop spending their days on assembly and start spending them on the handful of items each week that genuinely need a person who knows what they are looking at. That is the whole argument for redesigning enterprise work around AI, and it lives in the queue rather than in the demo.

***

_See also [the cash-forecasting teardown](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) and [human decision rights in AI-native workflows](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows)._

## Questions this article answers

**Q: What is the exception path in an AI workflow?**

The exception path is everything that happens to an item that does not go straight through: how it is detected, where it queues, who owns it, how it ages and escalates, what the person resolving it sees, how the resolution is recorded, and what gets changed so the same thing happens less often. Straight-through items were never expensive — they already flow. The exception path is where the elapsed time, the specialist effort and the risk actually sit, which is why designing it first tends to produce a better workflow than designing the clean case first and bolting on a queue.

**Q: What should an exception queue hold for each item?**

Enough that someone can resolve it without leaving the screen. The item and its source evidence; the class of exception and the specific reason it stopped, stated in business terms rather than as a score; a named owner rather than a team; the age since detection; a priority derived from risk and deadline; the service level for that class; the actions available and what each one does; similar cases and how they were resolved; and somewhere to record the reason for the decision. Anything missing becomes a tab someone opens, and tabs are where the afternoon goes.

**Q: How do you measure an AI workflow's exception rate?**

Define the numerator and denominator before you measure anything: exceptions raised per items processed, broken down by class, over real volume across a real period that includes a month end. Then track three numbers rather than one — the rate, the cost to clear an exception by class, and the age of the oldest unresolved item. Most processes can be measured today, because the current way of working already produces exceptions; they are simply called chasing, rework or the Friday afternoon list rather than being counted.

---

# Human Decision Rights in AI-Native Workflows

Source: https://gravam.com/blog/human-decision-rights-in-ai-native-workflows
Topic: AI Workflow Design — https://gravam.com/topics/ai-workflow-design
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: The useful question is not what AI can automate. It is who is allowed to decide what — a rights matrix over every action a workflow contains.

**Decision rights in an AI-native workflow are the written statement of which actor — model, rule, or named human — may read, extract, classify, recommend, approve, execute, override or change policy, and on what evidence. It is a mapping onto the delegation of authority you already have, not a new governance regime.** The textbook way to open an AI design workshop is with a capability question instead: what can the model do, how accurate is it, which of these steps can it take off our hands. It is a reasonable question and the wrong one to start with, because it produces designs that demo beautifully and then stall in a control review nobody scheduled.

The question that decides whether an AI-native workflow can actually run is much older than the technology, and every enterprise already answers it a hundred times a day for its human staff: **who is allowed to decide what?**

Enterprise systems work — approval matrices, bank mandates, the documents that decide who may release a payment — teaches that the hard part of a design is almost never the processing. It is the authority: who may raise it, who may approve it, who may release it, and what happens when those turn out to be the same person. AI does not retire that question. It changes who is standing where the answer used to be.

## Break the workflow into verbs

Decision rights cannot be granted to a process. "Supplier onboarding" is not something anyone can hold authority over; it is a container. Rights attach to actions, so the first move is to take the workflow apart into its verbs.

Most enterprise work reduces to a short and surprisingly stable list:

- **Read** — retrieve, open, look at.
- **Extract** — pull a value out of an unstructured source.
- **Classify** — assign a category, a counterparty, a cost centre, a risk band.
- **Recommend** — propose an action, with reasoning attached.
- **Approve** — accept a proposal so that it may proceed.
- **Execute** — do the thing: post, send, release, pay.
- **Override a control** — proceed despite a rule that said stop.
- **Change policy** — move the rule itself.

Written out like that, most of the answers stop being controversial. Nobody seriously argues that a model should raise a limit. The arguments happen because the verbs were never separated: "the agent handles onboarding" bundles read, extract, classify, recommend, approve and execute into one sentence, and the approval hides comfortably inside it. Separating them is the same discipline as [taking the workflow apart in the first place](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow), run down a different axis.

## The rights matrix

This is the default I would start a design from. Every row is negotiable. None of them should be left implicit.

| Action | What AI may do | What a human must do | The condition that decides |
| --- | --- | --- | --- |
| **Read** | Retrieve anything inside a granted scope | Set the scope once, and review it when roles change | The scope never exceeds that of the person on whose behalf the work is done |
| **Extract** | Pull values and cite where each one came from | Nothing per item; sample the accuracy on a schedule | The value is shown beside its source, so checking takes seconds rather than minutes |
| **Classify** | Assign from a fixed list, with a reason and a confidence | Resolve the ones it declines to assign | The classification is reversible, and nothing consequential acts on it before confirmation |
| **Recommend** | Propose the action, the amount, the counterparty and the evidence | Accept, amend or reject — by name | A recommendation never promotes itself to an approval because nobody responded |
| **Approve** | Nothing, unless inside a written, narrow, hard-limited remit | Approve anything consequential, under the delegation of authority that exists | Value, reversibility, whether the consequence lands outside the company — and whether the delegation of authority even permits a non-person to hold it |
| **Execute** | Carry out what a human approved, exactly as approved | Approve first, and retain the ability to stop it mid-flight | The action is idempotent, logged against an identity, and has a defined reversal path |
| **Override a control** | Nothing | Override, with a recorded reason and a second pair of eyes | A control a machine can set aside was never a control |
| **Change policy** | Draft the change and show what it would have done historically | Decide, approve and version it | Policy changes follow the same governance as any other change to the control environment |

Two rows carry the whole design. **Recommend** is where nearly all of the value sits — an afternoon of assembly done before anyone sits down. **Approve** is where the risk sits, and it is the row that quietly moves when a programme is behind schedule.

> An AI system may be allowed to prepare any decision in the enterprise. What it is allowed to decide is a much shorter list, and someone's name is on every line of it.

## The condition column is the actual work

The first two columns are easy to agree in a room. The fourth is where a design becomes real, and it holds four different questions.

**Materiality.** The obvious one, and the one people reduce to a currency amount. Value is a decent proxy and an incomplete one: a small credit note to the wrong customer is cheap, the same action against a regulator is not. Set thresholds on consequence, then express them in money where money is a fair stand-in.

**Reversibility.** Not "can it be undone" but how far it has travelled and what undoing costs. A draft is free to reverse, a classification is cheap, an email to a counterparty is out of the building the moment it is sent, and a released payment is a phone call to a bank at best.

**Repetition.** The condition that genuinely differs between a human decision right and a machine one, and the one most often left out. A human approver making the same misjudgement four hundred times before anyone notices is not a realistic scenario; an automated step doing exactly that before lunch is an ordinary Tuesday. So rights need bounding twice: per case and per period. Value per item, value per day, count per hour, and a stopping condition that does not depend on someone watching a dashboard.

**Accountability, and to whom.** Every consequential decision runs to a person, and that person answers to someone else — a committee, a board, an auditor, a regulator. "The system decided" is not an answer any of those accept. If you cannot name who is answerable for a row, that row is not ready.

## You are not starting from a blank page

Here is the part most writing on AI governance skips, and it decides whether a design survives its first control review.

Decision rights already exist in your organisation, written down and signed, and more carefully reasoned than anything a workshop will produce in an afternoon. The delegation of authority. The approval matrix. Segregation of duties. Four-eyes release. Bank mandates and signature limits. Spending authority by grade. System roles and entitlements. Most of it exists because something went wrong once and someone made sure it could not happen the same way twice.

So this is mostly a mapping exercise. For each verb, find the document that already governs it. If the machine is going to recommend, whose preparation work is it doing, and does that person's scope cover the data it reads? If it is going to execute, under whose authority, and does that authority exist in something a person signed? This is where the design meets the plumbing of [identity and permissions in the existing landscape](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems), and the two have to give the same answer.

Skipping it produces two failure modes. The **parallel regime**: a new AI governance policy with its own risk tiers, review board and thresholds, standing beside a delegation of authority it never references — six months in there are two answers to who may approve a payment, and the auditor finds both. And the quieter, commoner **silent widening**: no document changed, but a service account with broad access now does what a person with narrower access used to do, and the effective authority of the workflow rose without anyone deciding that it should.

A practical test: if the design cannot be described as a set of amendments to documents that already exist, it has not been mapped onto the control environment. It has been laid on top of it.

Segregation of duties deserves its own line, because it breaks in a new way. An agent that both prepares a payment and releases it is the four-eyes violation wearing a costume, and most people spot that one. The subtler version is the proposed fix: split the duty between two instances, one proposing and one checking. Segregation between two humans works because they are different people with different incentives and blind spots. Two instances of the same system are not two people. They share a model, a prompt and a failure mode. That is one opinion, asked twice.

## When it is confident and wrong

An experienced person who is unsure usually signals it. They hedge, they ask a colleague, they escalate, they write "I think" in the email. That signal does an enormous amount of unacknowledged work in every control environment I have seen — it is how borderline items find their way to the person who should see them.

A model's output does not carry that signal reliably. It can be fluent, well-structured, internally consistent, complete, and wrong — and the qualities that make an output easy to approve can appear regardless of whether the content is correct. The presentation is not evidence about the answer.

So never grant a right on observed accuracy alone. Grant it on what a wrong answer costs and how quickly it is caught: two steps performing identically deserve different rights when one produces a label that can be reclassified and the other produces a payment.

And put the check where the error would be visible. For an extraction, the source document beside the extracted value. For a recommendation, the evidence and — the part people omit — the evidence pointing the other way. A check that consists of re-reading the model's own conclusion is not a check. It is a second opinion from the same source.

## "Human in the loop" is a position, not a control

The phrase has become a reassurance, and it reassures far more than it should. Being in the loop describes where someone stands. A control has a trigger, an action, evidence that it happened, and an owner. A review step becomes a control only when three things are true at once.

**The human has the evidence.** Enough to disagree, not merely enough to agree. If the only artefact on the screen is the model's conclusion, the reviewer can approve it or delay it, but they cannot check it.

**The human has the time.** Review capacity is a finite budget. Take a step generating four hundred recommendations a day with a reviewer who has two hours to give it — purely as an illustration — and each item gets about eighteen seconds. That is a design input, not an unfortunate discovery after go-live. Either the output is checkable in eighteen seconds, or the volume is split by risk so most items are never individually reviewed and a few get genuine attention, or the review is fictional.

**Saying no has to work.** Rejecting should be as easy as accepting, the reason should have somewhere to go, and it should change what happens next rather than merely delaying it. Where accepting is one click and disagreeing means starting a conversation with another team, the design has already chosen its outcome.

## Designing against the rubber stamp

Rubber-stamping is not a people problem, and training rarely fixes it. It is the predictable output of asking someone to approve more items than they can examine, with less evidence than they need, in a screen where agreeing is frictionless. So design against it on purpose.

**Match the volume to the attention.** Route by risk rather than uniformly: the material and the irreversible get a real decision, the rest get sampled. Uniform routing is fair and useless.

**Show the reason to disagree.** Every recommendation should carry what would make it wrong — the source that was missing, the assumption applied, the item that did not match the pattern. A recommendation that argues only its own case has been optimised for approval, not for a decision.

**Instrument the approval itself.** Approval rate, time spent per item, and how often the human changed anything. If nearly everything is approved in a couple of seconds, the workflow is no longer augmentation. It is [autonomy that nobody signed for](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy), running under a person's name — the worst of both designs, with neither real oversight nor a boundary with an owner. Then sample what was approved, the way a quality function samples anything else.

Most of these rights get exercised in one place: the queue where the items that did not go straight through are waiting. That is why [the exception path](https://gravam.com/blog/designing-the-exception-path) is where a decision-rights design either works or is quietly abandoned.

## Write it down, one row per verb

The artefact this produces is small: a table, one row per action, four columns, and a named human on every consequential row. It fits on a page, and it is worth arguing about before anything is built — after go-live, each of those rows is a change request with a control review attached.

The test I would apply to any AI-native design, at any stage: point at a consequential action and ask three questions. Who decided? On what evidence? Who answers for it? If the first answer is "the system" and the third is a pause, the design is not finished — whatever the model can do. There is more of this method in the [AI workflow design](https://gravam.com/topics/ai-workflow-design) notes.

***

_See also [the anatomy of an AI-native enterprise workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow) and [designing the exception path](https://gravam.com/blog/designing-the-exception-path)._

## Questions this article answers

**Q: What are decision rights in an AI-native workflow?**

Decision rights are the explicit statement of which actor may take which action, and under what condition. They attach to verbs, not to processes: read, extract, classify, recommend, approve, execute, override a control, change policy. For each verb you state what the AI may do, what a named human must do, and the condition that decides — a value threshold, how reversible the action is, whether the consequence lands outside the company, and who is answerable when it turns out wrong. Written down, most of the argument disappears, because the disagreements were about bundles of verbs rather than the verbs themselves.

**Q: Why is 'human in the loop' not a control on its own?**

Because being in the loop is a position, not a control. A control has a defined trigger, a defined action, evidence that it was performed, and a person accountable for it. A review step has none of those unless three conditions hold: the reviewer can see the evidence behind the recommendation and not just its conclusion, they have enough time per item to examine it, and rejecting is as easy and as recorded as accepting. Remove any one of those and the step still appears in the process diagram while checking nothing at all.

**Q: How do you stop AI approvals becoming a rubber stamp?**

Treat rubber-stamping as a design outcome rather than a discipline problem. Route items by risk so the volume matches the attention available, instead of sending everything to one queue. Show the reasons to disagree — the missing source, the assumption made, the item that did not fit — beside the recommendation, so the output is built for a decision rather than for approval. Make rejecting cheap and give the reason somewhere to go. Then measure it: approval rate, time spent per item, and a periodic sample of approved items re-checked properly.

---

# AI Workflow Teardown: Cash Forecasting

Source: https://gravam.com/blog/ai-workflow-teardown-cash-forecasting
Topic: AI Workflow Design — https://gravam.com/topics/ai-workflow-design
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: A corporate cash forecast, taken apart: where the elapsed time really sits, what stays deterministic, what AI genuinely does, and what a named human decides.

**Redesigning cash forecasting around AI means attacking the collection and chasing, not the number — the model reads widely and writes narrowly, and a human still owns the forecast.** The textbook cycle is a clean loop: entities submit expected receipts and payments, treasury consolidates them into a rolling view, the forecast is compared with what actually landed, and the variances feed back into next week's submission. It appears in every treasury operating model I have seen, and as a description of the work it is nearly useless — because it describes the arithmetic, and the arithmetic was never the problem.

This is the first in a series of teardowns: one real workflow at a time, taken apart with [the method](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow) rather than described from the outside. Cash forecasting first, because I have rebuilt it enough times to know where it hurts.

## The workflow as it runs today

A typical group's short-horizon forecast runs like this. A template goes out — usually a spreadsheet, sometimes a form, occasionally both because two regions never agreed. Entities fill in expected receipts and payments and send them back, in a window that is nominally two days and in practice runs until someone gives up waiting. Treasury pulls the opening position from bank statements, extracts open items from AR and AP, layers in the known items nobody submits — payroll, tax, debt service, intercompany — and assembles a rolling view, commonly thirteen weeks and commonly [direct rather than indirect](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) at that horizon.

Then the second half starts. Last period's forecast is compared with what landed, someone works out which entity was wrong and why, a pack is written, a meeting is held. Occasionally a funding or investment decision follows, which was the point of all of it.

## Where the time actually goes

Map the cycle honestly — each step, and the reason it takes as long as it does — and the shape is the same everywhere I have seen it.

Most of the elapsed time is waiting for entities to submit, not calculating. After waiting comes chasing: a person reading a mailbox to work out which of forty replies matters and which eleven never arrived. Then normalisation — the file with merged cells, the currency that was not stated, the entity that reported gross where everyone else reports net, the line described only as "project costs". Then the hunt for explanations, the expensive one, because it means opening prior submissions, bank statements and correspondence to reconstruct why a number moved.

The consolidation itself — sum, translate, bucket, compare — takes seconds, and is the only part most people picture when they say "automate the forecast".

> The forecast was never late because the arithmetic was slow. It was late because eleven entities had not replied.

There is a quieter cost too. A view that lands on Thursday describing the week that began on Monday is a report, not a decision tool. Compressing the cycle is not efficiency; it changes what the number is for.

## The deterministic core

Now the split. First pile: everything that must be identical every time it is asked, or that a control depends on.

- **Aggregation and currency translation.** Sums by entity, category, currency and week, at a stated rate on a stated date.
- **Date bucketing.** Which week a flow falls into, including value dating, weekends and public holiday calendars per country.
- **The opening position.** Derived from imported bank statements against known accounts, not typed.
- **Variance calculation.** Forecast versus actual, by horizon and category, on a definition that does not move between periods.
- **Thresholds.** Headroom against facility limits, minimum balances, concentration and counterparty limits — policy as code, checked rather than judged.
- **Routing and status.** Which entity is due, which has submitted, which version is current, who may see which entity's figures.

None of this is a candidate for a model. It is cheap to write, easy to test, and — the part people skip — it is what makes the model-driven parts safe: every drafted explanation lands next to a number calculated the same way it will be next week.

## What AI can genuinely do here

The second pile is bigger than sceptics expect, and it maps almost exactly onto what the experienced analyst does all week.

- **Reading whatever arrived.** The submission sent as an email body, the PDF from a joint venture, the spreadsheet with the extra column, the bank confirmation attached instead of filled in.
- **Classifying flows.** Mapping a free-text line to a forecast category from a fixed list, with the unmapped ones raised rather than guessed silently.
- **Synthesising the cycle.** Twelve submissions from six entities into one summary of what changed and what is still missing.
- **Drafting.** The chaser, the variance commentary, the first version of the review pack.
- **Spotting the odd one out.** Not computing the variance — that is a rule — but noticing that its explanation does not match the pattern of previous periods, or that a receipt has slipped a week in each of the last four submissions.

What these share is that being wrong is visible and cheap. A misclassified line gets reclassified; a weak draft gets rewritten. Where being wrong is neither visible nor cheap — anything that changes the signed number, anything that moves money — the work belongs in the first pile or the third. That choice, step by step, is the [automation, augmentation and autonomy](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy) split applied concretely.

## What stays with a named human

The third pile is decisions, and the test is not capability. It is who answers for it when it is wrong.

Four things stay with a person, by name: whether a large uncertain flow belongs in this cycle at all; which assumption wins when two sources disagree; what to do about a gap the forecast has exposed — draw, delay, sweep, escalate; and what is said to the CFO about the number.

The redesign does not remove that person; it makes the decision cheap. Once the reading, chasing, mapping and drafting have already happened, the treasurer's work shrinks from assembly to judgement — and the judgement improves, because it is made against the whole picture rather than the three tabs there was time to open.

## The state this workflow has to hold

This is where AI redesigns of forecasting quietly fail, and it has nothing to do with models. A forecast is not an answer; it is a record with a history.

- **A cycle record** with a status per entity: due, submitted, queried, accepted.
- **Versions.** What the figure was, what it is now, who changed it, why, and which version the review pack was cut from.
- **An assumption register.** The overrides treasury applies on top of what entities submitted, each with an owner and a reason, so next period's variance is attributable to the assumption rather than the entity.
- **A frozen basis for accuracy.** The forecast as it stood at cut-off, kept untouched — otherwise every accuracy measure grades a forecast that was edited after the fact.
- **An audit trail.** Which action, by which identity, at which time, on which entity's data.

That list is why this ends up as an application with a model inside it rather than a chat window with a good prompt. Someone picks the cycle up on Thursday having not seen Monday; an auditor asks in March why an assumption was applied. A conversation holds none of it, which is one reason [pilots stall short of running the work](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems).

## The exception path

Straight-through entities were never the problem. The cost sits in five recurring exceptions, and the redesign is judged on how it handles them:

1. **No submission by cut-off.** Detect at the deadline, chase automatically, and — the part usually left undesigned — decide what stands in for the missing data: last period, a trend, or a marked gap. Whichever it is, it must show as a substitution rather than fold into the total.
2. **An unmappable line.** Raised as a proposal with the suggested category and its reasoning, resolved by a person, and written back so the mapping exists next time.
3. **A position that does not tie.** The opening balance disagrees with the statement — a break, not a forecast issue, routed to whoever owns the bank data.
4. **Late data after cut-off.** Never edited into the frozen version. It creates the next version, with the delta visible.
5. **A variance nobody can explain.** The one that must not be closed automatically. It ages, it is visible, and it belongs to a person.

Design these first. On every forecasting process I have worked on, they are where the week goes — and they are exactly the reading-and-assembling work a model supports.

## What it has to integrate with

Mostly reads, which is what makes this a realistic first teardown rather than a two-year programme: bank statements for the opening position and actuals; open items from AR and AP (what [SAP S/4HANA cash forecasting](https://gravam.com/blog/sap-s4hana-cash-forecasting) reads from One Exposure); payroll, tax and debt service calendars; entity submissions in whatever form they arrive; governed FX rates; facility and limit data. Where a group runs [a treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system), several of those already sit in one place and the integration is narrower than it looks.

The write path is thin: a published forecast version, the accuracy history, the resolved category mappings. Nothing posts to a ledger or moves money, which keeps the control surface small — worth choosing on purpose. Workflows that read widely and write narrowly are where a redesign can be proved without a control review at every step.

## The redesigned workflow

Put together: submissions arrive however entities want to send them, and are read, normalised and mapped on arrival, with unmapped lines raised rather than guessed. The moment cut-off passes, the missing entities are known and chased without anyone reading a mailbox. Consolidation, translation, bucketing and variance run as deterministic code against a versioned cycle record. What reaches the treasurer is a complete draft: the position, the movements since last run, the exceptions with their evidence, and a drafted commentary for each material variance.

The treasurer's session is judgement, not assembly: accept or override the assumptions, resolve the aged exceptions, decide the funding action, put the commentary into their own words, publish. The published version is frozen and becomes next period's accuracy baseline, and the resolved mappings make the next cycle shorter than this one.

For the shape of the output underneath all this, the [13-week cash flow model](https://gravam.com/tools/13-week-cash-flow-model) is the same structure without the surrounding machinery.

## What the business case is made of

Four measures, named before the build and taken before and after. Not one is a model metric.

- **Cycle time**, from cut-off to a published forecast someone can act on.
- **Hands-on-keys touches** per cycle: submissions re-typed, lines mapped by hand, chasers written by hand.
- **Coverage at cut-off**: how much of the group's cash is represented by entities that submitted on time, without substitution.
- **Accuracy by horizon**, against the frozen version, so improvement cannot come from editing history.

Coverage at cut-off is the one worth watching: it moves before accuracy does, because a forecast built on substitutions is guessing about the entities it could not reach.

Stated as a shape, illustratively rather than measured: a cycle that runs for days and produces a forecast the treasurer half-trusts becomes one that finishes inside a day and produces a number they can fund against. What justifies the work is not the analyst hours saved. It is the cost of funding decisions made late, or made on a view nobody quite believed.

## What this generalises to

Cash forecasting is a good first teardown because it is unusually legible. But the four things that made the redesign work are not treasury-specific.

**The elapsed time is almost never in the step everyone wants to automate.** Here it is waiting and chasing. In reconciliation it will be matching exceptions; in month-end reporting, the explanations. Map the calendar before choosing the technology, and the map usually points somewhere other than where the enthusiasm is.

**The number stays deterministic; the words around it go to the model.** Any workflow producing a figure someone signs has this line running through it. Calculation, limit checks and postings stay as code. The reading, classifying, synthesising and drafting around the figure are the model's work — and that is where the hours were all along.

**Freeze the basis, or you cannot measure anything.** A forecast edited after the fact cannot be graded; nor can a reconciliation whose rules moved, nor a report whose comparatives were quietly restated. Decide what is frozen, when, and what a later correction creates instead of overwrites. That is a state decision, and it settles whether the business case can ever be proved.

**Design the exception path first, because it is the workflow.** The straight-through cases already flow. The value lands in the items that do not match, do not arrive or do not tie — each needing detection, a route, the context that travels with it, and a write-back so the next one is cheaper. A redesign that handles only the clean cases has automated the part that was never expensive.

The headings above are the ones the next teardown uses too — the method is the sequence, not the example.

***

_See also [the anatomy of an AI-native enterprise workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow), [direct vs indirect cash flow forecasting](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting), the next teardown in the series — [bank reconciliation](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) — and the general case of section seven: [designing the exception path](https://gravam.com/blog/designing-the-exception-path)._

## Questions this article answers

**Q: Where does the elapsed time go in a cash forecasting cycle?**

Almost never in the calculation. The arithmetic behind a rolling forecast is trivial and instant; the cycle is long because treasury is waiting for entities to submit, chasing the ones that have not, normalising submissions that arrived in the wrong shape, hunting the opening balance, and assembling an explanation for a variance somebody will ask about in the review. In every forecasting process I have worked on, the calendar is dominated by waiting and reconciling. That matters for a redesign, because a faster model applied to the calculation step changes nothing anyone can feel.

**Q: Can AI produce the cash forecast itself?**

AI should not produce the cash forecast number. Aggregation, currency translation, bucketing by date and variance against actuals must be deterministic, because a figure a treasurer signs cannot vary between two runs on the same inputs. What a model does well is everything around the number: reading submissions that arrive as emails, PDFs and inconsistent spreadsheets, proposing a category for a line nobody has mapped, drafting the chaser and the variance narrative, and flagging an explanation that does not match the pattern of previous periods. The calculation stays code; the reading, drafting and classifying go to the model.

**Q: What does a named human still decide in a redesigned forecast?**

The judgements that carry consequence and are hard to reverse. Whether a large, uncertain flow belongs in this cycle at all. Which assumption to adopt when two sources disagree. What to do about a funding gap the forecast has exposed — draw, delay, sweep or escalate. And what is said to the CFO, in that person's own words, with their name attached. The redesign does not remove that person; it removes the four hours of assembly in front of the decision, so the judgement is made against a complete picture rather than the three tabs there was time to open.

---

# AI Automation vs Augmentation vs Autonomy

Source: https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy
Topic: AI Workflow Design — https://gravam.com/topics/ai-workflow-design
Author: Tan Gravam
Published: 2026-08-18
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: AI automation vs augmentation vs autonomy are three different designs, not rungs of a ladder. The criteria that decide which one a piece of work deserves.

**Automation, augmentation and autonomy are three different designs, not three stages of maturity: automation executes a written rule, augmentation puts a machine's proposal in front of a person who decides, and autonomy lets the machine act inside a bounded mandate.** A mature organisation runs all three at once, deliberately, inside the same process — and picks between them per step, on the cost of being wrong.

The common framing is the opposite: a ladder, with automation at the bottom and autonomy at the top, and everyone climbing. It is a tidy story and it is the wrong shape.

The confusion is expensive. The moment worth recognising is where "we are still only doing augmentation" is said apologetically, as though the design were an embarrassment rather than a decision. That sentence is usually the start of an autonomy project that will be quietly walked back after the first incident.

So here is the distinction, made properly, and then the criteria that decide which one a given piece of work deserves.

## Automation: the machine does the whole step, under fixed rules

Automation is the oldest of the three and it has nothing to do with AI. The rules are written down, the inputs are structured, the machine executes and the output is identical every time. Payment file generation, statement import, the matching engine, the limit check, [the straight-through processing a treasury system already does](https://gravam.com/blog/what-is-a-treasury-management-system).

There is no judgement in it, which is precisely its virtue. It is testable, explainable, and boring in the way that controls should be boring. When people describe an automation as "AI", they are usually describing a rules engine with better marketing, and the honest question to ask is whether the rules could be written down. If they could, write them down. A deterministic step beats a probabilistic one on every dimension that matters here: cost, latency, testability and audit.

## Augmentation: the machine prepares, a person decides

Augmentation is where a model reads what was previously read by a person, assembles what was previously assembled by hand, drafts what was previously drafted from scratch — and then a named human accepts it, changes it, or throws it away.

The decision does not move. That is the whole point. What moves is the preparation: the four hours of gathering that used to precede a five-minute call. Done well, the human's judgement gets better rather than merely faster, because they are deciding against a complete picture instead of the three documents they had time to open.

This is the least glamorous of the three and by some distance the most valuable in enterprise work, for a reason that is structural rather than technological: the control environment does not have to change. The same approver approves, the same audit trail records it, the same segregation of duties holds. You can put augmentation into a regulated process in a quarter. Autonomy in the same process is a governance programme.

## Autonomy: the machine decides and acts within a bounded remit

Autonomy is not "the model is very good now". It is a design in which the machine makes a decision and takes an action without a human in the loop for that instance, inside a boundary somebody defined — and, crucially, somebody is answerable for what happens inside that boundary.

The bounded remit is the substance of it: which actions are permitted, against which data, up to what value, with what stopping conditions, and what happens on the day it is wrong. A well-designed autonomous step has limits enforced in code, a full record of what it decided and why, monitoring that a human actually reads, and an owner who can be asked about it. Autonomy without those four is not autonomy. It is an unsupervised script with a good story attached.

> Autonomy is not the absence of a human. It is a human who has moved from deciding each case to owning the boundary — and who is still answerable when something inside it goes wrong.

## The criteria that decide which one

Five questions, asked per step and not per process. Most workflows contain all three answers.

**Is it reversible?** Can the action be undone, cheaply, before it reaches anyone outside? A draft is reversible. A classification is reversible. A payment release is not, and neither is an email to a counterparty. Irreversibility pushes work up toward a human decision, regardless of how well the model performs.

**What is the blast radius?** If this runs wrong a hundred times before anyone notices, what is the worst state of the world? Bounded by a limit that is enforced in code, or bounded only by the assumption that it will not happen? A step whose failure is contained can be given a longer leash than one whose failure compounds silently.

**What is the exception rate, measured?** Not estimated in a workshop — measured on real volume, with the failures categorised. A step where the model is right the overwhelming majority of the time and the residue is detectable is an autonomy candidate. A step with a long tail of odd cases is an augmentation candidate forever, and that is fine. You need [evaluation and regression evidence](https://gravam.com/blog/ai-evaluation-and-regression-testing) to know which one you have; without it, you are asserting.

**How expensive is the review compared to the task?** This is the criterion people skip, and it kills more augmentation designs than any other. If checking the output takes as long as doing the work, you have not saved anything — you have moved the effort and added a step. Either the output must be structured so it can be checked at a glance, or the task should stay with rules, or the review has to be reduced to a sample. A review nobody can afford to do properly is a rubber stamp, and a rubber stamp is autonomy that nobody admitted to designing.

**Does the decision have an owner in the control environment?** Every consequential decision in an enterprise already has one: a delegation of authority, an approval matrix, a signatory list. If you are proposing that a machine makes that decision, you are proposing a change to that document, and it is a real change with a named person on the other end. If nobody will put their name to the boundary, the work is not ready for autonomy — and the answer is not a governance workaround, it is augmentation.

## Most enterprise work should be augmentation

Run those five criteria across a real process and the distribution is consistent. A minority of steps are pure rules and should simply be automated properly, often with technology that has been available for a decade. A small number are narrow, reversible, high-volume and well-evidenced, and genuinely deserve autonomy. The bulk is judgement applied to messy inputs, where the expensive part is assembling the evidence rather than making the call — and that is augmentation.

That is not a failure of ambition. It is what the work is. Consequential enterprise decisions have owners because someone decided they should, usually after something went wrong, and the machinery of approval matrices and segregation of duties is the residue of institutional memory. Redesigning around AI does not entitle you to skip that history; it entitles you to make those decisions dramatically cheaper to make well.

## The pressure to skip straight to autonomy

Be honest about where the pressure comes from. "We have agents running the process end to end" is a better slide than "our analysts now decide in five minutes what used to take four hours", even though the second sentence describes more value and more of it delivered. Autonomy photographs well. Augmentation shows up in the cycle time and nowhere else.

The failure mode is predictable. An autonomous step goes live on a process whose exception rate was never measured; the exceptions arrive; nobody is watching the log because the monitoring was built for a demo; a bad run reaches a customer or a regulator; the whole programme is paused, including the augmentation work that was quietly succeeding. That recovery takes far longer than doing it in the right order would have.

Do it in the right order. Run the step as augmentation, keep the human decision, and instrument it: record every case, what the model proposed, what the human did with it, and where they disagreed. After a few months you have the one thing that makes an autonomy decision honest — evidence about the exception rate and where the failures cluster. Then narrow the remit to the cases the evidence supports, put real limits in code, name the owner, and let it run. Autonomy earned that way survives its first incident, because the incident was anticipated and someone owns it.

## The three sit inside one process

None of this is a choice you make once for a whole workflow. A single payment cycle can hold all three: the file generation and limit checks automated, the exception queue augmented with a model that assembles the context around each broken item, and a narrow, well-evidenced slice — say, auto-clearing a category of low-value matched items inside a hard limit — run autonomously. That is a mature design, and it looks nothing like a ladder.

The design work is the same as anywhere else in [taking a workflow apart](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow): decide what each step is, on purpose, and be able to say why. It is the same discipline as forcing [an explicit decision instead of a default yes](https://gravam.com/blog/05-commit-before-clear) — the value is in being made to choose, and to write down which mode this step is in and what would have to change for it to move. Where the architecture and control layer around all this lives is the subject of the [enterprise AI systems](https://gravam.com/topics/enterprise-ai-systems) notes.

***

_See also [the anatomy of an AI-native enterprise workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow), [how AI agents fit into existing enterprise systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems), and the question underneath all three modes: [who is allowed to decide what](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows)._

## Questions this article answers

**Q: What is the difference between AI augmentation and AI autonomy?**

Augmentation means the machine prepares the work and a person decides: it reads the inputs, assembles the evidence, drafts a recommendation, and a named human accepts, changes or rejects it. Autonomy means the machine decides and acts inside a bounded remit — defined limits, defined data, defined actions — and the human moves from deciding each case to setting the boundary and reviewing what came out of it. The distinction is not how capable the model is. It is where the decision sits, and who is answerable for it when the decision turns out to be wrong.

**Q: When does a task justify an autonomous AI agent?**

When four things hold at once: the action is reversible or cheaply corrected, the blast radius of a bad run is bounded by real limits rather than good intentions, the exception rate is low and understood from evidence rather than assumed, and someone in the control environment owns the outcome by name. Add a fifth practical test — the remit has to be narrow enough to write down in a sentence. Most enterprise work fails at least one of these, usually the exception rate, and the honest response is to run it as augmentation until the evidence changes.

**Q: Why is augmentation the right default for most enterprise work?**

Because most consequential enterprise work is judgement applied to messy inputs, and the expensive part is assembling the evidence, not making the call. Augmentation attacks exactly that: the machine does the reading, gathering and drafting, and the person spends their time on the decision instead of the preparation. It also keeps the control environment intact — the same named approver, the same audit trail — so it can be adopted without renegotiating how the organisation is governed. It is the fastest real gain available and the one that survives contact with an auditor.

---

# The Anatomy of an AI-Native Enterprise Workflow

Source: https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow
Topic: AI Workflow Design — https://gravam.com/topics/ai-workflow-design
Author: Tan Gravam
Published: 2026-08-18
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: Take a complex process apart: what must stay deterministic, what AI genuinely does well, what a named human decides, and the state the work has to hold.

**An AI-native workflow is one taken apart into five columns — what must stay a deterministic rule, what a model may judge, what a named human decides, what state the work has to hold, and what happens to the exceptions — and then rebuilt around those answers rather than around the old sequence.** The textbook version of "adding AI" is a copilot bolted onto one step instead: same intake, same handoffs, same approvals, one of them now faster. What that actually produces is a step that used to take twenty minutes and now takes five, sitting inside a process that still takes eleven days — because the eleven days were never in that step. The hours live in the waiting, the chasing, the re-keying, and the exceptions nobody owns.

An AI-native workflow is a different exercise. You take the process apart into what its pieces really are, and you decide, deliberately, which pieces stay as rules, which go to a model, which belong to a named human, and what has to be held in an application so the work can be picked up again next week. That decision — which is which — is the design work. Everything else is tooling.

This is the method I use, and it fits on a whiteboard.

## First, find where the hours actually go

Before anything is redesigned, map the process as it runs, not as the procedure document describes it. Two columns: the step, and the honest reason it takes as long as it does.

You will nearly always find that the elapsed time is not in the work. It is in someone waiting for a file, someone reading a mailbox to find out which of forty replies matters, someone copying figures into a spreadsheet that a third system will later import, and someone with a queue of exceptions they get to on Friday. Take a cash forecast cycle: the arithmetic is trivial and instant, but [collecting and reconciling the inputs](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) from entities on different systems is where the week goes.

That map also tells you where a redesign is worth doing at all. If the hours sit in a step you cannot change — a bank's cut-off, a regulator's window — no amount of AI moves it, and the honest answer is to redesign something else.

## The part that must stay a rule

Now split the work. The first pile is everything that must be deterministic, and the rule for what goes in it is short: anything whose answer must be identical every time it is asked, and anything a control depends on.

In practice that is:

- **Calculations.** Totals, allocations, interest, valuations, tax. A number that can vary between two runs on the same inputs is not a number a controller can sign.
- **Limits and thresholds.** Credit lines, approval bands, exposure caps. These are policy expressed as code, and they are checked, not judged.
- **Postings and writes to a system of record.** What lands in the ledger is generated by code from validated data, on a defined path, with a reversal path.
- **Entitlement and segregation of duties.** Who may see, who may approve, who may release — and the rule that they are not the same person.
- **Routing and status transitions.** What moves where, and what state a record is allowed to be in next.

None of this is a candidate for a model, ever. It is cheap to write, easy to test, and — the part people miss — it is what makes the AI parts usable. A drafted journal entry is only safe to put in front of a human because the totals it is checked against are calculated deterministically. The rules are the firm ground the probabilistic parts get measured on.

## The part AI is genuinely good at

The second pile is real, and it is bigger than sceptics think. Models are strong at the work that has always been done by an experienced person reading things:

- **Reading unstructured input.** The email with the amount in the third paragraph, the PDF confirmation, the free-text remittance line, the attachment someone sent instead of filling in the form.
- **Classifying.** This is a rate query, that is a dispute, this belongs to the entity in Poland.
- **Synthesising.** Twelve replies from six entities into one summary of what changed and what is still missing.
- **Drafting.** The chaser, the memo, the proposed mapping, the first version of the answer.
- **Spotting the odd one out.** Not "computing the variance" — that is a rule — but noticing that the explanation attached to a variance does not match the pattern of the last six months.

What these have in common is that a wrong answer is visible and recoverable. A misclassified email gets reclassified. A weak draft gets rewritten. That is the real test for putting a model on a task: when it is wrong, does someone notice cheaply, and is the cost of being wrong small? Where the answer is no, you either move the task back to rules, or you put a human decision immediately after it — which is the next pile.

> The test for handing a task to a model is not whether it can do it. It is whether being wrong is visible and cheap.

Design the boundary properly while you are here. The model's output should have a defined shape the surrounding code can validate and reject — the same discipline as [output contracts and failure handling](https://gravam.com/blog/ai-output-contracts-and-failure-handling) in a product — and the workflow should have a defined behaviour for the day the model returns nothing useful.

## The decisions that need a name on them

The third pile is decisions, and the question is not "can AI do this?" but "who is answerable when it is wrong?"

Some decisions have consequence that is hard to reverse, or that lands on someone outside the process: releasing a payment, accepting a counterparty, agreeing a write-off, approving a change to a control. Those get a named human, not a role, not a committee — one person whose name is on it. This is the same reason [an owner is a person, not a team](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams), and the same line I hold when I build: [the machine executes; the judgement stays mine](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows).

The redesign is not about removing that person. It is about making their decision cheap. If the model has read everything, assembled the evidence, drafted the recommendation and flagged what does not fit, the human's job shrinks from four hours of assembly to five minutes of judgement — and the judgement is better, because they are looking at a complete picture instead of the three tabs they had time to open. Which of the three modes a given piece of work deserves is the subject of the [automation, augmentation and autonomy](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy) split.

## The state the workflow has to hold

Here is where most AI redesigns quietly fail, and it has nothing to do with models.

Enterprise work is resumable. It is started by one person on Monday, continued by another on Thursday, questioned by an auditor in March, and it must survive all of that. That requires state a conversation does not have:

- **A record with an owner and a status**, visible to everyone in the queue rather than living in one person's transcript.
- **Versions.** What the figure was, what it is now, who changed it and why.
- **An audit trail.** Which action, by which identity, at which time, on which data.
- **Reference data and entitlements**, so the same question asked by two people gets two correctly scoped answers.
- **Resumability.** Someone opens it next week and sees exactly where it stopped and what it is waiting for.

This is the whole reason an AI-native workflow ends up as an application with a model inside it, rather than a chat window with a clever prompt. The model does the reading and the drafting; the application is where the work lives. Conflating the two usually shows up three months in, when the pilot cannot answer "what happened, and who approved it?"

## The exception path is the workflow

Every enterprise process has a happy path that everyone designs and an exception path where the work actually is. Straight-through items were never the problem — they already flow. The cost sits in the items that do not match, do not balance, arrive late, or arrive in the wrong format.

So [design the exception path first](https://gravam.com/blog/designing-the-exception-path), and be specific about four things: how an exception is detected, who it is routed to, what information travels with it, and what the resolution writes back so the next one is handled better. This is where AI earns most of its value, because assembling the context around a broken item — the related documents, prior cases and correspondence, in one place — is exactly the reading and synthesising work models do well, and it is the part that currently eats a specialist's afternoon.

## Run your own process through it

On a whiteboard, five columns. Take one real workflow and place every step:

| Column | The question | What it produces |
| --- | --- | --- |
| **Rule** | Must this be identical every time, or does a control depend on it? | Deterministic code |
| **Model** | Is this reading, classifying, synthesising or drafting — and is being wrong visible and cheap? | An AI step with a validated output |
| **Human** | Is this consequential or hard to reverse? Who is answerable? | A named decision, made cheap |
| **State** | What must be held, versioned or evidenced for this to be resumable and auditable? | The application |
| **Exception** | What happens when this step fails or does not match? | The path where the hours are |

If a step cannot be placed, it is not understood well enough yet, and that is a finding rather than a failure. If everything lands in "model", the design is wishful. If nothing does, you have written a requirements document for software you already have.

The last question decides whether any of it gets funded: [what is true when this works](https://gravam.com/blog/how-to-define-a-measurable-outcome), stated as something you can measure before and after. Days in the cycle, items touched by hand, exceptions still open at close. A redesign that cannot name its number is a demo with a business case bolted on afterwards, and it gets reorganised away a year after go-live. More of this method sits in the [AI workflow design](https://gravam.com/topics/ai-workflow-design) notes.

***

_See also [automation, augmentation and autonomy](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy), [how to define a measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome), and this method applied to a real process: [the cash-forecasting teardown](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting)._

## Questions this article answers

**Q: What makes a workflow AI-native rather than AI-assisted?**

An AI-assisted workflow keeps its original shape and adds a model to one step — the same handoffs, the same approvals, one of them now faster. An AI-native workflow is redesigned around what each part of the work actually is: the calculations and controls stay deterministic code, the reading and drafting and classifying go to a model, the decisions that carry consequence go to a named human, and the whole thing runs inside an application that holds state, versions and an audit trail. The test is simple. If you removed the model, would the process be the old process again? If yes, it was assisted, not redesigned.

**Q: Which parts of an enterprise process should stay deterministic?**

Anything whose answer must be identical every time it is asked, and anything a control depends on. That means calculations and totals, limit and threshold checks, entitlement and segregation-of-duties rules, postings to a system of record, and the routing logic that decides who sees what. These are cheap to express as code, easy to test, and easy to audit — and a probabilistic component adds nothing to them except a new failure mode. Keeping them deterministic is also what makes the AI parts safe to use, because the model's output has something firm to be checked against before it moves.

**Q: Why can a chat window not replace an enterprise application?**

Because a conversation has no state that survives it. Enterprise work is resumable — someone picks up on Thursday what someone else left on Monday — and that needs things a chat window does not hold: a record with an owner and a status, versions of what changed and why, an audit trail that ties an action to a person and a time, and a queue everyone is looking at rather than a private transcript. The model can live inside the application and do the reading and drafting. What it cannot do is be the place the work lives.

---

# MCP Server in Front of SAP: Where Authorization Lives

Source: https://gravam.com/blog/mcp-server-sap-authorization
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: An MCP server adds a hop, not a control. Where authorization, segregation of duties and logging live when an agent calls SAP through MCP, and what MCP solves.

**An MCP server in front of SAP adds a hop, not a control. The Model Context Protocol governs how an agent's client authenticates to the MCP server, and it forbids passing that token on. The MCP server then calls SAP with a separate credential, and whichever user that credential logs on as is the user SAP checks, logs and writes on the document.** Authorization, segregation of duties and the record of what happened all live on the SAP side of the MCP server, in the identity used for that second hop and in the checks the called code performs. If they aren't designed there, they don't exist anywhere.

The case for [putting a service layer between an agent and the ERP](https://gravam.com/blog/connecting-ai-agents-to-your-erp) is made elsewhere on this site. MCP is now the most common way that layer gets built, so this page reads the protocol as it currently stands, revision 2026-07-28, against the SAP side, and marks where each responsibility actually sits.

## What MCP standardizes

MCP is an open protocol, built on JSON-RPC, for connecting LLM applications to tools and data. A **host** application runs **clients** that connect to **servers**, and servers expose tools with schema-described inputs and outputs. The 2026-07-28 revision made the protocol stateless, and it defines two transports that matter here: STDIO for a local process, and Streamable HTTP for a remote server.

Its authorization rules are narrower than people assume:

- Authorization is **optional**. When supported, HTTP-based implementations **should** follow the specification's OAuth 2.1 model. STDIO implementations **should not**, and instead retrieve credentials from the environment.
- A protected MCP server acts as an **OAuth 2.1 resource server**. It must validate that access tokens were issued specifically for it as the intended audience, and reject the rest.
- MCP servers **must not accept or transit any other tokens**. The security considerations spell out the consequence: if the server calls upstream APIs, the token it uses there is a separate token, issued by the upstream authorization server, and the MCP server must not pass through the token it received from the client.

The last rule is the one that matters for SAP. The protocol deliberately stops at its own boundary: MCP gives you a well-authenticated call into the MCP server and says nothing about the call out of it.

The STDIO rule deserves a second look in a finance context. "Credentials from the environment" on a developer laptop running a local MCP server against SAP usually means a stored SAP user and password. That is usually a technical user, and nobody reviews it.

## Three hops, three owners

| Hop | What decides who is allowed | Who owns it |
| --- | --- | --- |
| 1. Agent client → MCP server | MCP authorization: OAuth 2.1, audience-bound tokens, scopes | Whoever runs the MCP server and its IdP |
| 2. MCP server → SAP | The credential the server uses: technical user, propagated user, agent user | You, and nothing in MCP decides it |
| 3. Inside SAP | Authorization checks against authorization objects for the logged-on user | SAP roles, and the code being called |

Most designs spend their effort on hop 1, because that's where the protocol has something to say. Hop 1 decides who may talk to the MCP server. What they can do in SAP is decided at hops 2 and 3.

## Hop 2: technical user or principal propagation

This is the same decision [agent identity](https://gravam.com/blog/agent-identity-and-permissions) lays out in general. The MCP server is simply the place it gets made.

**A technical user** is the default because it's one credential in one configuration file. SAP sees one identity for every requester. Documents name the integration. Every authorization check runs against the union of rights that user accumulated, and revoking it stops every agent at once. A well-built OAuth flow at hop 1 doesn't change any of that: the requester's identity is authenticated all the way to the MCP server, then discarded at the one place SAP could have used it.

**Principal propagation** carries the requesting person's identity into SAP, so SAP's existing roles apply to the call. It's the model SAP itself describes for [Joule and its other finance AI](https://gravam.com/blog/sap-cash-application-ai): the assistant acts on behalf of the logged-on user through principal propagation, with the Cloud Connector creating a backend-consumable identity from the trusted user context, and actions subject to that user's roles. For an MCP server, the equivalent is to exchange the requester's identity for an SAP-side credential at hop 2, which the specification's "separate token issued by the upstream authorization server" explicitly allows, rather than logging on as itself.

Its costs are real and should be stated. The agent inherits everything that person can do, not just what the task needs, and the document names a person who didn't click. The strongest arrangement combines the two: an **agent-specific SAP user whose effective rights are bounded by the requester**, with the requester recorded. It costs more to build, and it's the only arrangement where an SAP document answers both questions an investigation asks: what acted, and for whom.

> The MCP spec authenticates the requester all the way to the MCP server. A technical user then throws that identity away at the one place SAP could have used it.

## Hop 3: where authorization really runs

Inside SAP, authorization is performed by the code being called, against the user it runs as. SAP's own ABAP guidance is blunt about the parts people forget:

- An `AUTHORITY-CHECK` statement checks whether an authorization is available **for the current user**, determined by values in an authorization object.
- **ABAP SQL statements trigger no authorization checks** in the database. Tables can be read without restriction, and SAP states that it's up to the programmer to ensure the user is authorized for the data the program handles.
- Reads through CDS can be protected implicitly by **CDS access control**, if the view has an access control defined and enforced.
- A `sy-subrc` of 0 means the check succeeded **or no check was performed**.

Put an MCP server in front of that and the risk becomes concrete. Released BAPIs and OData services carry the application's own authorization checks. A custom function module or service written quickly "for the MCP server", one that selects from tables and returns the rows, carries only the checks its author remembered to write. The MCP server will expose it with a clean JSON schema, and nothing about the schema tells you whether it checks anything.

So the rules for hop 3 are simple:

1. **Expose released APIs, not custom table reads.** Where a custom wrapper is unavoidable, review its authorization checks like any other code going to production.
2. **Test with the SAP identity from hop 2, not with a developer user.** A tool that works in testing with broad developer authorizations and fails in production is behaving correctly.
3. **Treat tool annotations as descriptions, not controls.** The specification itself says clients must consider tool annotations untrusted unless they come from trusted servers. A tool described as harmless is harmless only if the SAP user behind it can't do harm.

## Segregation of duties lives in two places

With MCP, segregation of duties has to hold in two lists:

- **The tool list.** An MCP server exposing a generic "call any BAPI" or "run any OData query" tool is the direct connection with a new label. The operation list should be written by you, one verb and one scope per tool, as argued in [connecting agents to the ERP](https://gravam.com/blog/connecting-ai-agents-to-your-erp). An MCP server that creates vendors and one that proposes payments shouldn't be the same server.
- **The SAP identity at hop 2.** Run its composite authorizations through the SoD ruleset you already own, as though it were a person. A conflict there is a [design defect](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents), whatever the tool list says, because a tool list can change in a deployment and an SAP role is what the auditor tests.

The specification adds a layer on top, but it's advisory. There **should** always be a human in the loop with the ability to deny tool invocations. Clients **should** prompt for confirmation on sensitive operations and show tool inputs before calling. Servers **must** validate inputs, implement proper access controls and rate-limit. Those are good requirements. But the client-side ones are only as reliable as whichever client connects, which is why the release of anything that moves money belongs in SAP's own approval path and [not in the agent layer](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment).

## Logging: three logs, one record

An agent calling SAP through MCP produces up to three logs, and only one of them is evidence.

| Log | Written by | What it is |
| --- | --- | --- |
| Client tool-usage log | The agent host | The specification says clients **should** log tool usage for audit purposes. It's the agent's account of itself |
| MCP server log | Your integration | What the server was asked, and what it sent on to SAP |
| SAP's own record | The system of record | The document, its created-by field, its change history |

The protocol is candid about the first. The 2026-07-28 revision **deprecated MCP's own Logging feature**, suggesting stderr or OpenTelemetry instead. It was never an audit mechanism, and nothing in MCP produces evidence of what SAP did. That evidence is SAP's own record, and the MCP logs become useful only when [reconciled against it](https://gravam.com/blog/ai-agent-logs-are-not-an-audit-trail).

Make that reconciliation cheap from the first release. Have every write tool return the SAP document number and log it in the MCP server alongside the requester, the tool, the inputs and the hop-2 identity. The specification documents OpenTelemetry trace context propagation through request metadata, which helps correlate client, server and downstream call, but the join that matters to an auditor is the one to the SAP document.

## What MCP solves, and what it doesn't

| MCP solves | MCP leaves to you |
| --- | --- |
| A standard way to describe, discover and call tools | Which tools exist, and which are allowed to write |
| OAuth 2.1 protection of an HTTP MCP server, with audience-bound tokens | Which SAP identity the server uses at hop 2 |
| A ban on token passthrough | How the requester's identity reaches SAP, if at all |
| Portability across agent platforms | SAP authorization checks, SoD, release steps, evidence |
| Guidance on human confirmation and input validation | Enforcing either for a client you don't control |

Nothing about the protocol changes the [indirect-access licensing question](https://gravam.com/blog/connecting-ai-agents-to-your-erp) either: an agent creating documents through an MCP server is still a non-human source creating documents.

One more distinction avoids a common confusion. SAP does publish MCP servers, for example `@sap-ux/fiori-mcp-server`, which runs over STDIO to help AI coding assistants create and modify Fiori apps, and `@cap-js/mcp-server` for CAP projects. Those are **developer tools**. They help build applications. They aren't a governed runtime entry point to finance data, and their existence doesn't answer any of the hop-2 or hop-3 questions above.

## Rules for an MCP server in front of SAP

- Put an MCP server in front of SAP only with a written tool list: one verb, one scope, and no generic query or call-anything tools.
- At hop 2, use principal propagation or an agent-specific SAP user bounded by the requester, and never a shared technical user for anything that writes.
- Expose released BAPIs and OData services, and review any custom wrapper's authorization checks before it ships.
- Run the hop-2 identity through the SoD ruleset as though it were a person.
- Keep release of payments and postings in SAP's own approval path, with a second human — [what actually lands in the system](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) is decided there, not in the server.
- Return and log the SAP document number on every write, so the MCP log can be reconciled to the system of record.

MCP is a good protocol for a narrow job, and the specification is careful about the edge of that job. The mistake is assuming the protocol's authorization story continues past that edge. It stops at the MCP server, and SAP's starts at the next logon.

_See also [how AI agents fit into existing enterprise systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems), [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) and the [OWASP LLM Top 10 for enterprise finance](https://gravam.com/blog/owasp-llm-top-10-2026-for-enterprise-finance)._

## Primary sources

Model Context Protocol specification revision 2026-07-28 (authorization, security considerations, tools, changelog), read from the specification source; ABAP authorization behaviour as described in SAP's ABAP cheat sheet for the SAP BTP ABAP Environment; Joule principal propagation as described by SAP; SAP's open-source Fiori and CAP MCP servers as published. Checked on 2026-09-25 through the specification source and cross-checked excerpts of the listed sources. SAP-side object names beyond these are deliberately not listed: verify the authorization objects your own BAPIs and OData services check.

- Model Context Protocol — Specification 2026-07-28: Authorization — accessed 2026-09-25 — https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- Model Context Protocol — Specification 2026-07-28: Authorization security considerations (token passthrough, upstream APIs) — accessed 2026-09-25 — https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations
- Model Context Protocol — Specification 2026-07-28: Tools (human in the loop, untrusted annotations, security considerations) — accessed 2026-09-25 — https://modelcontextprotocol.io/specification/2026-07-28/server/tools
- Model Context Protocol — Specification 2026-07-28: Key Changes (Logging deprecated) — accessed 2026-09-25 — https://modelcontextprotocol.io/specification/2026-07-28/changelog
- SAP-samples — ABAP cheat sheets: Authorization Checks — accessed 2026-09-25 — https://github.com/SAP-samples/abap-cheat-sheets/blob/main/25_Authorization_Checks.md
- SAP Community (SAP) — From Prompt to Permission: How Joule Securely Accesses SAP Cloud ERP Private — accessed 2026-09-25 — https://community.sap.com/t5/technology-blog-posts-by-sap/from-prompt-to-permission-how-joule-securely-accesses-sap-cloud-erp-private/ba-p/14480012
- SAP Community (SAP) — Joule A2A: Propagate the User Identity from Joule into S/4HANA — accessed 2026-09-25 — https://community.sap.com/t5/technology-blog-posts-by-sap/joule-a2a-propagate-the-user-identity-from-joule-into-s-4hana/ba-p/14420290
- SAP open-ux-tools — @sap-ux/fiori-mcp-server README — accessed 2026-09-25 — https://github.com/SAP/open-ux-tools/tree/main/packages/fiori-mcp-server
- cap-js — @cap-js/mcp-server README — accessed 2026-09-25 — https://github.com/cap-js/mcp-server

## Questions this article answers

**Q: Does an MCP server handle authorization for SAP?**

No. The MCP specification covers how an MCP client authenticates to the MCP server, using OAuth 2.1 for HTTP-based transports with tokens bound to that server as their audience. It explicitly forbids the server from passing that token on: a call from the MCP server to an upstream API such as SAP uses a separate credential. SAP then checks its own authorization objects against whatever user that credential logs on as. Authorization for the business action therefore lives in SAP and in the identity choice at that second hop, not in MCP.

**Q: Should an MCP server call SAP as a technical user or with principal propagation?**

Principal propagation, or an agent-specific user bounded by the requester, for anything beyond low-risk reads. A single technical user makes every requester look the same to SAP: the documents name the integration, the SAP authorization checks run against the union of rights the technical user holds, and revoking it stops everything at once. Principal propagation carries the requesting person's identity into SAP so the existing roles apply, which is the model SAP itself describes for Joule; its cost is that the agent inherits that person's full rights and the documents name someone who did not click.

**Q: Is an MCP server log an audit trail for SAP postings?**

No. It is the integration's account of what it asked for, written by the component under review. The specification recommends that clients log tool usage for audit purposes and deprecated its own protocol logging feature in the 2026-07-28 revision in favour of stderr or OpenTelemetry, so nothing in MCP produces evidence of what SAP did. The evidence is SAP's own record, the documents and their change history, and the MCP log becomes useful when it is reconciled against that record using the document numbers SAP returned.

**Q: What does MCP actually solve for enterprise integration?**

A standard way for an agent to discover and call tools, with schema-described inputs and outputs, and a standard OAuth-based way to protect an HTTP-based MCP server with audience-bound tokens. That makes an integration portable across agent platforms. It does not decide which SAP identity is used, which authorizations apply, how segregation of duties is enforced, which steps need human release, or how the action is evidenced. Those remain design decisions on the SAP side.

---

# SAP Cash Application and Joule: What SAP's AI Posts

Source: https://gravam.com/blog/sap-cash-application-ai
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: What SAP Cash Application, payment advice extraction and Joule actually do in finance: what posts, under whose authorizations, and what has to stay human.

**SAP's own AI in finance is three different things that are easy to lump together. SAP Cash Application proposes matches between incoming payments and open receivables and, above a confidence threshold you set, clears them automatically under a job user's authorizations. Payment advice extraction turns unstructured remittances into structured data for that matching. Joule is a conversational layer that acts as the logged-on user.** None of them changes who is accountable for the posting. What they change is how many postings happen before anyone looks.

The [general question of what an agent leaves behind in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) applies to third-party agents and SAP's own alike. This page applies it to SAP's own finance AI, as documented in September 2026, and sticks to what each one does rather than to the roadmap.

## The three, side by side

| Capability | What the AI does | What posts | Under whose authority | What stays human |
| --- | --- | --- | --- | --- |
| **SAP Cash Application** | Proposes matches of bank statement items to open items, from learned clearing history | Clearing documents, automatically above the threshold | The job user of the reprocessing job | Setting the threshold; working the proposals below it |
| **Payment advice extraction** | Reads remittance data out of PDFs, images and emails | Nothing by itself: it supplies data used for matching | The integration that imports the advices | Correcting extraction errors; unmatched advices |
| **Joule (finance)** | Finds apps, answers from documentation, and runs transactional capabilities in conversation | Whatever the transactional capability creates, such as a bank transfer | The logged-on user, through principal propagation | Approval and release steps behind the app |

The rest of the article takes them one at a time, because the controls differ.

## SAP Cash Application: a model inside the reconciliation

SAP Cash Application uses machine learning trained on **your own past clearing decisions**. SAP describes a daily loop. Bank statement items that the standard processing rules could not handle are sent to the service along with the open receivables. The model returns matching proposals to SAP S/4HANA, and proposals that meet a configurable confidence threshold are cleared automatically. Training runs regularly, so the model picks up changes in how customers pay and how accountants clear.

In S/4HANA the mechanics are specific:

| Object | Role |
| --- | --- |
| Job template _SAP Cash Application: Automatic Bank Statement Reprocessing_ | Scheduled accounts receivable job that receives ML proposals for bank statement items and clears them automatically |
| Communication scenario `SAP_COM_0650` | The integration between S/4HANA Cloud and the matching service |
| Cash Application Integration (1MV) | The licence SAP names as a prerequisite for the job template |
| Reprocess Bank Statement Items app | Where items the system could not post and clear automatically are worked by an accountant |
| ML-based Cash Application training scenarios | Separate training for incoming and outgoing payments (supplier-side matching exists too) |

The order matters. The model sits **after** the deterministic layer, the [bank statement posting rules and interpretation algorithms](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) and processing rules, and works on what those left over — the items that would otherwise sit in [FEBAN post-processing](https://gravam.com/blog/feban-bank-statement-post-processing). That's the right architecture, and the same one the [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) arrives at from first principles: deterministic rules where the rule is knowable, a model for the residue, a human for what the model isn't sure of.

### The threshold is a control, and someone has to own it

The confidence threshold decides which clearings a person sees and which they never see. That makes it a control setting, not a tuning parameter, and it deserves what any control setting gets: an owner in finance rather than in IT, a documented rationale, a change process, and a periodic review against evidence.

Three things make this control unusual. **The population is invisible by design**: auto-cleared items don't pass through anyone's worklist, so the only way to review them is to report on them, and that report has to exist from the first day. **The behaviour changes without a configuration change**: a model that retrains regularly can clear differently next quarter at the same threshold, so the auto-clear rate and the rate of later reversals need monitoring as trends, not checking once. And **a wrong clearing looks exactly like a right one** on the document, so the evidence of a problem is downstream: disputes, dunning of customers who paid, unapplied cash.

### Whose name is on the clearing document

Automatic clearing is performed by an application job, which settles the identity question. SAP S/4HANA Cloud separates the **job owner**, the business user who schedules the job, from the **job user**, whose authorizations apply while the job runs. The Maintain Job Users app manages the pairing, and the job user can be an SAP technical user.

So the clearing documents carry whichever identity you chose there. It's the same decision [agent identity](https://gravam.com/blog/agent-identity-and-permissions) describes, arriving through the job scheduler rather than an agent framework. A job user dedicated to Cash Application, with authorizations limited to clearing, is traceable and revocable. A shared batch user that also runs the payment program isn't, and it also puts clearing and payment in one identity, which is the combination [segregation of duties](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) exists to keep apart.

> The confidence threshold decides which clearings a person ever sees. That makes it a control setting with an owner, not a tuning parameter.

## Payment advice extraction: better inputs, not decisions

The second capability is less visible and often more valuable. Customers send remittance information as PDFs, scans and email bodies. SAP's **Payment Advice Extraction** service uses OCR and machine learning to pull the relevant fields (invoice references, amounts, deductions) out of those documents and make them available for automatic processing in SAP.

Nothing posts because of an extraction. The advice feeds the matching, which is where the risk sits. An extraction error that swaps two invoice numbers produces a confident, wrong match downstream. The control is on the matching side: keep extracted advices traceable to their source document, so an accountant can open the original PDF behind any clearing in one step. That's the [independent-evidence requirement](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) in its simplest form.

## Joule: the user's authority, in a conversation

Joule is SAP's assistant across its applications. For SAP S/4HANA Cloud, SAP documents three kinds of capability: **navigational** (finding the right app), **informational** (grounded answers from SAP documentation) and **transactional** (viewing business objects and performing actions inside the conversation). In finance, SAP's capability list includes cash and liquidity items such as displaying cash positions and **making bank transfers**, alongside capabilities like fixed asset master data and one SAP calls Payment Resolution.

The authorization model is what matters here, and SAP describes it consistently. Joule **acts on behalf of the logged-on user through principal propagation**. Actions run as the authenticated user, subject to that user's existing roles. Transactional capabilities need the relevant **OData services activated**, and capabilities are tied to the semantic objects and actions in the user's roles, so a user only reaches through Joule what their roles already reach. It's the arrangement worth copying when you build your own agent access, for example [an MCP server in front of SAP](https://gravam.com/blog/mcp-server-sap-authorization), where the default tends to be a technical user instead.

Two conclusions follow, and both are easy to get wrong in a steering committee.

**Joule doesn't add authority.** A user who can't make bank transfers in the app can't make them through Joule. Anyone worried about an assistant escalating privileges should look at the roles, not the assistant.

**Joule doesn't remove authority either.** A user who can make bank transfers in the app can now make them in a sentence. The friction of navigating to the app, which sometimes worked as an informal pause, is gone. If the only thing standing between a request and a transfer was that the user had to go and find the screen, there was no control there to begin with. What holds is the approval and release configured behind the transaction, with a different person releasing. [Whether an agent can approve its own payment](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment) is answered by that release path, and it's worth confirming in your own configuration exactly which release steps apply to transfers created this way.

## What stays human

Across all three, the human work moves rather than disappears:

- **Owning the threshold** for automatic clearing, and signing off every change to it.
- **Working the proposals below it**, with the source evidence, not the model's summary, on screen.
- **Reviewing the auto-cleared population** by report, on a cycle, with reversal and dispute rates as the signal.
- **Releasing payments and transfers** as a second person, whether they were created in an app, a job or a conversation.
- **Owning the job user and the roles** behind each capability, including the leaver and review process for technical identities.

## Guardrails for Cash Application auto-clearing

Use Cash Application behind the deterministic rules, not instead of them. Give it a dedicated job user limited to clearing, and never the batch user that runs payments. Put the threshold under finance ownership with a documented rationale, and build the auto-clear population report before go-live, not after the first audit. Keep every extracted advice traceable to its source document. Treat Joule as a new front end to existing authority: review the roles it exposes, and rely on the release step, not on the interface, for anything that moves cash.

None of this is a reason to hold back. Matching is where finance teams spend hours on work a model does well. The design question is only whether, a year from now, you can still show who decided what, and on what evidence.

_See also [connecting AI agents to your ERP](https://gravam.com/blog/connecting-ai-agents-to-your-erp) and [what the enterprise AI control layer owns](https://gravam.com/blog/the-enterprise-ai-control-layer)._

## Primary sources

SAP Cash Application integration with SAP S/4HANA (Cloud Public Edition and on-premise), the SAP Cash Application payment advice extraction service, and Joule for SAP S/4HANA Cloud as documented in September 2026. Product capabilities, capability lists and licensing move quickly: claims were checked on 2026-09-25 through cross-checked excerpts of the listed sources (SAP Help pages could not be opened directly), and nothing here describes roadmap items. Verify availability for your edition and release.

- SAP — SAP Cash Application use case (reduce accounts receivable matching effort) — accessed 2026-09-25 — https://www.sap.com/use-cases/reduce-accounts-receivable-matching-effort
- SAP Help — Cash Application: Automatic Bank Statement Reprocessing (SAP_COM_0650) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/918bca53037f408f91a2295d04ac16bc/213464e4cbff420b90659e652136d6fd.html
- SAP Help — Cash Application: Automatic Bank Statement Reprocessing (on-premise job template) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/213464e4cbff420b90659e652136d6fd.html
- SAP Help — Reprocess Bank Statement Items — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/918bca53037f408f91a2295d04ac16bc/bc1fe656fe590950e10000000a44147b.html
- SAP Learning — Explaining the SAP Cash Application and Machine Learning — accessed 2026-09-25 — https://learning.sap.com/courses/sap-s-4hana-cloud-for-contract-accounting-invoicing/explaining-the-sap-cash-application-and-machine-learning
- SAP Help — Payment Advice Extraction (SAP Cash Application) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_CASH_APPLICATION/bd1c2b6071a54d08845c4b6f5ecaec58/c2a229c923294352a65c9a3c18f998a8.html
- SAP Help — Machine Learning Based Cash Application: Training for Outgoing Payment — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/b8c08e0197454541a11f8d46ef1ab96e/b18618deaa904d2b80ba2449f31dcec6.html
- SAP Learning — Maintaining Job Users and their Authorizations (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://learning.sap.com/courses/administrating-sap-s-4hana-cloud-public-edition/appendix-maintaining-job-users-and-their-authorizations
- SAP Help — Joule Capabilities: Joule in SAP S/4HANA Cloud Public Edition — accessed 2026-09-25 — https://help.sap.com/docs/joule/capabilities-guide/joule-in-sap-s-4hana-cloud-public-edition
- SAP Community (SAP) — From Prompt to Permission: How Joule Securely Accesses SAP Cloud ERP Private — accessed 2026-09-25 — https://community.sap.com/t5/technology-blog-posts-by-sap/from-prompt-to-permission-how-joule-securely-accesses-sap-cloud-erp-private/ba-p/14480012
- SAP Community (SAP) — Joule A2A: Propagate the User Identity from Joule into S/4HANA — accessed 2026-09-25 — https://community.sap.com/t5/technology-blog-posts-by-sap/joule-a2a-propagate-the-user-identity-from-joule-into-s-4hana/ba-p/14420290

## Questions this article answers

**Q: What does SAP Cash Application actually do?**

It matches incoming payments to open receivables using a machine learning model trained on the company's own historical clearing. Bank statement items that the deterministic processing rules could not clear are sent with the open items to the service, which returns matching proposals to SAP S/4HANA. Proposals above a confidence threshold you configure are cleared automatically by a scheduled job; the rest stay as proposals for an accountant to accept or reject. A separate service extracts payment advice data from PDFs, images and emails so that remittance information is available for matching.

**Q: Whose authorizations does SAP Cash Application auto-clearing run under?**

Under the user the clearing job runs as. Automatic clearing is performed by an application job, and SAP S/4HANA Cloud separates the job owner, the business user who schedules it, from the job user, whose authorizations apply while it runs and which can be an SAP technical user. That job user is the identity on the clearing documents, so choosing it, scoping it and reviewing it is part of the control design, not a technical detail.

**Q: Does Joule bypass SAP authorizations?**

No, and it does not reduce them either. SAP describes Joule as acting on behalf of the logged-on user through principal propagation, with actions subject to that user's existing roles, and transactional capabilities require the relevant OData services to be active. Whatever a user may do in the underlying app, including creating a bank transfer, they may do through Joule. Segregation of duties therefore still depends on the roles and the approval steps behind the app, not on the assistant.

---

# Your AI Agent's Logs Are Not an Audit Trail

Source: https://gravam.com/blog/ai-agent-logs-are-not-an-audit-trail
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: A log the agent writes about itself is testimony, not evidence. What an auditor tests instead — completeness, independence, retention — and how to design it.

**An AI agent's log is not an audit trail, because an auditor does not ask whether a record exists — they ask whether it can be relied on.** A log the agent writes about itself is the actor's own account of what the actor did. It is useful, often indispensable, and on its own it is testimony rather than evidence. The evidence is what the system of record wrote down when the agent touched it, and whether anyone can show that the list of things the agent did is complete.

The standard engineering answer to "how do we audit our agents" is to log everything: every prompt, every tool call, every output, into a store with a long retention setting, perhaps made immutable. That is a good answer to an operations question. It is an incomplete answer to an audit question, because it makes the log thorough without making it independent, provably complete, or retained for the right period.

What follows is how the evidence question looks from the other side of the desk: the SAP FI and treasury controls that sit under postings and payments.

## What an auditor actually does with a log

Start with the standards, because they are specific.

PCAOB AS 1105, paragraph .10, says that when the auditor uses information produced by the company as audit evidence, they must test the accuracy and completeness of that information, or test the controls over its accuracy and completeness — including, where applicable, IT general controls and automated application controls. ISA 500, paragraph 9, carries the same requirement for information produced by the entity. On reliability, AS 1105 .08 is blunt: evidence from a knowledgeable source independent of the company is more reliable than evidence from internal sources only, and internally produced information is more reliable when the controls over it are effective.

Now apply that to an agent. Suppose an auditor wants to test the journal entries an agent posted last quarter. They will select a sample, and the sample comes from a list. **That list is information produced by the company**, and before any sampled item can say anything, the auditor has to be satisfied the list is complete and accurate. A clean sample drawn from an incomplete population tells you nothing about the items that were never on it.

So the first question an agent's log faces is not "what does it contain" but "how do you know it contains everything" — and that is a question most agent logs were not designed to answer.

## Three ways an agent log falls short

| Property | A typical agent log | What evidence needs |
| --- | --- | --- |
| Independence | Written by the agent or its framework — the component whose actions it records | A record produced by something other than the actor, ideally the system of record |
| Completeness | No sequence, no reconciliation; a dropped or sampled entry leaves no gap | A population you can prove is whole, against a count kept by someone else |
| Retention | Whatever the platform was configured with, for operational or cost reasons | The period the governing obligation sets, whichever is longest |

**Independence.** This is not about the agent lying. It is about correlated failure. The same fault that makes an agent act wrongly — a bad retry, a tool call that timed out after it had in fact succeeded, a framework bug — can also make its record of that action wrong or absent. A person's diary of their own work is not how a finance function evidences four-eyes, and an agent's diary is not different in kind. The same holds one hop further out: the log of [an MCP server in front of SAP](https://gravam.com/blog/mcp-server-sap-authorization) is the integration's account of what it asked for, not a record of what SAP did.

**Completeness.** Observability pipelines commonly sample, buffer and drop under load, because they were built to show trends, not to account for every event. That is the right design for [production observability](https://gravam.com/blog/production-ai-observability) and the wrong one for evidence. A log with no sequence number cannot show that entry 4,812 is missing, because there is no entry 4,812 to miss.

**Retention.** A log's retention is a setting somebody chose — often the default, often tuned for cost. Accounting records answer to statute: in Germany, § 257 HGB keeps books and financial statements for ten years, and accounting vouchers for eight for most companies since January 2025 — banks, insurers and investment firms were returned to ten. Even the AI-specific rule defers to the longer regime. Article 26(6) of the EU AI Act requires deployers of high-risk systems to keep the logs under their control for at least six months, and says financial institutions keep them as part of the documentation their financial-services law already requires.

Two qualifications on that last point. Most finance agents are not high-risk systems under the Act, and since the AI Omnibus entered into force on 27 July 2026 the high-risk requirements for stand-alone systems apply from 2 December 2027. Article 26(6) is not your obligation today. It is a clear statement of the principle: the platform's retention is not the answer; the obligation is.

> A log the agent writes about itself is testimony. The evidence is what the system of record wrote down when the agent touched it — and a count of those touches that the agent did not keep.

## The evidence is already on the other side

In an SAP landscape, most of what an auditor wants is written by the system of record whether or not the agent logs anything.

**Change documents.** When a business object with a change document object is changed, SAP writes a header to CDHDR — object class, change document number, user, date, time, transaction code — and the field-level old and new values to CDPOS. That is a record produced by the system, under the identity that made the change, not a description volunteered by the caller. The catch worth checking: a field is only logged if its data element has the change document flag set. Before you rely on change documents for an agent, confirm that the fields it writes are actually among the logged ones.

**The posted document.** An FI document carries a number from a number range, a created-by user and an entry date. Number ranges give you a sequence the agent does not control, and SAP ships a report for gaps in document number assignment (RFBNUM00), because a missing number is something you will be asked to explain. [What actually lands when an agent posts in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) covers why the agent must post through the application rather than into the tables — a direct table write skips the change document and the number range both.

**Payment runs.** F110 keeps the proposal and payment data (REGUH, REGUP) and the job logs of each run. It is also a warning about retention: SAP's own reorganisation function for F110 deletes that payment run data and the associated job logs up to a chosen date, and deleted entries cannot be restored. "The system of record keeps it" is also a retention decision, and it has to be checked against the obligation too.

None of this helps if the agent posts under a shared technical user, because every one of those records will then name the interface. [Agent identity](https://gravam.com/blog/agent-identity-and-permissions) comes first; the rest of the evidence depends on it.

## Reconcile the two sides

Here is the design move that turns the agent's log from a liability into something useful: **treat it as one side of a reconciliation, not as the evidence.**

The agent's record says what it believes it did. The system of record says what happened. Match them on a key both sides carry — the document number the ERP assigned, stored against the agent's run ID; the run ID, stored on the document in a reference or text field. Then reconcile, on a schedule, in both directions:

- **An agent action with no document** is a failed post the agent believes succeeded, a duplicate suppressed by the ERP, or a write that went somewhere it should not have.
- **A document under the agent's identity with no agent action** is the more serious break: something used those credentials, or a path the agent does not log.

That is exactly the shape of a bank reconciliation, and it earns its keep the same way — the breaks are the findings. It is also what [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation) has always done for batch interfaces. An agent is an interface that makes decisions.

## What to design instead

**Agent identity on every action.** Its own user, scoped to the task, with the requesting human recorded alongside it, so created-by and changed-by mean something.

**An evidence store the agent cannot write to.** Append-only, written by the control layer rather than the agent, with no delete permission for any identity the agent holds. Tamper evidence comes from where the record lives and who can touch it, not from a promise in the logging library.

**The chain, linked to the document.** For each consequential action, one record keyed to the posted document:

| Field | Why an auditor wants it |
| --- | --- |
| Document / change number | Ties the record to the system of record's own evidence |
| Agent identity and run ID | Attribution, and a sequence in which a gap is visible |
| Requesting human | On whose behalf the action ran |
| Input reference | What the agent was looking at, retrievable later |
| Output / proposal | What it proposed, before any human edit |
| Prompt and model version | Which configuration produced it — see [prompt and model versioning](https://gravam.com/blog/prompt-and-model-versioning) |
| Rule version and result | Which deterministic check passed it |
| Approver and timestamp | The human release, taken from the system of record where possible |

**A completeness control that runs.** Sequential run IDs, a daily two-way reconciliation to documents under the agent's identity, and a named owner for the breaks.

**Retention set from the obligation.** Map each record type to its governing requirement, take the longest, and test every deletion job against it — the agent platform's retention and the ERP's reorganisation runs alike.

**Re-performance where the decision matters.** Put the consequential decision in a deterministic check whose version is recorded, so it can be re-performed months later. [Four-eyes for AI agents](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) has the argument; the version field is how it survives an audit.

## Making the system of record the evidence

Keep the agent's log, and stop calling it the audit trail. Make the system of record the evidence: the agent posts through the application, under its own identity, so change documents, number ranges and release records are written by something other than the agent. Give every action a sequential run ID and the document number it produced, and reconcile the two populations daily in both directions. Write the linking record to a store the agent cannot touch. And set retention from the obligation rather than the platform — then check that nothing, including the ERP's own housekeeping, deletes the evidence first.

None of this is AI-specific. It is what [a treasury audit trail](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) always had to be, applied to an actor that writes very fluent descriptions of its own work.

_See also [the enterprise AI control layer](https://gravam.com/blog/the-enterprise-ai-control-layer) and [the EU AI Act's high-risk requirements](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems)._

## Primary sources

PCAOB AS 1105 as currently effective; extant ISA 500 (the IAASB's revision project was still in progress when checked); EU AI Act Articles 12 and 26 as amended by the AI Omnibus (Regulation (EU) 2026/1744, in force 27 July 2026); SAP change documents and F110 reorganisation as described in SAP Help. Checked 25 September 2026 against cross-checked excerpts of these sources; verify against the primary text for your jurisdiction and version.

- PCAOB AS 1105: Audit Evidence (paragraphs .08 and .10 — reliability; information produced by the company) — accessed 2026-09-25 — https://pcaobus.org/oversight/standards/auditing-standards/details/AS1105
- IAASB — ISA 500 series, Audit Evidence (extant ISA 500 paragraph 9 on information produced by the entity; revision project status) — accessed 2026-09-25 — https://www.iaasb.org/consultations-projects/isa-500-series
- EU AI Act, Article 12: Record-keeping — accessed 2026-09-25 — https://artificialintelligenceact.eu/article/12/
- EU AI Act, Article 26: Obligations of deployers of high-risk AI systems (paragraph 6 — log retention) — accessed 2026-09-25 — https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
- European Commission — AI Omnibus enters into force — accessed 2026-09-25 — https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
- SAP Help — Change Documents: Concept (CDHDR, CDPOS) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_NETWEAVER_731_BW_ABAP/c14d25a8f471453590980dbb47a2aa0e/48dfd498ab14280de10000000a42189c.html
- SAP Help — Set Change Document Flag — accessed 2026-09-25 — https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/48/d1c163f6c96745e10000000a421937/content.htm
- SAP Help — Reorganization in F110 — accessed 2026-09-25 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361878327.html
- § 257 HGB — Aufbewahrung von Unterlagen, Aufbewahrungsfristen — accessed 2026-09-25 — https://www.gesetze-im-internet.de/hgb/__257.html
- EY — Längere Aufbewahrungsfristen bei Banken, Versicherungen und Wertpapierinstituten — accessed 2026-09-25 — https://www.ey.com/de_de/technical/steuernachrichten/laengere-aufbewahrungsfristen-bei-banken-versicherungen-und-wertpapierinstituten

## Questions this article answers

**Q: Is an AI agent's log an audit trail?**

Not on its own. An audit trail is evidence that a control operated, and an auditor judges evidence by its source, its completeness and whether it survives for the required period. A log the agent or its framework writes about its own actions fails the first test by construction — it is the actor's account of itself — and usually cannot prove the second or meet the third. It becomes useful when it is one side of a reconciliation against records the system of record wrote independently, such as SAP change documents and the posted documents themselves.

**Q: What do auditors need from an AI agent's activity records?**

The same thing they need from any information produced by the company: evidence that it is accurate and complete, or evidence that the controls over it are effective. PCAOB AS 1105 and ISA 500 both require the auditor to address the accuracy and completeness of company-produced information before relying on it. For an agent that means a provably complete population of its actions, each tied to a posted document, an identity, the approval that authorised it, and the prompt and model version behind it.

**Q: How long must AI agent logs be kept?**

As long as the longest obligation that applies to the record, which is almost never the default retention of the agent platform. Accounting records carry statutory periods measured in years — in Germany, § 257 HGB sets ten years for books and financial statements and, for most companies, eight for accounting vouchers. For high-risk AI systems, Article 26(6) of the EU AI Act requires deployers to keep the logs under their control for at least six months, and financial institutions keep them within their existing financial-services documentation. Map each record to its requirement and let the longest win.

**Q: How do you prove an AI agent's log is complete?**

By reconciling it to a population the agent did not write. Every agent action should carry the document number the system of record assigned, and every document created or changed under the agent's identity should carry the agent's run ID. Reconcile the two sets on a schedule: an action with no document, or a document with no action, is a break to investigate. Add a sequence check on run IDs so a missing entry is detectable, and store the evidence somewhere the agent has no permission to write or delete.

---

# The OWASP LLM Top 10 (2026), Read From a Finance Seat

Source: https://gravam.com/blog/owasp-llm-top-10-2026-for-enterprise-finance
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: All ten 2026 entries with what changed from 2025 — and which of them a finance or treasury deployment actually meets first.

**The 2026 OWASP GenAI/LLM Top 10, published 4 August 2026, runs: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling.** The codes are versioned and they moved this year, so a document citing a bare `LLM08` without a release year is citing an unknown item.

This page is the list, verified against the project's canonical repository rather than a secondary write-up, with what changed since 2025 and — the part that is mine, not OWASP's — which entries a finance or treasury deployment actually meets first.

## The list, and where each one moved

| Code | Entry | 2025 → 2026 |
| --- | --- | --- |
| **LLM01:2026** | Prompt Injection | Held first; now also covers cross-modal attacks |
| **LLM02:2026** | Sensitive Information Disclosure | Held second |
| **LLM03:2026** | Excessive Agency | **Climbed to third** — the largest consequential move |
| **LLM04:2026** | Supply Chain | Now covers a promoted model artifact not being what it claims |
| **LLM05:2026** | Data and Model Poisoning | Now absorbs fine-tuning subversion |
| **LLM06:2026** | Unbounded Consumption | **Rose four places** |
| **LLM07:2026** | Misinformation | Middle of the list — see the vote-versus-evidence note below |
| **LLM08:2026** | Hidden Context Exposure | **Renamed and broadened** from 2025's System Prompt Leakage |
| **LLM09:2026** | Vector and Embedding Weaknesses |  |
| **LLM10:2026** | Improper Output Handling | **Fell furthest**, fifth to tenth; now spans insecure generated code |

The renumbering is the practical trap. If your control matrix, your vendor questionnaire or your architecture review cites `LLM08`, it now means something different from what it meant last year: LLM08:2025 was Vector and Embedding Weaknesses, which is LLM09 now. And the entry that took the number is not a like-for-like carry-over either — System Prompt Leakage (LLM07:2025) was a specific failure, and Hidden Context Exposure is a broader class. Write the year with the code.

## What is actually new about this release

The 2026 list is the first the project has checked against recorded incidents rather than practitioner judgement alone. The method is worth knowing, because it is the reason two entries sit where they do:

- A corpus of **7,714 real incidents** was assembled from public vulnerability databases and an AI-harm database, of which **6,639** carried enough detail to classify.
- The community vote carries **three-quarters** of the weight; the incident data carries **one quarter**. That is enough to move an entry a tier where belief and evidence diverge sharply, and deliberately not enough to let one year of imperfect data rewrite a consensus list.

Two divergences came out of that, and both are more useful than the agreements.

**Prompt Injection ranks first on the vote and falls out of the top ten entirely on raw incident count.** The project reads that as a defence effect rather than an absence of risk: teams already spend real money holding it off, so fewer clean exploits reach a public database. That reading matches what I would expect from any mature control — the incidents you do not see are the ones somebody is paying to prevent — and it is exactly why [injection is a blast-radius problem rather than a prevention problem](https://gravam.com/blog/enterprise-ai-agent-security-boundaries).

**Misinformation runs the other way**: voters put it near the bottom, the incident record put it near the top, and it was seated in the middle. This is the widest gap in the direction that hurts — the field under-rates it relative to what has already gone wrong. For a finance audience I would treat that as the headline finding of the whole release, because a confident wrong number that drives a posting or a payment is not a content problem. It is a control problem.

## The boundary the project draws, and why it matters here

The list owns the risk while a model is **a component inside an application**. The moment it becomes an **actor** — with tools it can call, memory carried between sessions, and consequences set in motion downstream — the project routes you to the separate OWASP Agentic Top 10.

That boundary is worth taking seriously, because most enterprise finance deployments are already on the far side of it or will be within a year. An assistant that reads open items is a component. Something that prepares a payment run is an actor. If your security review has only worked the LLM list, it has covered the model and not the thing that acts — which is where [the placement decision](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems) and [the authorization union](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) live.

## Which of these a finance deployment meets first

This half is my reading, not OWASP's. Ranked by what I would expect to actually bite in an SAP or treasury landscape, rather than by the list's own order.

**LLM03 Excessive Agency — first, by a distance.** In a finance landscape "excessive agency" is not an abstraction; it is a credential. It is the composite that lets one non-human identity create a vendor and release a payment to it, and it does not appear in the access review because technical users are excluded from the human one. The list's own movement agrees: this climbed to third because agentic deployments are where the damage lands. The mitigation is the oldest one there is — narrow the operation list, and [do not connect the agent to the ERP directly](https://gravam.com/blog/connecting-ai-agents-to-your-erp).

**LLM02 Sensitive Information Disclosure — second, and it arrives through retrieval scope.** Enterprise content permissions were built assuming a person has to know where to look and has limited hours. Point retrieval at a share and neither limit holds. The exposure is usually not new; it is an old over-broad permission that nobody could exploit at scale until now.

**LLM07 Misinformation — third, and under-rated exactly as the incident data says.** A plausible wrong figure in a cash position or a reconciliation is not caught by a security control. It is caught by reconciliation, by an exception queue somebody actually works, and by [output contracts that fail loudly rather than plausibly](https://gravam.com/blog/ai-output-contracts-and-failure-handling).

**LLM04 Supply Chain — fourth, and it is the one your existing process half-covers.** Vendor risk management already exists in every regulated finance function. What it does not yet cover is the model, the training data and the agent platform as supply-chain components, which is the gap [GOVERN 6 of the NIST framework](https://gravam.com/blog/nist-ai-rmf-functions-and-categories) names in almost the same words.

**LLM06 Unbounded Consumption — fifth, and it is the one that surprises people.** The characteristic agent incident is not one clever action; it is the same wrong action four thousand times before anyone looked. In a finance context that is a duplicated instruction, not just a cloud bill, and the mitigation is a rate limit plus idempotency on every write.

**LLM10 Improper Output Handling — last on the list, and I would not treat it as last in practice.** It fell from fifth to tenth, but it now spans insecure code generated at scale, and the finance-specific version is narrower and sharper: a model output that reaches a system of record without passing a deterministic check. That is the entire argument for [a control layer that is not a model](https://gravam.com/blog/the-enterprise-ai-control-layer).

## Which OWASP LLM risks to work first

Cite the codes with their release year, and re-check any control matrix written against the 2025 list — LLM08 in particular now means something else. Work LLM03 first regardless of its rank, because in a finance landscape excessive agency is a credential and the credential is the blast radius. Take the misinformation finding seriously: the incident record says the field under-rates it, and the finance version of "misinformation" is a wrong number that somebody acts on. And if what you are deploying can call a tool, pair this list with the Agentic one, because the project itself says neither covers that ground alone.

The framing the project leads open with is the same one this site has argued from the start, which is worth saying plainly rather than pretending at independence: build the system around the model so that when the model is fooled — and it will be — nothing important breaks.

_See also [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) and [the NIST AI RMF functions and categories](https://gravam.com/blog/nist-ai-rmf-functions-and-categories)._

## Primary sources

Codes, titles, rank movements and the incident-corpus figures are taken from the 2026 final release in the project's canonical repository. Entry numbering is NOT stable across releases — LLM08 was Vector and Embedding Weaknesses in 2025 and is Hidden Context Exposure in 2026, while System Prompt Leakage, which Hidden Context Exposure renames, was LLM07:2025 — so cite the release year whenever you cite a code. The mapping onto finance controls in the second half is my interpretation, not part of the OWASP material.

- OWASP GenAI Security Project — GenAI/LLM Top 10, 2026 final: the ten entry files (LLM01–LLM10) and the project leads' preface, including the incident-corpus method and the 2025→2026 rank movements — 2026 final, published 4 August 2026 — accessed 2026-08-19 — https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final
- OWASP — Top 10 for Large Language Model Applications project page (legacy entry point, pointing to the current 2026 release and canonical repository) — accessed 2026-08-19 — https://owasp.org/www-project-top-10-for-large-language-model-applications/

## Questions this article answers

**Q: What is the OWASP LLM Top 10 for 2026?**

In order: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling. It was published on 4 August 2026 by the OWASP GenAI Security Project, and it is the first release to weigh the community vote against a corpus of real recorded incidents rather than practitioner judgement alone.

**Q: What changed between the 2025 and 2026 OWASP LLM Top 10?**

The order moved more than in previous years. Excessive Agency climbed to third, described by the project leads as the most consequential move, because agentic deployments are where the damage is landing. Unbounded Consumption rose four places. Improper Output Handling fell furthest, from fifth to tenth. Prompt Injection held first. And what was System Prompt Leakage became Hidden Context Exposure — a rename and a broadening, not a like-for-like carry-over. Several entries also absorbed newer risks rather than new categories being created: cross-modal attacks folded into Prompt Injection, model-artifact trust into Supply Chain, fine-tuning subversion into Data and Model Poisoning, and insecure generated code into Improper Output Handling.

**Q: Are the OWASP LLM entry numbers stable between releases?**

No. The OWASP LLM entry numbers change between releases, and treating them as stable is a real source of confusion. LLM08 was Vector and Embedding Weaknesses in the 2025 list and is Hidden Context Exposure in 2026 — the entry it renames, System Prompt Leakage, was LLM07:2025; several other entries changed rank in the same release. A control document or a vendor questionnaire that cites a bare code without its release year is referring to an unknown item. Always write the year with the code — LLM03:2026, not LLM03 — the way the project's own entry headings do.

**Q: Does the OWASP LLM Top 10 cover AI agents?**

Only up to the point where the model stops being a component and starts being an actor. The project draws that boundary explicitly: this list owns the risk while a model sits inside your application, and once it has tools it can call, memory it carries between sessions and downstream consequences it sets in motion, the risk moves to the separate OWASP Agentic Top 10. Many recorded incidents sit right on that line, so an enterprise agent deployment needs both lists rather than either one.

**Q: Why does Prompt Injection rank first if the incident data does not support it?**

Because the gap is a defence effect rather than an absence of risk. Ranked by raw public incident count, prompt injection falls out of the top ten entirely — but the project reads that as evidence that teams already spend real money holding it off, so fewer clean exploits reach a public database. The attack surface exists wherever a model reads untrusted input, which in an enterprise is everywhere, and it cannot be closed. The list keeps it at first place on the strength of the community vote, which carries three-quarters of the weight against one quarter for the incident data.

---

# NIST AI RMF: The Functions and Categories, Explained

Source: https://gravam.com/blog/nist-ai-rmf-functions-and-categories
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: All four functions and 19 categories of the NIST AI Risk Management Framework, with subcategory counts — and which finance controls already cover each one.

**The NIST AI Risk Management Framework has four functions — GOVERN, MAP, MEASURE and MANAGE — holding 19 categories and 72 subcategories between them, and GOVERN is cross-cutting rather than first in a sequence.** It is voluntary, it is not a regulation, and most of what it asks is whether controls a finance function already runs have been extended to cover a component whose output varies.

This page is the structure, verified line by line against NIST AI 100-1, with the counts stated so you can tell at a glance where the weight sits. The commentary underneath each function is mine: controls work in SAP FI and treasury, pointed at the question the framework actually asks.

## The shape of it

| Function | Categories | Subcategories | What it asks |
| --- | --- | --- | --- |
| **GOVERN** | 6 | 19 | Is there a culture, an owner and a policy — across all three below |
| **MAP** | 5 | 18 | Do you understand the context, the system and the risks |
| **MEASURE** | 4 | 22 | Can you evaluate and track it, with methods and metrics |
| **MANAGE** | 4 | 13 | Do you act on what you found, including recovery |
| **Total** | **19** | **72** |  |

Two things are worth reading off that table before anything else.

**GOVERN is not step one.** NIST is explicit that governance is a cross-cutting function designed to inform and be infused throughout the other three. Treating it as a gate you pass before the work starts produces the failure mode I described in [where to start with enterprise AI](https://gravam.com/blog/where-to-start-with-enterprise-ai): a control regime written against no concrete case, calibrated for the worst thing anyone imagined.

**MEASURE 2 is the heaviest single category in the framework**, with 13 of the 72 subcategories. It is the one about evaluating a system against the trustworthiness characteristics. If your programme's effort is not lopsided toward measurement, it is not following the shape of this framework — whatever the slide says.

## The seven characteristics of trustworthy AI

The framework names these, and the ordering carries meaning. NIST treats **valid and reliable** as the base condition — the other characteristics do not add up to trustworthiness without it — and **accountable and transparent** as relating to all the others rather than sitting beside them.

1. Valid and reliable
2. Safe
3. Secure and resilient
4. Accountable and transparent
5. Explainable and interpretable
6. Privacy-enhanced
7. Fair, with harmful bias managed

The framework is explicit that these are balanced for a given system and context, not maximised independently — which is the honest position, because several of them trade against each other in any real design.

## GOVERN — 6 categories, 19 subcategories

| Category | In one line | The finance-control equivalent |
| --- | --- | --- |
| **GOVERN 1** | Policies, processes and practices for mapping, measuring and managing AI risk are in place and implemented | The control framework document nobody reads until an audit |
| **GOVERN 2** | Accountability structures: teams empowered, responsible and trained | The named process owner and the delegation of authority |
| **GOVERN 3** | Workforce diversity, equity, inclusion and accessibility in the risk work | No direct equivalent — this one is genuinely additional |
| **GOVERN 4** | A culture that considers and communicates AI risk | Speak-up culture; the thing every incident review says was missing |
| **GOVERN 5** | Robust engagement with relevant AI actors | Stakeholder management, including the people the output lands on |
| **GOVERN 6** | Third-party software, data and supply-chain risk | Vendor risk management, extended to models and training data |

GOVERN 2 is the one I would put first in practice. Accountability is where AI governance most often fails and it fails the same way every time: the accountable party is "the AI team", which is the same as nobody. The rule that holds is the one every control already follows — a named person who can change the system, see the exception queue, and stop it. That is [the ownership question](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems), and no framework can answer it for you.

GOVERN 6 deserves more weight than it usually gets in enterprise programmes, because for most organisations the model is third-party, the training data is third-party, and the agent platform is third-party. Vendor risk management is not a formality here; it is most of the attack surface, and the questions worth asking are [the ones a vendor's accuracy claim cannot survive](https://gravam.com/blog/evaluating-enterprise-ai-vendor-claims). The security list names the same gap in almost the same words — [LLM04 Supply Chain in the 2026 OWASP LLM Top 10](https://gravam.com/blog/owasp-llm-top-10-2026-for-enterprise-finance).

## MAP — 5 categories, 18 subcategories

| Category | In one line | The finance-control equivalent |
| --- | --- | --- |
| **MAP 1** | Context is established and understood | The scoping workshop, done honestly |
| **MAP 2** | Categorization of the AI system is performed | System classification on the application inventory |
| **MAP 3** | Capabilities, usage, goals, benefits and costs against benchmarks | The business case, with a baseline |
| **MAP 4** | Risks and benefits mapped across all components, including third-party | The interface inventory and the dependency map |
| **MAP 5** | Impacts to individuals, groups, organizations and society characterized | Impact assessment — the half of a risk register nobody fills in |

MAP 3 is where I would put the most pressure, because "expected benefits and costs compared with appropriate benchmarks" is precisely the step that gets skipped. A benefit stated without a baseline cannot be checked afterwards, which is the whole argument for [measuring the work rather than the tool](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow).

MAP 4 is the one an enterprise architect will recognise immediately. It is the interface estate, and the reason it matters here is that an AI component's risk is mostly inherited from what it can reach — [an architecture problem, not a model problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem).

## MEASURE — 4 categories, 22 subcategories

| Category | In one line | The finance-control equivalent |
| --- | --- | --- |
| **MEASURE 1** | Appropriate methods and metrics are identified and applied | Test strategy: deciding what "correct" means before testing |
| **MEASURE 2** | Systems are evaluated for trustworthy characteristics (**13 subcategories**) | UAT, regression testing, and the evidence pack |
| **MEASURE 3** | Mechanisms for tracking identified risks over time | KRIs on the risk register; monitoring and alerting |
| **MEASURE 4** | Feedback about the efficacy of measurement is gathered and assessed | The post-implementation review that asks whether the tests were the right tests |

MEASURE 1 contains the step teams reliably skip: deciding the method and the metric _before_ measuring. In systems delivery that is a test strategy, and the AI version has one extra obligation — the output varies, so a single pass tells you nothing without a defined sample and a defined threshold. That is [regression testing for a probabilistic component](https://gravam.com/blog/ai-evaluation-and-regression-testing).

MEASURE 3 is the one that ages worst if you leave it. Tracking risk over time means noticing that behaviour drifted, and if the detection mechanism is "a customer told us", there is no mechanism — which is what [production observability](https://gravam.com/blog/production-ai-observability) exists to fix.

MEASURE 4 — assessing whether your measurement was any good — is unusual, and it is the most self-aware thing in the framework. Very few control environments ask it about anything.

## MANAGE — 4 categories, 13 subcategories

| Category | In one line | The finance-control equivalent |
| --- | --- | --- |
| **MANAGE 1** | Risks from MAP and MEASURE are prioritized, responded to and managed | Risk treatment decisions on a RAID log |
| **MANAGE 2** | Strategies to maximize benefits and minimize negative impacts | The design decisions themselves — where the human sits, what is automated |
| **MANAGE 3** | Risks and benefits from third-party entities are managed | Ongoing vendor management, not just onboarding |
| **MANAGE 4** | Risk treatments, response, recovery and communication documented and monitored | Incident management and the cutover fallback |

MANAGE 4 is the gate I would refuse to waive. Response and recovery for an AI step means a tested way to undo a wrong output and a defined route for who is called when it misbehaves out of hours — which is exactly [what a pilot has to prove before production](https://gravam.com/blog/ai-pilot-exit-criteria), and it is the gate most often assumed rather than exercised.

## What the framework does not do

Worth stating plainly, because the gap is where the disappointment comes from.

**It is voluntary, and it is not law.** Nothing in it carries a penalty. If your obligation is regulatory, the binding instrument in Europe is the AI Act, with dated requirements — [which apply on a schedule the framework says nothing about](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems).

**It will not tell you whether to build the thing.** The framework assumes a system exists or is planned. The prior question — whether this workflow should be redesigned with AI at all — is not in scope, and [an assessment that can answer "don't"](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai) is a separate exercise.

**It does not size your exception queue, set your thresholds or design your control path.** Those are engineering and operating decisions. The framework tells you they must exist and be documented; it deliberately does not tell you what good looks like for your volume, which is correct for a non-sector-specific framework and unhelpful on the Monday you have to decide.

## How I would use the NIST AI RMF in finance

Use it as a checklist and a vocabulary, not as a programme plan. Run your existing control inventory against the 19 categories and mark the ones an existing control already covers — for most finance functions that is the majority, and the exercise takes an afternoon rather than a workstream. Put the real effort into the three that are genuinely different for a probabilistic component: GOVERN 6 because the supply chain is the model, MEASURE 2 because it is a third of the framework by weight, and MANAGE 4 because a recovery path nobody has exercised does not exist.

And do not let the framework substitute for the decision underneath it. Naming a risk in a register is not a control. [Something deterministic in the path](https://gravam.com/blog/the-enterprise-ai-control-layer) is.

_See also [the EU AI Act's high-risk requirements](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems) and [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries)._

## Primary sources

Structure and wording verified against NIST AI 100-1 (AI RMF 1.0, January 2023), the current version of the core framework. NIST publishes companion material — the AI RMF Playbook and the Generative AI Profile (NIST AI 600-1) — on a different cadence; this page describes the framework itself, not those profiles. The AI RMF is voluntary and is not a regulation, and mapping it onto your control environment is an interpretation, not a compliance statement.

- NIST AI 100-1 — Artificial Intelligence Risk Management Framework (AI RMF 1.0): the four functions, 19 categories, 72 subcategories, and the seven characteristics of trustworthy AI — AI RMF 1.0, January 2023 — accessed 2026-08-19 — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

## Questions this article answers

**Q: What are the four functions of the NIST AI RMF?**

GOVERN, MAP, MEASURE and MANAGE. GOVERN is the cross-cutting one: NIST designs it to inform and be infused throughout the other three rather than to sit before them in a sequence. MAP establishes context and identifies risks, MEASURE analyses and tracks them with methods and metrics, and MANAGE prioritises and acts on them, including response and recovery. The framework is voluntary and non-sector-specific, so the functions describe what has to be true rather than prescribing how an organisation achieves it.

**Q: How many categories and subcategories does the NIST AI RMF have?**

Nineteen categories and 72 subcategories across the four functions. GOVERN has 6 categories and 19 subcategories, MAP has 5 and 18, MEASURE has 4 and 22, and MANAGE has 4 and 13. MEASURE 2 alone carries 13 subcategories, which is the largest single group in the framework and a fair signal of where NIST expects the work to be — evaluating a system against the trustworthiness characteristics is more detailed than governing or managing it.

**Q: What are the seven characteristics of trustworthy AI in the NIST framework?**

Valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST treats valid and reliable as the base condition — without it the others do not get you a trustworthy system — and accountable and transparent as cutting across all the rest. The framework is explicit that these have to be balanced against each other for a given system and context rather than maximised independently.

**Q: Is the NIST AI RMF mandatory?**

No. The NIST AI RMF is a voluntary framework published by a US standards body, not a regulation, and nothing in it carries a penalty. That is a meaningful difference from the EU AI Act, which is binding law with dated obligations. What the AI RMF gives you is a shared vocabulary and a checklist structure that an internal audit function, a risk committee or a customer's due-diligence questionnaire will recognise — which is often exactly what is needed when the alternative is inventing your own categories.

**Q: How does the NIST AI RMF map to existing finance controls?**

More closely than the vocabulary suggests. GOVERN 2 (accountability structures) is the named process owner and delegation of authority you already maintain. GOVERN 6 (third-party software and data) is vendor risk management. MAP 4 (risks across all components including third-party) is the interface inventory. MEASURE 3 (tracking risks over time) is a KRI on a risk register. MANAGE 4 (response, recovery and communication) is the incident process and the fallback in a cutover plan. Most of the framework is asking whether controls you already run have been extended to cover a probabilistic component.

---

# Four-Eyes and Segregation of Duties for AI Agents

Source: https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: A human clicking approve on an agent's proposal is not a second pair of eyes. What independence requires when one of the two parties is a model.

**Four-eyes survives an AI agent only when the second examination is independent of the first — and a person approving what the agent put in front of them is not independent, because their view of the facts is the agent's view of the facts.** The control was never two clicks. It was two people looking at the same reality by different routes, and an agent that prepares the item and the evidence collapses those routes into one.

The textbook description is more forgiving: a maker and a checker, one prepares, another approves, and no single person completes a sensitive action alone. That description survives an agent perfectly well on paper, which is exactly the problem. Every box is still ticked. The independence it was standing in for has quietly gone.

SAP FI and treasury already build these controls in — release strategies, approval limits, dual release on payments (the [SAP payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow)), the segregation rules on the master data behind them. What follows is that machinery pointed at a non-human maker, including the parts that hold and the parts that do not.

## What four-eyes was actually buying

It is worth being precise, because the vaguer version is what fails silently.

The control exists to make a single error or a single dishonest act insufficient. Two conditions do that work: the two parties must examine the same transaction **from evidence they reached independently**, and the second must carry a consequence for approving it. Neither condition mentions how many clicks there are.

Human four-eyes already degrades when those conditions lapse — the approver who sees only what the preparer's cover note says is rubber-stamping, and every controller knows it. What changes with an agent is that the degradation stops being a habit and becomes structural. The agent assembles the item, selects the supporting evidence, and renders the screen the approver reads. There is no second route to the facts unless someone built one.

> Four-eyes was never two clicks. It was two routes to the same facts — and an agent that prepares the evidence has quietly merged them into one.

## Making the second examination independent again

Three things restore the property, in ascending order of effort.

**Show the source, not the summary.** The approver's screen should contain the underlying record — the invoice image, the statement line, the contract clause, the prior document — reachable in one action, not the agent's paraphrase of it. If reaching the source takes three systems and a colleague, nobody will, and you have designed rubber-stamping. SAP's own matching AI puts the same question to anyone running [SAP Cash Application](https://gravam.com/blog/sap-cash-application-ai): items it clears above the threshold reach no approver at all, so that population has to be reviewed by report.

**Give the approver a fact the agent did not supply.** The strongest form of independence is a second source: the counterparty's own confirmation, the bank's statement, a system the agent cannot write to. In treasury this is routine — a payment is checked against a confirmation that arrived by a different channel entirely, and that is the design to copy.

**Make the approver's own question explicit.** Not "do you approve", which invites yes. "Does the bank detail on this payment match the one on file, and when was it last changed, and by whom?" A question with a factual answer is a control; a confirmation dialog is a formality. This is the same reason [the release path, not the model, is where payment authority lives](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment).

## Can the agent be the second pair of eyes?

Separately worth answering, because it is where most of the enthusiasm is.

As a **detective check**, an agent as reviewer is genuinely valuable and I would use one. It is tireless, consistent, and good at the things people skim on the fortieth item of an afternoon: the duplicate, the changed bank detail, the amount that is plausible but out of pattern. Adding a machine reviewer catches a real class of error.

As the **second party in a four-eyes control**, no — and the reason is not model quality. The control needs a party who can be asked afterwards why they approved and who bears the consequence of the answer. That is what makes the second signature worth anything. A model cannot hold a consequence, so an approval attributed to one is an approval attributed to nobody, which is the failure mode [agent identity](https://gravam.com/blog/agent-identity-and-permissions) exists to prevent.

So the workable arrangement is three-part, not two: the agent proposes, a second agent or deterministic check screens, and a human with independent evidence releases. The machine review adds coverage. It does not replace the signature.

## Segregation of duties: the union problem

The related control fails in a different and more mechanical way.

Segregation of duties is a statement about **combinations**, not about any single action. Create a vendor, and release a payment to it. Enter an invoice, and approve it. Maintain a bank detail, and initiate a transfer against it. A ruleset does not forbid either half; it forbids one identity holding both.

An agent asked to carry a process end to end needs the union of every role that process touches. Each authorization check passes. The combination is the one the ruleset was written to prevent, assembled inside a single non-human identity — and it does not appear in the access review, because technical users are usually excluded from the human one. That is the same failure [an agent posting in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) produces on the document, arriving all at once rather than accumulating over five years of [access creep](https://gravam.com/blog/access-management-and-user-provisioning-treasury).

The test is available to you today and costs an afternoon: **run the agent's composite authorizations through the segregation-of-duties ruleset you already own, as though it were a person.** The pairs worth checking first in a finance landscape:

| Half one | Half two | Why the pair matters |
| --- | --- | --- |
| Vendor / business partner maintenance | Payment run execution | Create a payee and pay it |
| Bank detail maintenance | Payment release | The actual fraud path — the account, not the amount |
| Invoice entry | Invoice approval | Self-approval of what you posted |
| Goods receipt | Invoice posting | Confirm the goods you are invoicing for |
| Journal entry | Journal approval | Period-end adjustment nobody reviewed |

A conflict this returns is a **design defect, not an exception to be approved**. The remedy is to split the agent — two identities with two operation lists — or to move the second half behind a human release. Both are cheaper than the mitigating-control paperwork the alternative generates every year afterwards.

The master-data half deserves emphasis because it is consistently underrated. In treasury the settlement account matters more than the deal, and [the business partner and standing-instruction data behind a payment](https://gravam.com/blog/business-partner-configuration-sap-treasury) is where the loss actually happens. An agent with write access there needs the four-eyes control that data already carries, not a new one invented in the agent layer.

## Does the agent's log count as the evidence?

Increasingly people accept that raw model logs are not automatically an audit trail. The more useful question is what a **financial** audit trail additionally requires, because that bar is higher and older than anything written about agents.

Three properties, none of which a debug log has by default:

**Retention on your schedule, not the platform's.** Statutory retention for accounting records runs to years, and it is measured against your obligation, not the log-rotation policy of whichever agent platform you were using at the time. If the record has to survive a change of vendor, it cannot live only in the vendor.

**Tamper evidence.** An auditor needs to know the record was not altered after the fact. That is the point of change documents in an ERP, and it is why an appended text file is not equivalent.

**Re-performance.** This is the one that surprises teams. An auditor does not merely read the record; they re-perform the control — take the same inputs, apply the same rule, and check they reach the same conclusion. For a deterministic check that is straightforward. For a model output it is not, which is a strong argument for putting the consequential decision in [a deterministic policy layer](https://gravam.com/blog/the-enterprise-ai-control-layer) whose behaviour can be re-performed, and letting the model do the part that is being reviewed rather than the part being relied on.

Practically, that means capturing at the grain of the action: what was proposed, on what inputs, which rule version evaluated it, what the deterministic check returned, who released it and when. [Audit trails and logging](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) has the general shape; the addition here is the rule version, because a control you cannot version is a control you cannot re-perform six months later. And the population itself has to be provably complete before any sample drawn from it means anything — [why an agent's logs are not an audit trail](https://gravam.com/blog/ai-agent-logs-are-not-an-audit-trail) covers how to reconcile it to the system of record.

## Keeping the second signature human

Keep the second signature human, and make sure the human sees the source rather than the summary — ideally a fact the agent did not supply. Use a machine reviewer as an extra layer, never as one of the two eyes. Run the agent's composite through the existing segregation-of-duties ruleset and split the agent where it conflicts. Put the consequential decision behind a deterministic check that can be re-performed. And capture the rule version alongside the decision, because that is the field an auditor will ask for and the one nobody logs.

None of that is new control design. It is the control design that already exists, applied honestly to a participant that happens to be very fast and cannot be held responsible for anything.

_See also [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) and [segregation of duties in treasury systems](https://gravam.com/blog/segregation-of-duties-in-treasury-systems)._

## Questions this article answers

**Q: Does the four-eyes principle still work with AI agents?**

Only if the second pair of eyes sees the underlying evidence rather than the agent's summary of it. Four-eyes was never about two clicks; it was about two independent examinations of the same facts. When an agent prepares an item and a person approves what the agent shows them, the person's view of the world is the agent's view of the world, so an error in the first examination is inherited rather than caught. The control is preserved by making the approver's evidence independent — the source record, the counterparty's own data, the prior document — not by adding a confirmation step.

**Q: How does an AI agent break segregation of duties?**

By holding the union rather than by exceeding any single permission. Segregation of duties is a statement about combinations — create a vendor and release a payment to it, enter an invoice and approve it, maintain a bank detail and initiate a transfer against it. A ruleset forbids one identity holding both halves, not either half. An agent asked to carry a process end to end needs every role that process touches, so each authorization check passes while the combination the ruleset exists to prevent is assembled inside one non-human identity that no access review looks at.

**Q: Can an AI agent be the second approver?**

As a detective check, usefully; as the second pair of eyes in a four-eyes control, no. A model reviewing a proposal is worth having because it is tireless and consistent about things people skim, and it will catch a class of error a rushed human misses. What it cannot supply is the thing the control is actually for: an independent party who can be asked afterwards why they approved, and who carries the consequence. Accountability has to land on someone who can answer for it, which is why the second approver stays human even when a machine is doing the checking.

**Q: What SoD conflicts should you test an AI agent against?**

The ones already written in the ruleset you own, run against the agent's composite authorizations as though it were a person. In a finance landscape the recurring pairs are vendor or business-partner master maintenance against the payment run, bank-detail maintenance against payment release, invoice entry against invoice approval, goods receipt against invoice posting, and journal entry against journal approval. That is a report you can produce this week, and a conflict it returns is a design defect rather than an exception to be approved.

---

# Should You Connect an AI Agent Directly to Your ERP?

Source: https://gravam.com/blog/connecting-ai-agents-to-your-erp
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: Should you connect AI agents to your ERP directly? No: put a narrow service layer between them. What a direct connection costs — one cost is commercial.

**No — not directly. Put a service layer between the agent and the ERP that exposes a small number of narrow, logged, rate-limited operations, and connect the agent to that.** The reason is not that agents are dangerous. It is that "connect it to the ERP" means handing one non-human identity the union of authorizations a process touches, through an interface surface designed for trusted integrations, in a system where the licensing model is written around who creates documents.

If you search this question you will find a genuine split. Platform vendors say their ERP natively supports agents, which is true and getting truer. Practitioners in forums say, often in capitals, do not connect an agent directly to the ERP. Both are right, because they are answering different questions: one is about product support, the other is about what a credential can reach at three in the morning when nobody is reading the log.

Non-human callers are not new inside SAP FI and TRM: the authorization model, the posting architecture, the release strategies and the interfaces were handling them long before anyone said "agent". Three things a direct connection costs, in ascending order of how rarely they are mentioned.

## 1. The authorization union defeats segregation of duties

An agent asked to carry a process end to end needs every role that process touches: create the vendor, enter the invoice, release the payment. Each authorization check passes. The combination is precisely what a segregation-of-duties ruleset is written to forbid.

This is not a subtle failure. It is the oldest control in finance systems being satisfied step by step and defeated across the sequence, and it does not show up in an access review because non-human users are usually excluded from the human one. The detailed version — what lands on the document, what the auditor samples — is in [what an agent actually posts in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts).

The service layer fixes this by construction. If the agent can only call `propose_payment_batch` and never `create_vendor`, there is no union to review, because the union is the operation list and you wrote it.

## 2. "Directly" usually means past the controls, not through them

The second cost is about the route in. A direct connection tends to resolve, in practice, to one of two things: a write into the tables behind a document, or a read from a convenient copy — an extract, a warehouse table, an export somebody built years ago.

Both look like shortcuts and both are control failures. A table write skips validations, substitutions, the release strategy, number ranges and the change document, so the record exists and nothing records that it happened. A convenient copy carries its own scoping, usually looser and undocumented, and it is stale in a way the answer will not mention.

The rule I would apply without exception: **an agent should be able to do nothing a person could not do through the front of the system, by that same route.** That is not a restriction on agents. It is the same rule every integration has been held to for thirty years, and the reason [the write path is an architecture decision](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem) rather than an implementation detail.

> The question is not what the agent may do. It is what the agent may do next, and what it already did — because that sequence is the thing the control was written about.

## 3. The one nobody on that search results page mentions: licensing

This is the cost I would raise first in a design review, because it is the only one that arrives as an invoice.

ERP licensing has had a long, expensive argument about **indirect access** — what you owe when something other than a licensed named user causes the system to do work. SAP's answer since April 2018 is the Digital Access model, and it is worth reading the shape of it carefully, because an agent fits that shape exactly.

From SAP's own public overview of the model:

- It **counts the creation of documents by indirect or digital access**, across **nine document types** — Sales, Invoice, Purchase, Service & Maintenance, Manufacturing, Quality Management, Time Management, Financial and Material.
- Counting is **on the initial document created**. In SAP's words, "Read, Update, or Delete Documents are not counted."
- Sales, Invoice and Purchase documents count at line-item level at a 1.0 multiplier; Financial and Material documents count at line-item level at 0.2.
- The model was designed for exactly this class of caller. SAP's stated rationale is that it "eliminates the need to count 'users' accessing ERP" and **"addresses IoT cases (devices, bots, etc.)"** — that phrasing is SAP's, from 2019, years before anyone was selling an agent.

Read those four points next to the thing you are about to build. An agent that creates purchase requisitions or financial postings through an interface is a non-human source creating counted documents, at a rate no human integration ever produced. Nobody notices during the pilot, because a pilot creates fifty documents.

Three honest caveats, because this is the part where confident writing does damage. Digital Access is **optional** for existing ERP customers — several licensing routes exist and you may already hold a different one. SAP's overview states on its own first page that it is informational, "shall not be incorporated into any contract", and subject to change, and it is now several years old. And your actual position depends on your contract, your region and how the landscape is licensed. None of that weakens the point, which is narrower and firmer: **this is a question with a real answer, it is cheaper to ask before the build than after, and it is not on the architecture checklist you are using.** Ask your account team what an agent creating documents does to your position, and get it in writing.

## What connecting it properly looks like

The service layer is not a new architectural idea. It is the integration layer you would have built for any other non-human caller, with a few properties made explicit. Today it is often built as an MCP server, and [where authorization actually lives when it is](https://gravam.com/blog/mcp-server-sap-authorization) is worth settling before the first tool is written.

**A small, fixed operation list.** Written by you, not exposed from the ERP's API surface. One verb, one scope each. `read_open_items_for_vendor`, not `query`.

**Its own identity, with the requesting human recorded.** Not a shared technical user — that is the decision that destroys attribution at the source and cannot be repaired afterwards. See [who the agent is acting as](https://gravam.com/blog/agent-identity-and-permissions).

**A deterministic policy check in the path.** Thresholds, limits and approvals evaluated by code, not by a model that can be talked out of them. The model proposes; something that cannot be persuaded disposes. That component is [the control layer](https://gravam.com/blog/the-enterprise-ai-control-layer), and it is the whole difference between an instruction and a control.

**Rate and volume limits.** The characteristic agent incident is not one clever action, it is the same wrong action four thousand times before anybody looked.

**Idempotency on every write.** Agents retry. Retries duplicate. A duplicated payment instruction is a bad afternoon.

**Logging at the grain of the call**, with inputs. This is what makes the period-end conversation survivable, and it is the same requirement [audit trails](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) have always had.

There is a bonus that is worth more than it sounds: the layer is where your control environment lives, so changing agent platform becomes a technical decision instead of a re-negotiation with audit.

## Where the value actually is anyway

Worth saying plainly, because none of the above is an argument against using agents in an ERP context.

**Reading is underrated and it is where most of the return sits.** The friction in an SAP finance process is rarely the posting — it is establishing why something is the way it is: which document cleared this item, why this valuation moved, what the open items against this counterparty look like. An agent that answers those from the system of record, with document numbers attached, removes real hours, cannot corrupt anything, and under the counting rules above is not a document-creating event at all.

**Proposing is the useful middle.** Draft the posting, propose the clearing, prepare the payment run — and stop. A human releases. That is where [the bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) lands too, and for the same reason: the release path is where the control lives.

**Posting directly is a narrow case.** High volume, low value, deterministic, with a tested reversal and a reconciliation that would catch a bad run. It is a small set, it is not where programmes should start, and it is the only one of the three that puts you inside the licensing question.

## Put a service layer between agent and ERP

Do not connect the agent to the ERP. Connect it to a service layer you own, with a written operation list, its own identity, a deterministic policy check, rate limits, idempotency and call-grain logging. Run the agent's composite authorizations through the segregation-of-duties ruleset you already have, and treat a conflict as a design defect rather than an exception to approve. Start on reading, move to proposing, and treat direct posting as a case to be argued rather than a destination.

And before any of that, ask the licensing question. It is the cheapest question in the programme and the only one that gets more expensive the longer you leave it — which is a fair summary of everything ERP has ever taught about indirect access.

_See also [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) and [how AI agents fit into existing enterprise systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems)._

## Primary sources

The licensing section describes SAP's Digital Access model as SAP published it in a public May 2019 overview, which states on its own first page that it is informational, not part of any contract, and subject to change. It is not legal or licensing advice, commercial terms differ by contract and region, and Digital Access is one of several options an existing ERP customer may hold. Treat it as the question to raise with your account team, not as an answer.

- SAP — Digital Access Adoption Program Overview (PUBLIC, May 2019): the nine document types, the counting rules, and the definition of Use — May 2019 — accessed 2026-08-19 — https://news.sap.com/wp-content/blogs.dir/1/files/DA_Offer_External-Master_V11_050619.pdf

## Questions this article answers

**Q: Should you connect an AI agent directly to your ERP?**

Not directly. The disagreement you will find online about connecting AI agents to an ERP is really two different questions being answered at once. Whether an ERP platform supports agents is a product question, and the answer is increasingly yes. Whether you should point one at your ERP's interfaces with a broad credential is an architecture question, and the answer is no — because the agent then needs the union of the authorizations the process touches, which is the combination your segregation-of-duties ruleset exists to forbid. Put a service layer between them that exposes a small number of narrow operations, and connect the agent to that.

**Q: What is the risk of giving an AI agent ERP access?**

Three, and only the first is usually discussed. The authorization union: an agent carrying a process end to end holds roles no single person would be allowed to hold, so every individual check passes while the control fails across the sequence. The write path: an agent that reaches the tables or a convenient copy rather than the normal transaction path produces records with no validation, no release strategy and no change document. And the commercial one: an agent creating documents is a non-human source creating documents, which is exactly what indirect or digital access licensing is written about.

**Q: Does an AI agent creating documents in SAP count as indirect access?**

Whether an AI agent creating documents in SAP counts as indirect access is a contract question, not a technical one, and it deserves to be asked before the build rather than after. SAP's public description of its Digital Access model counts the creation of documents by indirect or digital access across nine document types, prices reads at nothing, and its 2019 overview explicitly frames the model as addressing non-human use — devices and bots. An agent creating purchase or financial documents through an interface has the same shape. Whether it is charged depends on your contract, which options you hold and how your landscape is licensed, so the honest advice is to raise it with your account team early.

**Q: What sits between an AI agent and an ERP?**

A service layer that exposes a deliberately small set of operations — not the ERP's API surface. Each operation does one thing at one scope, runs under the agent's own identity rather than a shared technical user, passes a deterministic policy check that a language model cannot argue with, is rate-limited, is idempotent so retries do not duplicate postings, and logs at the grain of the call. That layer is where the answer to every audit question lives, and it is also the thing that lets you change agent platforms without renegotiating your control environment.

---

# AI Agents in SAP: What Actually Lands in the System

Source: https://gravam.com/blog/ai-agents-in-sap-what-actually-posts
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: Role-aware is not segregation-safe. What an agent posting in S/4HANA leaves on the document, in the release path, and in front of the auditor at period end.

**An AI agent in SAP is judged by what it leaves behind: the user ID on the document, whether the posting went through the release path, and what the change record shows at period end.** Everything else in the discussion — which assistant, which model, which platform — is replaceable. Those three artefacts are what the control environment reads, what the auditor samples, and what someone will reconstruct from in a year.

Almost every article about AI agents in S/4HANA finance describes what an agent _can do_. Very few describe what actually lands. This one is about the second, seen from inside SAP FI and TRM — the posting architecture, the release strategies, the business partner data behind a payment, and the change documents that make any of it provable afterwards.

## "Role-aware" is not segregation-safe

The reassurance you will read most often is that an agent operates within the authorizations of the user it acts for, so it cannot do anything that user could not. That is true, necessary, and not the control people take it for.

Segregation of duties is not a statement about any single action. It is a statement about _combinations_: create a vendor and release a payment to it; enter an invoice and approve it; maintain a bank detail and initiate a transfer against it. A ruleset does not forbid either half. It forbids one identity holding both.

Now consider what an agent asked to carry a process end to end actually needs. Not one role — the union of every role that process touches. Each individual authorization check passes. The combination is the one the ruleset was written to prevent. The control has not been bypassed; it has been satisfied step by step while being defeated across the sequence.

This is the same failure mode as [access creep](https://gravam.com/blog/access-management-and-user-provisioning-treasury), arriving all at once instead of over five years. And it is why the design question is not "does the agent have permission" but "what is the union of what this agent may do, and would a person holding that union pass the SoD review". Run the agent's composite through the ruleset you already own. That is a report you can produce this week.

> Every authorization check passes. The combination is the thing the ruleset forbids — and nothing checks combinations except the review nobody ran on a non-human user.

## The document is the evidence, so the identity is the design

What lands on an FI document is a small number of fields, and they carry the entire accountability chain: who created it, who changed it, who released it, and when. A treasury or controlling person reads those fields the way a developer reads a stack trace.

A shared technical user destroys all of it in one decision. It is the default in most integrations — including [an MCP server in front of SAP](https://gravam.com/blog/mcp-server-sap-authorization) — because it is administratively simple, and it means the document says the interface did it. There is nowhere to go from there.

Three arrangements, and their consequences on the document:

**Agent posts as a shared technical user.** Attribution gone. Revocation is all-or-nothing. The SoD review does not see it because technical users are usually excluded from the human access review.

**Agent posts as the requesting user.** Attribution points at a person who may not know the posting exists, and inherits every permission that person has accumulated — which is [almost always more than the task needs](https://gravam.com/blog/segregation-of-duties-in-treasury-systems).

**Agent has its own identity, scoped to the task, with the requesting human recorded.** More work. The only one where the document answers both questions an investigation asks: what acted, and on whose behalf.

The third is the same conclusion as [agent identity generally](https://gravam.com/blog/agent-identity-and-permissions), and SAP makes it concrete: there is a field, it will be filled with something, and you are choosing what.

## Post through the front door or not at all

The strongest architectural rule I would apply, and the one that resolves most design arguments quickly: **an agent should be able to do nothing a person could not do through the normal transaction path, by that same path.**

A direct write to the tables behind a document — [BKPF and BSEG for an FI posting](https://gravam.com/blog/02-bkpf-bseg-join), or the position and flow tables behind a treasury deal — produces a row that looks right and is invisible to everything that makes a posting trustworthy. It skips validations and substitutions. It skips the release strategy. It skips number range assignment. Most importantly it skips the change document, so nothing records that it happened or who did it.

The result is the worst possible combination: correct-looking data with no control history. It will reconcile. It will also be undefendable the first time anyone asks how it got there, and [the posting architecture](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) is exactly where that question lands.

That rule is also the reason [an agent should not be connected to the ERP directly](https://gravam.com/blog/connecting-ai-agents-to-your-erp) — the operations it may call have to be a list you wrote, not an interface surface it discovers.

Same reasoning applies to the master data behind a payment. [Business partner and standing-instruction changes](https://gravam.com/blog/business-partner-configuration-sap-treasury) are the actual fraud path in treasury — the settlement account matters more than the deal — and an agent with write access there needs the four-eyes control that data already has, not a new one invented in the agent layer.

## Where an agent genuinely helps, and where it stops

None of the above argues against using them. It argues for putting them on the right side of a line that already exists in the system.

**Reading is where the value is, and it is underrated.** Most of the friction in an SAP finance process is not the posting — it is finding out why something is the way it is. Which document cleared this item, why this valuation moved, what the open items against this counterparty look like, where in the [treasury tables](https://gravam.com/blog/sap-treasury-tables) a number came from. An agent that answers those from the system of record, quickly, with the document numbers attached, removes real hours and cannot corrupt anything.

**Proposing is the useful middle.** Draft the posting, propose the clearing, prepare the payment run — and stop. A human releases. This is the "propose, never post" boundary the [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) settles on, and it holds in SAP for the same reason: the release path is where the control lives, so proposals can be generated freely as long as the release stays human.

**Posting directly is a narrow case, not a default.** It can be right — high-volume, low-value, fully deterministic postings with a tested reversal path and a reconciliation that would catch a bad run. That is a small set, and it is not where most programmes start. It is also not where the benefit is, which is worth saying because the instinct is to measure success by how much got automated. SAP's own example of the narrow case is Cash Application's automatic clearing, and [what it posts and under whose authorizations](https://gravam.com/blog/sap-cash-application-ai) is worth reading before building your own.

## What a period-end conversation looks like

The test I would apply before go-live is not a demo. It is a conversation rehearsed in advance: sit with whoever signs the close and answer the questions they will actually ask.

Show them a document the agent posted. Who does it say created it. What approval is attached. If they sampled thirty of these, could they tell which were agent-originated — and can you produce that population, completely, or only the ones you happen to have logged. If a posting was wrong, what reverses it, and does the reversal carry the same accountability. If the agent were disabled this afternoon, could the process still run on Monday.

Those questions are not about AI. They are the questions [operational readiness](https://gravam.com/blog/operational-readiness-and-acceptance) has always asked, and an agent that cannot answer them is not blocked by its model quality. It is blocked by an integration decision someone made early, usually the shared technical user, usually because it was the easy way to get a proof of concept working.

## How I would let an agent post in SAP

Post through the transaction path, never into the tables. Give the agent its own identity and record the requesting human on the document. Run the agent's composite authorizations through the existing SoD ruleset and treat a conflict as a design defect rather than an exception to be approved. Keep release human for anything irreversible. And put the agent on reading and proposing first, where the value is real and the blast radius is small.

The failure I would expect to see most often is not a bad model. It is a technically successful pilot that posted under a service account, which nobody notices until an auditor asks a question the system can no longer answer.

_See also [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) and [why enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem)._

## Questions this article answers

**Q: Is an AI agent working within a user's SAP authorizations safe?**

Being role-aware is necessary and not sufficient, and the distinction matters more than it sounds. Running inside a user's authorizations means the agent cannot exceed what that user may do. But an agent asked to carry a process end to end needs the union of the roles that process touches — create the vendor, enter the invoice, release the payment — and that union is precisely the combination a segregation-of-duties ruleset is written to forbid. The authorization check passes on each step while the control the ruleset exists to enforce is defeated across them.

**Q: What user ID appears on a document an AI agent posted in SAP?**

Whatever identity the agent authenticated as, and that is a design decision with consequences you cannot fix afterwards. If it posts under a shared technical user, the document's created-by field names the technical user and the chain to a responsible person is broken at the source. If it posts under the requesting user's ID, the document says a person did something they may not know about. The workable arrangement gives the agent its own identity and records the requesting human alongside it, so both are recoverable from the document.

**Q: Should an AI agent post directly to SAP tables or use the normal transaction path?**

The normal path, always. A direct write to the tables behind a document skips the validations, substitutions, release strategy, number ranges and change records that the transaction path applies — which is why the posting looks correct and behaves as if it never happened for every control that matters. The rule that holds across every integration I have reviewed is simpler than it sounds: an agent should be able to do nothing a person could not do through the front of the system, by the same route.

**Q: What does an auditor see when an AI agent posts in SAP?**

The same fields they always sample: who created the document, who changed it, who released it, when, and against what approval. Nothing about the agent changes what is examined; it changes whether those fields still mean anything. If the answer to all of them is one technical user, the auditor's next question is how the company demonstrates that initiation and approval were separated — and the honest answer at that point is usually that it cannot.

---

# Can an AI Agent Approve Its Own Payment?

Source: https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: It is not a new question. It is a release strategy — and the per-transaction limit everyone reaches for is the one an agent defeats first.

**An AI agent approving its own payment is not a new class of problem, and treating it as one is the mistake.** It is a release strategy — the same question every finance function answered decades ago when it decided who may create a payment, who may release it, above what value, and in what combination. The vocabulary is new. The control is not.

Search for it and you will mostly find the answer given in wallet terms: private keys, spend limits, an approval gate above some threshold. That framing comes from consumer and crypto payments, where authority really does live in whoever holds the key. In a company it does not. Authority lives in a release path inside a system of record, and ultimately in a mandate the bank holds. An answer that never mentions either is describing a different problem.

In SAP FI and treasury, this layer already exists — release strategies, approval limits, who is allowed to maintain the bank details behind a payment — the [SAP payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow) walks through the rules and dual control. What follows is that layer's reasoning applied to a non-human initiator.

## The question underneath the question

"Can it approve its own payment" is really three questions, and they have three different owners.

**Is it allowed to initiate?** A configuration question in the source system.

**Can the same identity that initiated also release?** A segregation question, enforced by the system of record — and this is the one that actually matters.

**Would the bank act on the instruction if it got that far?** A mandate question, and the answer does not depend on any of your software.

Most published guidance answers the first, gestures at the second, and never reaches the third.

## Where the control has to live

Here is the part that decides the design: **the separation between initiate and release must be enforced by the system that holds the document, not by the agent framework.**

The reason is structural rather than technical. The agent framework is the component you are trying to constrain. A rule enforced inside it is a rule the constrained thing administers — and every mechanism it offers to express that rule is configuration a future integration can widen, usually for a good reason, usually without anyone connecting the change to a control. It is the same argument as [an instruction is not a control](https://gravam.com/blog/the-enterprise-ai-control-layer): what is enforced by the thing being governed is not a boundary.

The release path in the ERP or the TMS is different in kind. It sits on the document. It cannot be talked out of its opinion. It produces evidence as a side effect. And it already exists, tested, with someone's name against the configuration — which is the [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) model the company already runs.

So the design rule is short: an agent may propose a payment through the same door a person would, and the release path treats it exactly as it treats a person. If your architecture has the agent writing through an integration that bypasses the release path, you have not automated a payment — you have built a second, uncontrolled one.

## The per-transaction limit is the wrong limit

This is the claim I would most want a design review to take away, because the control that gets reached for first is the one an agent defeats first.

Give an agent a €10,000 per-transaction ceiling and instruct it to settle a supplier's balance. It has an obvious, entirely reasonable route to completing the task: several payments, each under the ceiling. Nothing has been circumvented in any sense the agent would recognise. It was given a constraint and a goal, and it satisfied both.

Accounts payable has a name for the human version and has watched for it for as long as there have been approval thresholds. The countermeasure is not a lower ceiling. It is that the ceiling was never meant to be the only limit.

**Aggregate.** Total per counterparty per period, checked against everything already released this period rather than against the item in hand.

**Velocity.** How many instructions may be released in a window at all. Most damaging incidents are not one clever payment; they are the same wrong payment repeated faster than anyone looked.

**Total exposure.** A ceiling on what the whole capability may move in a day, independent of how it is distributed.

> An agent given a per-transaction ceiling and a goal will meet both. Structuring is not an attack — it is the obvious way to satisfy the constraint you actually wrote.

Note the shape of that. The per-transaction cap is not wrong; it is incomplete in a way that only shows up against a tireless initiator. A person structuring payments to stay under a threshold is doing something deliberate and detectable. An agent doing it is following instructions.

## The bank is a control you did not configure

Every internal limit sits inside software you own. There is one that does not, and it is the reason a badly configured agent is less catastrophic than it first appears.

Payment authority at a bank comes from the account mandate — who may sign, to what value, in what combination, on which accounts. It is a legal arrangement, maintained through [bank account management](https://gravam.com/blog/electronic-bank-account-management-ebam), and no amount of configuration in an ERP, a TMS or an agent platform widens it. If a released instruction exceeds what the mandate confers, the bank declines it.

Two practical consequences. First, "what could this agent theoretically move" has a ceiling you did not set and cannot accidentally raise from inside. Second, that ceiling is only as current as your mandate housekeeping — which is exactly the discipline that decays quietly, because nobody's job description includes noticing that a signatory left in March.

Worth adding to the design review: which accounts is this capability able to reach, and what do their mandates actually say today.

## Accountability is a field, not a policy

When something goes wrong, nobody reads the AI governance policy. They open the document and look at who created it, who changed it, and who released it.

That is what makes a shared technical user so damaging. It is administratively convenient, it is what most integrations do by default, and it destroys attribution at the exact moment attribution is the whole question. A document that says a service account released a payment tells an investigator nothing and gives them nowhere to go.

The workable pattern gives the agent [an identity of its own](https://gravam.com/blog/agent-identity-and-permissions), scoped to the task, and records the human who requested the run so the document carries both — what acted, and on whose behalf. It is more work at build time and it is the difference between an incident with a thread to pull and an incident without one. The same reasoning applies to the [audit trail](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) around it: the record has to be produced by the system, not by the agent describing itself.

## Where I would draw the release line

An agent may create and propose. It may not release anything irreversible under the identity that created it — enforced in the system of record, not in the agent platform. And the releasing human has to see the source rather than the agent's summary of it, or the [four-eyes control has already collapsed into one](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) without anyone changing a setting.

Limits are cumulative, not per item: aggregate per counterparty, velocity per window, total exposure per day. Assume the per-transaction ceiling will be met by splitting, because it will.

The agent gets its own identity. The requesting human is recorded on the same document. Neither of those is optional if you intend to be able to explain what happened.

And before any of it: check what the bank mandate on those accounts actually permits, because that is the only limit in the design that your own configuration cannot quietly widen.

_See also [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) and [human decision rights in AI-native workflows](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows)._

## Questions this article answers

**Q: Can an AI agent approve a payment it created?**

An AI agent should not be able to approve a payment it created, and whether it can is a property of your system of record rather than of the agent. The rule that an initiator cannot approve their own item is enforced in the ERP or treasury system's release path — so if the agent creates a payment under one identity and releases it under the same one, the separation is gone no matter what the agent framework claims. Enforce it where the document lives, because the agent framework is the thing being controlled and cannot be the thing that controls it.

**Q: What spending limits actually stop an AI agent?**

Not a per-transaction cap on its own: an AI agent asked to settle a supplier's balance will meet a per-item ceiling by splitting the payment, which is the same structuring a person does and which accounts payable controls have watched for decades. The limits that hold are cumulative: an aggregate per counterparty per period, a velocity limit on how many instructions may be released in a window, and a total exposure ceiling. A per-transaction cap is useful as one layer, never as the layer.

**Q: Who is accountable for a payment an AI agent released?**

Whoever is named in the document's own fields. Accountability in a finance system is not a statement in a policy; it is created-by, changed-by and released-by on the record, and it is what an auditor samples. If the agent acts under a shared technical user, those fields say the technical user did it and the chain is broken before any investigation starts. Give the agent an identity of its own and record the human who requested the run, so the document carries both.

**Q: Can software grant an AI agent authority the bank does not recognise?**

No, and this is the limit most discussions of agent spending controls miss entirely. Payment authority at a bank comes from the account mandate: who may sign, up to what value, in what combination. That is a legal arrangement between the company and the bank, and no configuration inside an ERP, a treasury system or an agent framework can widen it. It is also a useful backstop — if an instruction exceeds the mandate, the bank rejects it regardless of what any internal system believed.

---

# Security Boundaries for Enterprise AI Agents

Source: https://gravam.com/blog/enterprise-ai-agent-security-boundaries
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-09-04
Summary: An agent that reads untrusted content can be instructed by it. What the boundaries are, which of them hold under pressure, and which are theatre.

**An enterprise agent that reads a document can be instructed by that document, and there is no reliable way to stop it.** Instruction and data arrive on the same channel, get tokenised the same way, and are weighed against each other by a process that has no notion of provenance. Every serious mitigation is therefore about consequence rather than prevention: assume something in the context window will eventually be hostile, and make that fact boring.

That framing is not a counsel of despair. It is the ordinary way controls work in a function that moves money. Nobody designs a payment process on the assumption that no one will ever try a fraudulent invoice — you assume it, and you build so that trying is expensive and succeeding is hard. This is the same discipline applied to a new kind of participant.

Enterprise finance systems already run on that discipline: least privilege, joiner-mover-leaver, four-eyes on payments and on the static data behind them, break-glass access that has to be logged because it will be used at 2am. What follows is that discipline reasoned forward onto agents. Where the AI-specific behaviour is contested or moves quickly, I have said so rather than asserted a fix.

## The three questions a security review actually asks

Not "is the model safe". Three concrete ones, and a design that cannot answer all three is not ready to be reviewed.

**What can it read?** Not what you intended it to read — what its credential permits.

**What can it do?** The set of side effects reachable from its tools, including the ones reachable indirectly.

**Whose authority is it acting under, and how do you take that away?** Attribution and revocation, which are the two things an incident needs and the two things a shared service account destroys.

## Read is not the safe half

The instinct is to treat read-only as the harmless configuration and put the caution on writes. That instinct is half right and the half it gets wrong is the one that leaks.

Enterprise content permissions were built around two implicit limits: a person has to know where a document is, and a person has limited hours. Most over-broad permission sets have been harmless for years because both limits held. An agent has neither. A share that "everyone in finance can technically open" becomes, the day you point a retrieval system at it, a share that everyone in finance can _ask questions about_ — including questions nobody would have thought to go looking for the answer to.

So the read boundary is a scoping decision, and it is not the same as the permission model you already have. Two rules that hold up:

**Scope retrieval to the task, not to the user's entitlements.** An agent answering questions about supplier invoices needs supplier invoices. Giving it the requesting user's full document reach because that is administratively easier is how a salary schedule ends up in an answer about procurement.

**Fetch from the system of record, not the convenient copy.** The extract, the warehouse table, the export somebody set up years ago — those carry their own scoping, usually looser and undocumented, and they are stale in ways the answer will not mention. This is an accuracy argument as much as a security one, and it is the same argument [enterprise AI makes as an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem).

## Injection: what actually reduces the risk

Assume the hostile string arrives. Rank the mitigations by whether they survive an adversary who knows they are there.

**Weak, and widely sold as strong.** Instructing the model to ignore instructions found in content. This is a request, made in the same channel as the attack, to a component that cannot verify origin. It raises the effort slightly. It is not a boundary, for the same reason [an instruction is not a control](https://gravam.com/blog/the-enterprise-ai-control-layer).

**Weak on its own.** Filtering input for injection-shaped text. Detection of an open-ended natural-language pattern is an arms race you do not win, and the false-negative you care about is the one written by someone who read your filter.

**Genuinely effective, in rough order of strength.**

- **Least privilege on the credential.** The single highest-value control, because it bounds every attack at once rather than any one of them. An agent that cannot reach the payments API cannot be talked into using it.
- **A choke point that is not a model.** Every consequential action passes through code that evaluates policy, thresholds and limits deterministically. The model proposes; something that cannot be persuaded disposes.
- **Human approval for the irreversible.** Not for everything — an approval queue nobody has time to work is worse than none, because it launders responsibility. For the actions where being wrong cannot be undone.
- **Separating trusted from untrusted context.** Decide _before_ retrieval which content may influence which actions. The common pattern that works: content from outside the company may inform an answer but may never be the basis for a tool call that writes.
- **Rate and volume limits.** Most damaging incidents are not one clever action; they are the same wrong action four thousand times before anyone looked. A cap on actions per window turns a catastrophe into a ticket.

That ordering is not just my opinion of it. The 2026 OWASP list ranks injection first on the practitioner vote while the raw incident record drops it out of the top ten entirely — a defence effect, not an absence of risk, and the same argument as above read from the other end. [The full ten, and what moved](https://gravam.com/blog/owasp-llm-top-10-2026-for-enterprise-finance).

> Injection is not the vulnerability. The vulnerability is an agent whose credential makes a successful injection worth attempting.

## Tools are the actual attack surface

The model is not where the danger is. The danger is the set of functions you handed it, and the transitive closure of what those functions can reach — a point that follows directly from [where the agent sits relative to your systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems).

Four rules I would hold to, all of them borrowed unchanged from interface design:

**One tool, one verb, one scope.** A tool called `update_record` that takes a table name is not a tool, it is a database session. Narrow tools are auditable and revocable; broad ones are neither.

**No tool composes into a wider one by accident.** Read-supplier plus write-payment-instruction is a payment capability, whatever the individual descriptions say. Review the set, not the items.

**Every tool call is a logged event with its inputs.** At the grain of the call, not a summary. This is [audit trails and logging](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) applied to a caller that acts far faster than a person and whose reasoning is not recoverable afterwards unless you captured it.

**Idempotency on anything that writes.** Agents retry. Retries duplicate. A duplicated payment instruction is a bad afternoon.

## The identity problem, and the leaver nobody removes

Agent identity deserves its own treatment and gets it in [who is the AI acting as](https://gravam.com/blog/agent-identity-and-permissions). The security-specific point is narrower and it is about revocation.

Enterprise access management is a lifecycle, not a launch task — that is [the lesson provisioning keeps reteaching](https://gravam.com/blog/access-management-and-user-provisioning-treasury). A person joins, moves and leaves, and each of those triggers something. A standing agent identity triggers nothing. It does not change roles, does not go on leave, does not resign, and is not on any report the access review reads. It accumulates the permissions each new use case needed and never gives one back.

Two practical consequences. First, agent identities need a review cadence of their own, because they will not appear in the human one. Second, revocation must be tested, not assumed: if disabling the identity leaves outstanding tokens valid for another hour, then "we can turn it off" is a statement about the console rather than about the system.

## What defence in depth looks like here

The pattern is the one [payment fraud prevention](https://gravam.com/blog/payment-fraud-prevention-in-treasury) already uses: layers that each assume the previous one failed.

| If this fails | This still holds |
| --- | --- |
| The model is persuaded by hostile content | Its credential cannot reach the sensitive system |
| The credential is wider than intended | The action hits a deterministic policy check |
| The policy check has a gap | The action is irreversible, so it needs a human |
| The human approves too fast | Volume limits cap the damage per window |
| Everything fails | Event-grain logs make it reconstructable, and a stop control exists |

Read that table as a design brief rather than a maturity model. You do not need all five to start; you need to know which ones you have, so the conversation about the missing rows happens before go-live rather than after an incident.

And a caution I would put in writing on any design review: the control people are most confident about is usually the one they have never tested. Ask when the stop control was last exercised, and on what.

## The boundaries I would set for an agent

Give the agent its own identity, scoped to the task and not to the user's accumulated entitlements. Route every consequential action through code rather than through persuasion. Decide which context is untrusted before you retrieve it, not after. Log at the grain of the call. Cap volume. Put a human on the irreversible things and give them enough time to actually be one — because an oversight step nobody can exercise is the failure mode [the AI Act's human oversight requirement](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems) will eventually ask you to evidence.

None of that prevents injection. All of it makes injection an incident report rather than a loss.

_See also [the enterprise AI control layer](https://gravam.com/blog/the-enterprise-ai-control-layer) and [designing the exception path](https://gravam.com/blog/designing-the-exception-path)._

## Primary sources

The one external claim — that the 2026 OWASP GenAI/LLM Top 10 ranks Prompt Injection first on the community vote while the raw incident record drops it out of the top ten — verified against the project's own 2026 preface (7,714 incidents, 6,639 classifiable; vote weighted three-quarters, incidents one-quarter). The rest of the article is control design reasoned from finance practice, not sourced fact.

- OWASP GenAI Security Project — GenAI/LLM Top 10, 2026 final: preface (method, incident corpus and rank movements) — accessed 2026-09-04 — https://raw.githubusercontent.com/GenAI-Security-Project/GenAI-LLM-Top10/main/2026/final/LLM00_Preface.md
- OWASP GenAI Security Project — GenAI/LLM Top 10, 2026 final (repository directory, LLM01–LLM10) — accessed 2026-09-04 — https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final

## Questions this article answers

**Q: Can prompt injection be prevented in an enterprise agent?**

Prompt injection cannot be prevented reliably, and a design that depends on preventing it is the design to worry about. Instruction and data arrive through the same channel, so a model has no dependable way to tell a supplier's invoice text from a command. What you can do is make a successful injection uninteresting: give the agent an identity that can only reach what this task needs, route every consequential action through something that is not a language model, and require a human for anything irreversible. Treat injection as certain and design for the blast radius, the same way payment controls assume someone will eventually try.

**Q: What can an AI agent read that a person could not?**

Usually the same documents, but with an important difference in practice. Enterprise content permissions were designed around the assumption that a person has to know where to look and has limited hours. An agent has neither limit, so a permission set that was theoretically over-broad and practically harmless becomes genuinely over-broad the moment something can read all of it and answer questions about it. The exposure is rarely a new leak; it is an old one that nobody could exploit at scale until now.

**Q: How do you revoke an AI agent's access in an incident?**

Test it before you need it, because revocation is the control most likely to be assumed rather than verified. Disabling an identity in a console does not necessarily stop work already in flight: outstanding tokens may stay valid for their remaining lifetime, a queued job may carry credentials it obtained earlier, and a cached session may survive the change. Establish what actually stops within what window, and make sure at least one control — a rate limit, a policy check, a required approval — sits in the path independently of the identity, so revocation is not the only thing standing between you and a running incident.

**Q: What is trusted versus untrusted context for an AI agent?**

Trusted context is content whose origin you control and whose integrity you can assert: your own prompt, your policy text, a record you fetched from a system of record. Untrusted context is everything that entered from outside — an email body, a supplier PDF, a web page, a document a user uploaded, and in most designs the output of another agent. The distinction matters because the model cannot make it for you. It has to be made in the surrounding system, by deciding what content is allowed to influence what actions, before the content is read rather than after.

---

# The EU AI Act's High-Risk Rules Are a Control Environment

Source: https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Updated: 2026-09-02
Reviewed: 2026-09-02
Summary: The high-risk deadline moved to December 2027. What the rules ask for did not move — and a finance function already runs most of it under other names.

**On 2 August 2026 the European Union's biggest AI compliance deadline arrived, and most of it was not there.** The high-risk requirements everyone had been preparing for had been pushed back by sixteen months, earlier that summer, to 2 December 2027 for stand-alone systems and 2 August 2028 for AI embedded in products that are already regulated. The transparency duties in Article 50 did arrive, on the original date. So a lot of published guidance is now describing a deadline that did not happen, and a lot of programmes have quietly relaxed against a date that has not actually gone away — it has moved to a point where the work is bigger.

I am not a lawyer and nothing here is legal advice; whether a particular system falls in scope is a legal determination about that system in that use. What I can offer is the other half, which is much less written about: **what the high-risk requirements actually ask you to build, and why a finance function has most of it already, under different names.**

## What moved, and what did not

The Act entered into force on 1 August 2024 and applies in stages. The stages that are already live matter more than the one that slipped.

- **2 February 2025** — the prohibitions on unacceptable-risk practices, and the AI literacy obligation, began to apply. The literacy duty survived the Omnibus in a weakened form; it did not disappear.
- **2 August 2025** — obligations on providers of general-purpose AI models began to apply.
- **2 August 2026** — the Article 50 transparency duties applied as originally scheduled: disclose that a person is interacting with an AI system, and mark AI-generated or manipulated content. A short grace period applies to systems already on the market.
- **2 December 2027** — the high-risk requirements for Annex III stand-alone systems, moved from 2 August 2026.
- **2 August 2028** — the high-risk requirements for Annex I systems embedded in already-regulated products, moved from 2 August 2027.

The mechanism is worth one sentence because it changes how much you can rely on the dates. The Commission's original proposal made the deferral conditional on standards being ready; the agreed text replaced that with fixed dates. So these are dates, not triggers, and planning against them is reasonable.

> A deferred deadline is not a smaller obligation. It is the same obligation, with more systems in scope by the time it lands.

That last point is the one I would put in front of a steering committee. Sixteen months is not relief if the number of AI-touching processes in your landscape doubles in the same period, which on current trajectory it will. The programmes that will find December 2027 comfortable are the ones treating the extension as time to build the evidence, not time to stop.

## The requirements, in the language you already use

Chapter III, Section 2 of the Act sets out what a high-risk system must have. Read the seven articles cold and they sound like a new discipline. Read them as someone who has implemented financial systems and they are almost entirely familiar — because they are the same answers to the same problem, which is how you let a system do something consequential and still be able to say what happened and why.

**Article 9 — Risk management system.** A continuous, documented process for identifying what could go wrong across the lifecycle and doing something about it. This is a risk register with an owner and a review cadence. Every programme I have delivered ran one; the discipline that makes it real rather than decorative is that each entry carries an owner, a date and a next action, which is exactly what a [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) is for.

**Article 10 — Data and data governance.** Training, validation and test data must be governed: relevant, representative, and examined for gaps and bias. A finance function has fought this fight already, in the form of [data quality and governance](https://gravam.com/blog/treasury-data-quality-and-governance) and the question of [which system owns which record](https://gravam.com/blog/treasury-system-of-record). The novelty is not the requirement. It is that a model makes bad data _confident_ rather than obviously wrong.

**Article 11 — Technical documentation.** A description of what the system is, how it was built, what it was tested against and how it performs. This is a [solution design document](https://gravam.com/blog/solution-design-and-blueprint-for-finance-systems) that stayed current — which is the hard part, and the reason most technical documentation fails an audit is not that it was never written.

**Article 12 — Record-keeping.** Automatically generated logs of events over the system's lifetime. Not a dashboard: records, at the grain of an event, retained. A treasury systems person will recognise this immediately as [audit trails and logging](https://gravam.com/blog/audit-trails-and-logging-treasury-systems), and will also recognise the trap — a log that aggregates cannot answer the only question anyone ever actually asks, which is what happened to this specific record on this specific day.

**Article 13 — Transparency and provision of information to deployers.** The people operating the system must be told what it does, what its limitations are, and the conditions under which it works. In practice this is the honest version of a functional specification: not what it is supposed to do, but where it stops being reliable.

**Article 14 — Human oversight.** The system must be designed so a person can understand its output, decide not to act on it, and intervene. This is the closest match of all, and I will come back to it.

**Article 15 — Accuracy, robustness and cybersecurity.** It has to work, keep working under conditions it was not shown, and resist manipulation. This is [testing strategy](https://gravam.com/blog/testing-strategy-for-finance-systems), [interface monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation), and [access management](https://gravam.com/blog/access-management-and-user-provisioning-treasury), applied to a component whose failure mode is producing a plausible wrong answer rather than an error.

## Human oversight is the one that will be got wrong

Article 14 is where I would spend the attention, because it is the requirement most likely to be satisfied on paper and failed in operation.

The Act asks that oversight be effective — that the person can interpret the output, is aware of the risk of automation bias, can decide not to use the system, and can stop it. What that means in a real process is a throughput question, not a policy question. If a reviewer is presented with four hundred items and the process assumes they clear them in an afternoon, they are approving at a rate that makes reading impossible, and the oversight is decorative.

Finance already knows this failure. It is the four-eyes approval where the second signature is a habit, the exception queue nobody has time to work, the control that exists in the procedure document and not in anyone's day. The [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) discipline exists precisely because a control that cannot be exercised is not a control — and that reasoning transfers directly to a component that produces output faster than any human can evaluate it.

The design question, then, is not "who signs off". It is: what is the reviewer shown, how long do they have, what does declining cost them, and what evidence is captured when they accept. That is a workflow decision, and it is the same one as [who decides what, on what evidence](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows).

## What I would actually do with the extra sixteen months

Not compliance work. Inventory and design work, which is cheaper now than later and useful even if nothing in your landscape turns out to be high-risk.

**Know what you have.** Most organisations cannot currently list the AI-touching processes in their own landscape, because several arrived as features of software they already owned rather than as projects. You cannot classify what you have not enumerated, and the enumeration is a week of work that gets harder every quarter.

**Establish scope early, and write down the reasoning.** Whether a given system is high-risk is a legal determination — but the _inputs_ to it are yours: what the system decides, about whom, with what consequence. Having that written before someone asks is the difference between a conversation and a project.

**Build the record-keeping first, whatever the classification.** Article 12-style logging is the requirement with the longest lead time and the widest usefulness. You cannot retrofit a log of what the system did last quarter. And if it turns out nothing you run is high-risk, you still have [the observability](https://gravam.com/blog/production-ai-observability) that makes the thing debuggable, which you wanted anyway.

**Treat the control layer as the deliverable.** The requirements above are not properties of a model — they are properties of what surrounds it. Which is the argument I would make regardless of regulation: the safety and auditability of an AI capability live in [the control layer](https://gravam.com/blog/the-enterprise-ai-control-layer), not in the choice of model, and building that layer is what turns a deferral into a head start.

## The honest summary

The deadline moved; the work did not. And the work is less alien than the framing around it suggests, because the requirements are a restatement — in unfamiliar vocabulary, for an unfamiliar component — of the control environment a regulated finance function has been running for decades. Risk register, data governance, current documentation, event-grain logs, honest limitations, real oversight, tested robustness.

The organisations that will struggle in December 2027 are not the ones with weak models. They are the ones that cannot say what their AI systems did, to what, on whose authority — which is the same thing that has always separated a system you can operate from a system you merely own.

If you want the same ground covered voluntarily rather than legally, [the NIST AI Risk Management Framework](https://gravam.com/blog/nist-ai-rmf-functions-and-categories) organises it into four functions and nineteen categories, and most of them turn out to be controls a finance function already runs.

_See also [why enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem), [agent identity: who is the AI acting as?](https://gravam.com/blog/agent-identity-and-permissions) and the [OWASP LLM Top 10 for enterprise finance](https://gravam.com/blog/owasp-llm-top-10-2026-for-enterprise-finance)._

## Primary sources

EU AI Act as amended by the AI Omnibus (Regulation (EU) 2026/1744) — approved by the European Parliament on 16 June 2026 and in force since 27 July 2026. Dates verified 3 September 2026.

- EU AI Act Omnibus Agreement — Postponed High-Risk Deadlines and Other Key Changes (Gibson Dunn) — accessed 2026-08-19 — https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
- EU Approves Delays and Other Amendments to Certain EU AI Act Obligations (Morgan Lewis) — accessed 2026-08-19 — https://www.morganlewis.com/pubs/2026/06/eu-approves-delays-and-other-amendments-to-certain-eu-ai-act-obligations-what-businesses-should-know
- EU AI Act — Chapter III, Section 2: Requirements for High-Risk AI Systems (Articles 9–15) — accessed 2026-08-19 — https://artificialintelligenceact.eu/chapter/3/

## Questions this article answers

**Q: Did the EU AI Act high-risk deadline move?**

Yes, for the EU AI Act's high-risk obligations specifically. Under the AI Omnibus amendments, which the European Parliament approved on 16 June 2026 and which entered into force on 27 July 2026, the requirements for Annex III stand-alone high-risk systems moved from 2 August 2026 to 2 December 2027, and the requirements for Annex I systems embedded in already-regulated products moved from 2 August 2027 to 2 August 2028. Fixed dates replaced the conditional trigger mechanism the Commission had originally proposed. What did not move is everything else: the prohibitions and the AI literacy duty have applied since February 2025, the general-purpose AI model obligations since August 2025, and the Article 50 transparency duties took effect on schedule on 2 August 2026.

**Q: Which parts of the EU AI Act already apply in 2026?**

Three groups. The prohibitions on unacceptable-risk practices and the AI literacy obligation have applied since 2 February 2025. The obligations on providers of general-purpose AI models have applied since 2 August 2025. The Article 50 transparency duties — telling a person they are interacting with an AI system, and marking AI-generated content — applied from 2 August 2026 as originally scheduled, with a short grace period for systems already on the market. Only the high-risk requirements in Articles 9 to 15 were deferred.

**Q: Is an internal finance AI tool a high-risk AI system?**

Usually not, and that is worth establishing early rather than assuming either way. Annex III lists the categories that make a stand-alone system high-risk, and ordinary finance operations — reconciliation, cash forecasting, close support — are not among them. Systems used in creditworthiness assessment of natural persons, or in employment decisions, are. This is a legal determination about a specific system in a specific use, not something to settle from a blog post; the point of establishing it early is that the answer changes how much documentation you need, and finding out late is what makes it expensive.

**Q: What does the AI Act require for human oversight?**

Article 14 requires that high-risk systems be designed so that a person can genuinely oversee them — understand what the system is doing, interpret its output, decide not to use it, and intervene or stop it. The word that does the work is 'genuinely'. An oversight arrangement where a person approves faster than they could possibly read is not oversight, and a finance function already knows this: it is the same failure as a four-eyes control where the second pair of eyes clicks through. The design question is what the reviewer is shown and how much time the throughput allows them.

---

# Agent Identity: Who Is the AI Acting As?

Source: https://gravam.com/blog/agent-identity-and-permissions
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-08-19
Summary: Delegated, shared, agent-specific or temporary — the four identities an AI agent can act under, and what each one costs you in attribution and blast radius.

**Every AI agent that touches an enterprise system is acting as somebody.** That is not a philosophical statement, it is a technical one: a call arrives at a system, it carries a credential, and the system writes something in a log about who did it. Whether anyone chose that identity deliberately is a different question, and in most designs it is not chosen at all. The agent acts as whatever credential was available when the integration was built, which usually means a technical account with rights that accumulated over years for reasons nobody remembers.

The uncomfortable version of the question arrives later, and it always arrives in the same form. Somebody looks at a record that changed, asks who changed it, and the answer is a service account name. That is the moment the identity decision gets made — retrospectively, expensively, under scrutiny. It is much cheaper to make it at design time, straight after you have decided [where the agent sits relative to the systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems) at all.

## Four things an agent can act as

There are really only four options, and every design is one of them or a combination.

**The user's delegated identity.** The agent acts on behalf of the person who asked, carrying that person's rights and no more. It is the most honest model of what is actually happening — a person wanted something done, and a machine did it for them — and it inherits the whole existing authorisation estate for free. Whatever that user could not do, the agent cannot do either, without anyone building a second permission model.

Its weakness is that the audit trail stops being believable. The log says a named person performed four hundred actions between 02:00 and 02:06, and the person will tell you, truthfully, that they were asleep. Attribution is technically correct and practically misleading, unless the record also carries the fact that an agent performed it on their behalf. Revocation is blunt too: stopping the agent means interfering with the person.

**A shared service identity.** One technical account serves the agent, and usually several other things as well. It is the default because it already exists, and it is the worst of the four for exactly that reason. Its rights are the union of everything that has ever needed it, which makes the blast radius unknowable without an investigation. Attribution is gone — the log shows the account, not the request or the requester. And revocation is unusable in an incident, because switching the account off also stops three interfaces nobody has mapped. It is also the easiest default for an MCP server placed in front of an ERP, which is [where this decision quietly gets made](https://gravam.com/blog/mcp-server-sap-authorization).

**An agent-specific identity.** The agent has its own account, used by nothing else, scoped to precisely the objects and operations its job needs. Attribution is clean. Blast radius is bounded by design rather than by history. Revocation is surgical: disable it and the agent stops, and nothing else does. This is the model I would reach for by default for anything that writes.

The trade-off is that the rights are standing. They exist at three in the morning when nobody is asking for anything, which means the credential itself is now an asset worth protecting, and a scope that was right at go-live will drift as the agent's job grows.

**A temporary scoped credential per task.** The agent is issued rights for one piece of work, narrowed to that work, valid for a short window, and then gone. This is the strongest position — least privilege expressed in time as well as in scope — and it is the most work to build, because something has to decide what the scope for this particular task is, and be right.

| Identity model | Attribution | Blast radius | Revocation | What an audit sees |
| --- | --- | --- | --- | --- |
| **Delegated user** | Names a person, misleadingly | That user's full rights | Blunt — hits the person too | A human who did impossible volumes |
| **Shared service account** | None | Unknowable without investigation | Unusable — breaks other consumers | An account, and no way back to a requester |
| **Agent-specific** | Clean, per agent | Bounded by an explicit scope | Surgical | An agent, and whoever it acted for if you kept it |
| **Temporary scoped** | Clean, per agent and per task | Bounded per task and in time | Expiry does most of the work | An agent, a task, and the scope it was given |

The pattern worth stealing, if you build nothing else, is an agent-specific identity **bounded by** the requesting user's rights: the action attributes to the agent, and the agent may not exceed the person who asked. You get clean attribution and surgical revocation, and you inherit the existing authorisation model as a ceiling rather than rebuilding it.

## The questions that actually decide it

Four options is not a design. These questions are.

**May an agent act with permissions its requesting user does not have?** Usually the answer should be no, and where it is yes, that must be a deliberate, narrow, documented exception rather than a side effect. The failure mode is specific and it is not exotic: an agent with broad standing rights becomes an accidental privilege-escalation route, where asking it nicely accomplishes something the asker could not do directly. Nothing was hacked. The agent did its job. The organisation simply built a door beside the one it had locked.

**May an agent approve its own proposal?** No — and the reason is not about the agent's quality. Segregation of duties has never been a statement about competence. A trusted employee of twenty years is also not permitted to approve their own posting, because the control buys a second, independent look, and one actor doing both halves removes it entirely. An agent that drafts and then approves is a single identity performing maker and checker while the workflow diagram still politely shows two boxes. The same holds for two agents built from the same design reviewing each other; independence is the point, and two instances of one thing do not have it.

**How is the scope bounded?** To the smallest set that lets it finish its actual job, defined as a list rather than a category. "Read access to finance data" is not a scope; a named set of objects with named operations is. Two habits keep it honest: grant nothing "for now" during the pilot, because pilot access is production access with a friendlier name, and re-derive the scope from what the agent has genuinely used rather than from what somebody thought it might need.

> An audit does not ask what the agent was permitted to do. It asks who did this — and a shared service account has no answer.

**What happens when the person changes role or leaves?** Under delegated identity the existing leaver process largely handles it — provided disabling the account also revokes the agent's outstanding tokens, which is worth checking rather than assuming. Under a standing agent identity, nothing happens at all — and that is the honest weakness of the model I just recommended. The access outlives the employee, then outlives the reorganisation, and eventually nobody in the building can tell you why it exists. So every agent identity needs a named owner who is not the person who built it, a review on a real cycle, and where possible an expiry that forces the conversation rather than waiting for one.

**Who can revoke it, and how fast?** In an incident, the useful question is not whether revocation is possible but whether the person on call at 22:00 on a Friday can do it without a change request, and knows they can. That is a runbook and a rehearsal, not an architecture diagram. It is also the identity-shaped half of the kill switch described in [the control layer](https://gravam.com/blog/the-enterprise-ai-control-layer): stopping the agent and revoking its rights are two different actions, and you want both.

**What must the log contain?** Enough for someone with no context to reconstruct a specific action six months later. In practice that is: who requested it, which identity executed it, what the agent proposed, what it actually did, which scope permitted it, which approval covered it if one was required, and which prompt and model version produced the proposal. The test I would apply is simple — hand a single record to someone who has never met the system and ask them to explain why it changed. If they need you in the room, the log is decoration rather than evidence, and the [observability work](https://gravam.com/blog/production-ai-observability) has not been done.

## Read, propose, execute

Identity gets easier to reason about when you stop treating "access" as one thing. An agent doing genuinely useful work usually needs three different levels of authority in the same workflow, and they can carry different identities.

Reading is broad and low-consequence, though not zero-consequence: an agent that can read is an agent that can surface something to whoever asks, and enterprise content permissions were designed on the assumption that a human would have to know where to look.

Proposing needs almost nothing. A proposal is a record in a queue. It should not require any right in the target system at all, which is why propose-and-queue is such a comfortable placement — the agent's identity there is nearly powerless by construction.

Executing is where the whole question lives, and it should be the narrowest identity in the design, used for the shortest possible list of operations. Separating the three means the agent is not carrying execute-level rights while doing read-level work, which is most of what it does most of the time. Mapping this properly is part of laying out [the workflow end to end](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow) rather than describing the agent as a single actor with a single set of keys.

## Earning it

The instinct, when an agent works well, is to widen its identity. It has been right for two months, the queue is long, the approvals feel like ceremony — so give it more.

I would invert the test. The evidence that an agent should get a wider identity is not that its outputs have been good. It is that it has repeatedly demonstrated it does not need the wider identity: its proposals fall inside a narrow scope, it stops rather than improvising when something is outside its remit, its exceptions route correctly, and the approvals it collects almost never change what it proposed. An agent that keeps bumping into its scope is telling you the scope is wrong; an agent that has never needed to bump into it is the one that can be trusted with more.

That is not caution dressed up as principle. It is the same standard any organisation applies to people, and it comes from the same place as the argument that [enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem): authority is granted against demonstrated behaviour, not against enthusiasm.

## Choosing an identity model for AI agents

Choose the identity model explicitly and write down why, because the default is a shared account and the default is the worst option available. Prefer an agent-specific identity, bounded by the requesting user's rights, so attribution is clean and the existing authorisation estate acts as the ceiling. Move to temporary scoped credentials wherever the work divides into tasks cleanly enough to make it real. Never let an agent approve its own proposal, or exceed the person who asked, without a documented exception someone signed. Give every agent identity an owner, a review cycle and an end date. Rehearse revocation before you need it. And log at the grain of a single action, because the question that eventually arrives is never about averages — it is about one record, one day, and whose name is on it.

***

_See also [the enterprise AI control layer](https://gravam.com/blog/the-enterprise-ai-control-layer) and [how AI agents fit into existing enterprise systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems)._

## Questions this article answers

**Q: Should an AI agent use the user's identity or its own?**

Whether an agent acts under the user's identity or its own depends on which property you need most. Acting under the requesting user's delegated identity is honest about who wanted the work and inherits their limits automatically, but the trail then shows a person doing things at a volume and hour no person did, and revoking the agent means touching the person. An identity of its own attributes cleanly, can be scoped to exactly its job, and can be switched off without disturbing anyone — at the cost of a standing set of rights that exists whether or not anyone is asking. Many designs need both: the agent's own identity, bounded by the requesting user's.

**Q: Can an AI agent approve its own proposal?**

No, and the reason has nothing to do with how good the agent is. Segregation of duties exists because one actor doing both halves removes the second look entirely, and the control was never a judgement about competence — a trusted employee is also not allowed to approve their own posting. An agent that drafts and then approves is one identity performing maker and checker, so the control is gone even though the workflow diagram still shows two steps. The same applies to two agents from the same design: independence of judgement is what the control buys, and two instances of one model do not have it.

**Q: What happens to an AI agent's access when an employee leaves?**

An agent's access when an employee leaves depends entirely on how the identity was set up, which is why it is a design question rather than an operational one. If the agent acts under delegated user identity, a leaver process that disables the account generally stops the agent too — though only once the outstanding tokens are revoked rather than left to expire. If it holds its own standing rights that were granted because a particular person sponsored them, nothing happens at all — the access survives the person, and it usually survives the reorganisation after them. Any agent identity needs an owner, a review cycle and a defined end, or it quietly becomes permanent.

---

# The Enterprise AI Control Layer

Source: https://gravam.com/blog/the-enterprise-ai-control-layer
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-19
Reviewed: 2026-09-04
Summary: You cannot make an AI system safe by improving the model. Safety lives in a control layer between your systems of record and the agents acting on them.

**An enterprise AI control layer is the component between your systems of record and the agents acting on them that decides whether anything the model produces is allowed to become an action — it owns identity, permissions, deterministic thresholds, approvals, validation, limits, logging and the stop control.** Ask instead how an enterprise intends to keep an AI capability safe and the answer is usually a description of the model: a better one, a more carefully tuned one, a system prompt with the rules written into it very firmly. That answer has a structural problem. The model is the part of the design most likely to be replaced, least likely to behave identically twice, and completely unable to enforce anything. You can improve it and improve it and never arrive at safety, because safety was never a property of the model. It is a property of what the model is allowed to do.

That "allowed" is a thing. It has to live somewhere, be owned by someone, and be designed on purpose. In most AI architectures as they are actually described, it is not designed at all — it is scattered across prompt text, a few conditionals, and the assumption that whoever configured the credentials was thinking carefully that day.

## The layer you already have

This will sound less new than it is. Almost every enterprise landscape already runs one. Nobody drew it as a box on the architecture diagram, but it is unmistakably there.

It is the release strategy on the payment run. The approval matrix that changes shape above a value threshold. The tolerance on a match, and what happens outside it. Dual control on a bank master data change. The authorisation model that decides whether a role can post at all, and to which company codes. The exception queue somebody works every morning. The report that reconciles what one system believes against what another one holds.

None of that is in the ERP because the ERP is clever. It is there because at some point someone acted alone, or twice, or on the wrong entity, and the organisation wrote down a rule so it would not happen again. That is why the shape of that layer can be described without knowing your company: it is the accumulated scar tissue of everything that has ever gone wrong.

An AI capability arriving into that landscape does not get to skip it. It gets asked the same questions the layer asks everything else, and if the answers do not exist, the honest position is that the capability is not ready — which is the applied version of the argument that [enterprise AI is an architecture problem before it is a model problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem).

## Three layers, not two

The design most teams reach for has two layers. Systems of record at the bottom, AI at the top, credentials in between. The AI reasons, the systems hold state, and the connection is whatever access someone provisioned during the pilot.

The design that survives contact with an audit has three:

- **The systems of record** hold state and remain authoritative. They are the only place anything is true.
- **The AI or agent layer** reasons. It interprets unstructured input, classifies, drafts, proposes, explains. It is good at exactly the things rules are bad at, and it holds no authority.
- **The control layer** sits between them and decides whether anything from the second is allowed to reach the first — in what form, under whose identity, within what limits, with whose approval, and with what left behind in the log.

The third layer exists in the two-layer design too. It has simply been implemented as a paragraph of prompt text and a broadly-scoped service account, which is a control layer in the same sense that a note on a door is a lock.

## What the control layer owns

| Concern | The question it answers | What breaks without it |
| --- | --- | --- |
| **Identity** | Who is this action attributable to? | Everything lands as a shared technical user; nobody is accountable and nothing is revocable |
| **Permissions** | What may it touch? | Blast radius becomes whatever the credentials happen to reach |
| **Deterministic rules** | Which logic must never be re-derived by a model? | Arithmetic and policy become probabilistic and stop being reproducible |
| **Thresholds** | Above what value or volume does the treatment change? | A trivial item and a material one get handled identically |
| **Policy** | What standing rules constrain this at all? | Policy lives only in a document nobody enforces |
| **Approval requirements** | What needs a named human before it happens? | Approvals become optional and are discovered afterwards, from the log |
| **Segregation of duties** | May the same identity propose and dispose? | The oldest control in finance is broken quietly, by convenience |
| **Output validation** | Is this well-formed and semantically plausible? | Malformed or confidently wrong output flows downstream as if it were valid |
| **Action limits** | How much may it do, per run and per window? | One bad loop executes at machine speed until someone notices |
| **Logging** | Can a single action be reconstructed months later? | The capability is trusted exactly until someone asks a hard question |
| **Kill switch** | Can we stop it in a minute, without a deployment? | Incident response becomes a code change under pressure |
| **Exception routing** | Where does anything it cannot handle actually go? | Exceptions become a confident guess, or disappear |

Four of those deserve more than a row.

**Deterministic rules and thresholds.** The strongest instinct to resist is letting the model do work that a rule already does correctly. If the calculation is defined, calculate it. If the policy says approval is required above a value, the control layer evaluates that comparison — it does not ask the model whether approval seems necessary. A model asked to apply a rule will usually apply it. "Usually" is not a control standard, and it is not a standard you can evidence to anyone. Give the model the work that is genuinely ambiguous, and give the rules the work that is genuinely rules.

**Action limits.** This is the control most often missing, because in a human process it was never needed. A person could only process so many items before going home. An agent has no such property. Limits on how many actions per run, how much cumulative value per window, and how many consecutive failures before it stops are not caution — they are the thing that turns a bad afternoon into a small bad afternoon.

**The kill switch.** It has to be operable by whoever is on call at the time, in seconds, without a release. Not a feature flag that requires a deployment, and not "we'll revoke the credential" if nobody on the rota knows how. A stop control that has never been tested is a plan, not a control.

**Exception routing.** Every capability meets input it should not act on. The design question is whether that produces a routed exception with the evidence attached and an owner, or a confident answer produced anyway. The second one is the failure mode worth designing against first, because it is silent — nothing errored, an output arrived, and the fact that the system was guessing is visible only in a log nobody read. This is the same [output contract and failure-handling discipline](https://gravam.com/blog/ai-output-contracts-and-failure-handling) applied at the boundary where actions become real.

## An instruction is not a control

This is the sentence I would put above the whole architecture.

A control has two properties that prompt text cannot supply. It is enforced by something that cannot be persuaded, and it fails closed when it is unsure. Prompt text has neither. It is input to a probabilistic process, which means it can be outweighed by other input, reinterpreted under a case nobody anticipated, or quietly weakened when someone edits the prompt for an unrelated reason and does not realise a control was living in paragraph four.

There is also a testing argument, and I find it more persuasive than the philosophical one. You can write a test for a threshold. You can write a test for an authorisation. You cannot write a test for a sentence — only a sample, which tells you the model complied on the cases you tried.

> A control that lives in a prompt is a control the model can be talked out of.

So write the rule in the prompt if it helps the model behave well. Then enforce it somewhere the model does not get a vote.

## Enforce it twice, in two different places

Controls belong in the control layer and in the target system, because the two know different things.

The control layer knows intent and context. Which user asked. What the agent proposed and why. Which policy applies. Whether a threshold was crossed. Whether an approval exists and who gave it. It can stop an action early, explain the refusal in business terms, and route it somewhere useful.

The target system knows none of that, and it is still the more important gate — because it is the last one before state changes, and it holds whether or not your control layer was reached. If someone connects a second client to the same credential, calls the interface directly, or misconfigures a route during a busy release, the target system's own authorisation model is the only thing still standing.

That is not redundancy for its own sake. It is the reason a scope defined in the control layer must also exist as a real, narrow authorisation in the system being written to, which is exactly the question that [where an agent sits relative to your existing systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems) forces you to answer.

## The division of labour

Underneath all of this is one principle, and it is worth stating plainly because every decision above is an application of it.

**Models reason. Rules constrain. Systems hold state. Humans own consequential decisions.** The workflow-level version of that split is [the anatomy of an AI-native workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow).

Most trouble in AI designs comes from moving a responsibility across one of those boundaries. A model asked to constrain — to be its own guardrail, when the [security boundaries for enterprise AI agents](https://gravam.com/blog/enterprise-ai-agent-security-boundaries) have to sit outside it. A rule engine asked to interpret an ambiguous email. State held in a conversation instead of a system, so nobody can query it or reconcile it. And, most expensively, a consequential decision handed to a component that cannot be accountable for it, which is really a decision about [automation, augmentation and autonomy](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy) taken by default rather than on purpose.

The control layer is where that division is made concrete. It is the component that keeps the model in the reasoning business.

## Designing it on purpose

A few things I would hold to when building one.

Make it a real component with an owner, not a set of habits distributed across whoever wrote each integration. If the answer to "where is the approval requirement enforced" is three different files, it is not a layer.

Give actions one choke point. Every write, every external side effect, every irreversible thing goes through the same place. Convenience shortcuts around the layer are how it stops being one, and they are always added for a good reason at the time.

Version it like configuration and test it like code. Thresholds change, policies change, scopes change — and each of those is a functional change that someone should be able to find later.

Log at the grain of a single action, not the grain of a dashboard. Aggregates cannot answer the only question that ever actually gets asked, which is about one specific record on one specific day. Done properly, this is also the raw material for [production observability](https://gravam.com/blog/production-ai-observability), and the two are cheaper to build together than separately. What it is not, on its own, is audit evidence: the record an auditor relies on is the one the system of record writes, and [the agent's log only earns its place by reconciling to it](https://gravam.com/blog/ai-agent-logs-are-not-an-audit-trail).

And make identity the first decision rather than the last, because almost every other control in the layer resolves to it — which is why [what the agent is acting as](https://gravam.com/blog/agent-identity-and-permissions) deserves a design conversation of its own.

## Building the layer that owns AI safety

Stop trying to buy safety in the model and build the layer that owns it. Name the three layers explicitly so the middle one exists on the diagram rather than in the prompt. Put identity, permissions, deterministic rules, thresholds, approvals, segregation of duties, validation, limits, logging, a stop control and an exception route in it, and for each one, be able to say what breaks if it is missing. Enforce twice — once where you know why, once where it counts. Never let a control live only in prompt text. And keep the model doing the thing it is genuinely good at, which is reasoning about ambiguity, not policing itself.

None of this is new. That is rather the point: the enterprise worked out how to constrain powerful, fallible actors long before it had this one, and the answer is not a better actor. It is a layer. It is also, increasingly, what regulation asks for in its own vocabulary — the [EU AI Act's high-risk requirements](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems) are largely a description of this layer, written by lawyers, and the voluntary version says the same thing in four functions and nineteen categories: [the NIST AI Risk Management Framework](https://gravam.com/blog/nist-ai-rmf-functions-and-categories).

***

_See also [agent identity: who is the AI acting as?](https://gravam.com/blog/agent-identity-and-permissions) and [why enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem)._

## Primary sources

The one external claim — that the NIST AI RMF Core has four functions and nineteen categories — verified against NIST AI 100-1 and the NIST AIRC Core page (GOVERN 6, MAP 5, MEASURE 4, MANAGE 4). The rest of the article is design argument, not sourced fact.

- NIST AI 100-1 — Artificial Intelligence Risk Management Framework (AI RMF 1.0) — accessed 2026-09-04 — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
- NIST AI Resource Center — AI RMF Core (the four functions and their categories) — accessed 2026-09-04 — https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

## Questions this article answers

**Q: What is an enterprise AI control layer?**

An enterprise AI control layer is the component that sits between the AI or agent layer and the systems that hold the company's state, and decides whether anything the AI produces is allowed to become an action. It owns identity, permissions, the deterministic rules and thresholds that must not be re-derived probabilistically, policy, approval requirements, segregation of duties, output validation, limits on how much may be done in a window, logging, a stop control, and the route for anything it cannot handle. Almost every enterprise already has this layer around its ERP postings and payment releases. AI does not get an exemption from it.

**Q: Why can't AI safety rules live in the system prompt?**

Because an instruction is not a control. A control has two properties a prompt cannot supply: it is enforced by something that cannot be persuaded, and it fails closed when it is unsure. Prompt text is input to a probabilistic process, so it can be outweighed by other input, reinterpreted under an unusual case, or quietly weakened when someone edits the prompt for an unrelated reason. Rules in a prompt also cannot be tested the way a threshold can. Write the rule in the prompt if it helps the model behave, but enforce it somewhere the model does not get a vote.

**Q: Where should an AI control be enforced — in the control layer or the target system?**

Both — the control layer and the target system know different things. The control layer knows intent and context: which user asked, what the agent proposed, what the policy says, whether a threshold was crossed, whether an approval exists. The target system knows nothing about any of that, but it is the last gate before state actually changes, and its own authorisation model is the only thing still standing if the control layer is bypassed or misconfigured. Enforce in the control layer so bad actions are stopped early and explained, and in the target system so they are stopped at all.

---

# How AI Agents Fit Into Existing Enterprise Systems

Source: https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-18
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: The four placements an AI agent can take beside your existing systems — read-only, propose-and-queue, scoped write, orchestrator — and what each one demands.

**An AI agent fits into an existing landscape in one of four placements — reading beside the systems, proposing an action a named person approves, writing a defined class of object under its own identity, or orchestrating steps across several systems — and the placement, not the model, decides what has to be true before it goes live.** Most designs belong lower on that list than they start on, and the expensive mistake is not choosing the wrong placement but never choosing one.

The usual pitch is that an agent slots into your organisation like a new joiner: give it access, point it at the work, let it get on with it. That is wrong in an instructive way. A new joiner arrives into a structure that already knows how to contain them — a role with defined authorisations, an approval chain above them, a manager accountable for their output, and a probation period during which nobody hands them the payment run. An agent arrives with none of that unless you design it, and the default in most landscapes is not "restricted" but "whatever the credentials we gave it can reach."

So the practical question is not whether to use agents. It is where an agent sits relative to the systems that already run the business, and what has to be true before it is allowed to sit somewhere more powerful. This is the applied half of the argument that [enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem).

## Four placements, not one

Agent designs resolve to one of four positions relative to the existing landscape. They form a ladder — in blast radius, not in maturity, unlike [the three modes](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy), where climbing is not the goal — and the rungs differ enormously in what they demand.

| Placement | What it does | Blast radius |
| --- | --- | --- |
| **Read-only beside** | Reads, analyses, drafts; a human acts | A wrong answer someone acts on |
| **Propose & queue** | Prepares an action; a named person approves | A bad proposal that passes a tired reviewer |
| **Scoped write** | Writes a defined class of objects, under its own ID | Wrong data in a system of record, at volume |
| **Orchestrator** | Coordinates steps across several systems | Partial completion across systems, mid-chain |

The mistake is not picking the wrong rung. It is not picking at all — connecting an agent to whatever credentials were available and discovering its placement afterwards, from the audit log. Where that goes wrong most expensively is the ERP, which is why [connecting an agent to it directly](https://gravam.com/blog/connecting-ai-agents-to-your-erp) deserves its own answer.

## Read-only beside the systems

The agent reads across systems and produces something a human uses: a summary, a comparison, a flagged exception list, a draft. It changes nothing.

This placement is underrated, because a great deal of enterprise pain is not "the action was hard" but "assembling the picture took three days." It is also where the risk is genuinely lower — though not zero, and the way it is not zero surprises people. A read-only agent can still read data nobody intended to expose to it. Point one at a document store or a shared drive and it will happily surface a salary schedule, an unannounced deal, or a personal file to whoever asks, because the agent has no concept of "you can technically open this but you shouldn't." The permission model of most enterprise content was designed on the assumption that a human would have to know where to look. An agent removes that assumption entirely.

So even at the safest rung, the design work is real: scope what it can see, not just what it can do, and check that scope against the question "who is asking?" rather than only "what did we connect?"

## Propose and queue

The agent prepares the work and a named human approves it. Everything the agent produces lands in a queue with the proposal, the reasoning, and the evidence it used.

This is the placement to reach for by default, because it maps onto a control structure the enterprise already has. Four-eyes approval, maker-checker, release strategies — these exist in finance systems precisely because someone once acted alone and it went badly. An agent as the maker and a person as the checker fits an established shape rather than fighting it, and it keeps the [decision with the human while the execution goes to the machine](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows).

Its characteristic failure is rubber-stamping. If the queue is long, the proposals are usually right, and the approve button is one click, approval degrades into acknowledgement within weeks. That is a design problem, not a discipline problem, and it has design answers: surface what changed rather than the whole object, make the agent state its confidence and its evidence, sample-audit approved items against what actually happened, and watch approval time as a metric — when median review time collapses, the control has quietly stopped existing.

## Scoped write, under its own identity

The agent writes directly, for a defined class of actions, under an identity that belongs to it alone.

Two things make this survivable. The first is scope enforced where it counts: the agent's authorisations in the target system permit exactly the objects it needs and nothing adjacent. A prompt that says "only update draft records" is not a control. An authorisation that only permits draft records is. The second is that the identity is its own, so every action attributes to it and the trail is legible — and so that revoking it stops the agent without stopping four other integrations sharing the same technical user.

> An agent's blast radius is not what it usually does — it is the worst thing its credentials permit on the day its judgement is wrong.

The concrete failure I would design against first is duplication. An agent that can post, retrying against a target that cannot recognise a repeat, will eventually do the same thing twice: a timeout after the target committed, a retry, two records. Agents make this sharper than ordinary interfaces because they retry eagerly and can reword the same intent, so naive duplicate checks slide right past it. Before a write placement is allowed, the target has to honour an idempotency key or the agent has to check before it writes — and somebody has to have tested that by actually forcing a timeout, not by reading the documentation.

## Orchestrating across systems

The agent coordinates a sequence spanning several systems: read here, decide, write there, trigger something else, confirm.

This is where the value is, and it is also where enterprise integration has always been hardest, for a reason that has nothing to do with AI: there is no transaction spanning your ERP, your bank, and the third system. Step two succeeds, step three fails, and you are left in a state no single system considers invalid but the business does. Every landscape I have worked in had scars from exactly this, and the answers are the old ones — compensating actions, a saga-style unwind, a reconciliation that catches half-finished chains, and an explicit decision about what "partially done" means for each sequence.

An agent does not make this easier. It makes partial completion more likely, because it will attempt more sequences per day than any human process did, and it will attempt them at times when nobody is watching. An orchestrating agent without a defined unwind is not an automation; it is a generator of states your support team has never seen.

## Earning the next rung

Placements should move up on evidence, not on enthusiasm. The criteria I would hold to before promoting an agent one rung:

1. **Its outputs have been measured, not admired.** A held-out set of real cases, scored — the same discipline as [evaluation and regression testing](https://gravam.com/blog/ai-evaluation-and-regression-testing) — so "it's been good" is a number rather than an impression.
2. **The scope exists in the target system.** The authorisations are cut, tested, and confirmed to block what they claim to block. Verified by trying, not by reading the role definition.
3. **Idempotency and reversal are proven.** You have forced a duplicate and watched it be rejected, and you know how a wrong action gets undone.
4. **The observability is in place first.** Logging, sampling and alerting exist before the write does, because [you cannot supervise what you cannot see](https://gravam.com/blog/production-ai-observability) and after an incident is a poor time to start.
5. **Someone is named.** A person accountable for the agent's output, who would be accountable if a human had done it.

Fail any one of these and the agent stays where it is. That is not caution for its own sake; it is the same gate a change of this consequence would face in any [well-run intake and delivery process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams), applied to a component that happens to be probabilistic.

## Choosing where an agent sits, deliberately

Choose the placement deliberately and write it down, because an unchosen placement defaults to whatever access was convenient. Start read-only and scope what the agent can see as carefully as what it can do. Use propose-and-queue for anything consequential — it fits the four-eyes control the organisation already runs on — and then watch the approval step for the moment it turns into a rubber stamp. Grant a scoped write only under a dedicated identity, only where the target is idempotent, and only where you can undo a bad day. Treat orchestration as the hardest rung, not the obvious next one, and define what happens when a chain stops halfway. The agent's capability is rarely the constraint. Its placement is, and that is the part you control.

***

_See also [why enterprise AI is an architecture problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem), [AI output contracts and failure handling](https://gravam.com/blog/ai-output-contracts-and-failure-handling), and the question every placement above depends on: [who is the agent acting as](https://gravam.com/blog/agent-identity-and-permissions)._

## Questions this article answers

**Q: Where should an AI agent sit relative to the systems of record?**

Alongside them, at the lowest placement that still delivers the value. There are four practical positions: read-only beside the systems, producing analysis a human acts on; propose-and-queue, where the agent drafts an action and a named person approves it; write-through under a narrowly scoped identity for a defined class of low-consequence actions; and orchestrator, coordinating steps across several systems. Each step up multiplies both the value and the blast radius, so the placement should be an explicit design decision with named criteria for moving up — never something a capability drifts into because it was already connected.

**Q: What access should an AI agent be granted in an enterprise system?**

The narrowest set that lets it do the one job it was built for, enforced by the target system's own authorisation model rather than by instructions in a prompt. In practice that means a dedicated identity per agent and purpose, an explicit list of objects it may read and a shorter list it may change, and no combination of rights that lets the same identity both create and approve. Access granted for convenience during a pilot is the access it will still hold in production, so scope it as if it were permanent, because it usually is.

**Q: Why do AI agent retries duplicate work in enterprise systems?**

Because a retry is only safe if the receiving system can recognise a repeat, and many enterprise interfaces cannot. When a call times out after the target has already committed but before the response arrives, the agent sees a failure and tries again — and the target, having no way to know it is the same instruction, does the work twice. Agents make this worse than ordinary integrations because they retry eagerly and can reword the same intent, so simple duplicate detection misses it. The fix is an idempotency key the target honours, or a check-before-write, decided before the agent is allowed to write at all.

---

# Why Enterprise AI Is an Architecture Problem

Source: https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-08-18
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: Enterprise AI stalls on architecture, not model quality: who owns the record, what the AI may write, under whose identity, and how it is logged and rolled back.

**Enterprise AI is an architecture problem because what decides whether a capability ships is never the model: it is which system owns the data it reads, what it may write, under whose identity, what it does when a dependency is unavailable, and whether anyone can reconstruct the chain six months later.** Those are the questions a landscape asks, and none of them gets easier with a better model.

The common framing is the opposite — a model question: which one, how good is it, how does it score. That framing survives about a week past the pilot. In enterprise systems work — SAP, finance, treasury, the programmes where a mistake shows up on a bank statement — I have never seen model quality decide whether a capability shipped. What decides it is the layer underneath — and of the five questions above, the last one bites hardest: a controller asks six months later why a record changed, and nobody in the room can answer.

That is the same problem I have spent a career on: getting systems that were never designed to talk to each other to agree on what is true.

## Nobody deploys onto a blank page

The demo is always built against a clean surface. A prompt, a file, a plausible answer. The enterprise version of the same capability has to land in a landscape that already exists — an ERP with twenty years of configuration in it, a scheduling layer, an identity provider, an interface estate, a change process, and a set of controls that predate everyone in the room.

Every one of those is a constraint the demo never met. The capability does not get to define where the data lives; the landscape already decided. It does not get to invent an approval; there is one, and it has an owner. The real design work is not building the AI part. It is deciding where the AI part sits relative to everything that was already there, which is precisely the question the [enterprise AI systems](https://gravam.com/topics/enterprise-ai-systems) layer exists to answer.

## Which system owns the record

The first question I ask of any AI capability is the oldest question in integration: what is the system of record here, and is the AI reading it or reading a copy of it?

This is not pedantry. A [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system) and an ERP can both hold what looks like the same balance, and they are authoritative for different things. An AI reading the convenient copy — the extract, the warehouse table, the export somebody set up years ago for a report — will confidently answer from data that is a day stale, filtered, or scoped to a subset nobody documented. The answer looks right. It is wrong in a way that no amount of model capability can detect, because the model has no way of knowing what it was not given.

So ownership gets named before anything else: one authoritative source per data domain, the AI reads that or reads a copy whose staleness is known and stated, and nothing the AI produces becomes a second competing version of the truth.

## What it may write, and as whom

Reading is the easy half. The moment a capability can write, two questions become load-bearing at once.

The first is scope: exactly which objects may it create or change, and which may it only read? "It has access to the system" is not a scope. A scope is a list, it is narrow, and it is enforced by the target system's own authorisation model rather than by an instruction in a prompt. Anything enforced only in the prompt is not a control — it is a suggestion the model is free to reinterpret.

The second is [identity: under whose account does the write happen](https://gravam.com/blog/agent-identity-and-permissions)? An action attributed to a shared technical user is an action nobody is accountable for. It also breaks segregation of duties quietly, because a service identity broad enough to be convenient is usually broad enough to both create and approve — which is the exact combination the control was written to prevent. If a person is meant to be accountable for the outcome, the trail has to lead to that person, not to a service account with a name like `AI_INTEGRATION`.

> You can swap the model in an afternoon; you cannot swap the decision about which system owns the record, because by the time you want to, a hundred other things depend on the answer.

## The interesting failures happen between systems

Here is the part that makes this familiar rather than novel. Everything I learned building interfaces applies again, unchanged.

Retries duplicate work unless the receiving end is idempotent. If the AI's action is "post this" and the call times out after the target committed but before the response came back, a retry posts it twice — and an agent that retries eagerly is a duplicate-generation machine pointed at a system that keeps score. The fix is the same as it always was: an idempotency key the target honours, or a check-before-write, or both. It is not a model setting.

Rate limits, throttling and batch windows still exist. An AI that generates work faster than the downstream system accepts it does not fail loudly; it queues, backs up, and then floods the moment the window opens.

Reconciliation is still the only proof. Whatever the AI did, something has to compare what it believes it did against what the systems actually hold, on a cadence, with a break report that a human reads. Without that, the first time you learn the two disagree is when someone downstream notices the number is odd.

None of that is AI-specific. It is what you already do between an ERP and a bank, or between a forecasting process and the ledger. AI does not exempt you from it. It raises the volume, and it removes the natural rate limit that a human doing the work used to provide.

## The day something upstream is unavailable

Enterprise systems go down, get patched, run month-end, and lock. The design question is what the AI capability does during those hours, and there are only a few honest answers: it waits and resumes, it queues and replays safely, or it stops and tells someone.

The dishonest answer — the one that ships by accident — is that it proceeds on partial data and produces a confident output anyway. That is the failure worth designing against explicitly, and it is [the control layer's exception route](https://gravam.com/blog/the-enterprise-ai-control-layer) that has to catch it. The same [output contract and failure-handling discipline](https://gravam.com/blog/ai-output-contracts-and-failure-handling) that keeps a product honest applies here with more at stake, because the consumer is not a user who can shrug — it is a downstream process that will act on it.

## Versioning, and the way back

Every enterprise system I have worked on had an answer to "how do we undo this." Transport paths, change records, a defined rollback, an environment where you saw it work first.

An AI capability needs the same answers, and the moving parts are unusual. A prompt change is a functional change. A model version change is a functional change — one you may not have initiated, which is the genuinely new problem: the behaviour of a component can shift without a change record on your side. That is why [prompts and model versions belong under version control](https://gravam.com/blog/prompt-and-model-versioning) with the same seriousness as configuration, and why the environment path matters as much for AI as for anything else: you should have seen this exact prompt, against this exact model, on this data shape, somewhere that was not production.

The rollback question is the sharp one. If a prompt change caused a week of subtly wrong outputs, can you identify which outputs, and can you reverse them? For a read-only capability the answer is "regenerate." For a writing capability, it is a data-correction exercise — which is a very different conversation, and one worth having before you grant the write, not after.

## Logging for a question asked later

The logging standard in enterprise work is not "we have logs." It is that someone can reconstruct a specific transaction months later, without you in the room.

Applied to an AI capability, that means recording the request, the proposal, the action actually taken, the identity used, the downstream response, and the prompt and model versions behind it. Get that right and you have something better than an audit trail — you have [production observability](https://gravam.com/blog/production-ai-observability), the thing that turns "it seems worse lately" into a number you can point at. Get it wrong and you have a capability that is trusted exactly as long as nobody asks a hard question about it.

## Where the architecture effort should go

Treat the model as the most replaceable part of the design and spend your architecture effort on everything else. Name the system of record before you build anything. Keep the AI read-only until write scope, identity and reversal are all decided, and enforce scope in the target system rather than in a prompt. Assume retries, so demand idempotency. Reconcile on a cadence and let a human read the breaks. Version prompts and models like configuration, and know your way back. Then decide, deliberately, [where the agent actually sits relative to your existing systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems) — because that placement, not the model, is what determines how much damage a bad day can do.

***

_See also [how AI agents fit into existing enterprise systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems), [production AI observability](https://gravam.com/blog/production-ai-observability), and the layer this argument is really about: [the enterprise AI control layer](https://gravam.com/blog/the-enterprise-ai-control-layer)._

## Questions this article answers

**Q: Why is enterprise AI an architecture problem rather than a model problem?**

Because the model is the most replaceable component in the design and everything around it is not. Model quality decides whether a demo impresses; architecture decides whether the capability can run against systems that already hold the company's money, contracts and master data. The questions that actually gate a rollout are which system owns the data, what the AI is permitted to write and under whose identity, how its actions are logged and reconciled, how it behaves when a system it depends on is unavailable, and how a bad change is rolled back. None of those are answered by choosing a better model.

**Q: What has to be decided before an AI capability touches a system of record?**

Four things, explicitly and in writing. First, ownership: which system holds the authoritative version of the data, and whether the AI is reading a master or a copy. Second, write scope: exactly which objects it may create or change, and which it may only read. Third, identity: the account the write happens under, so the action attributes to something a person is accountable for rather than to a shared technical user. Fourth, reversal: how a wrong action is detected and undone. If any of the four is undecided, the capability is not ready to write.

**Q: How should AI actions be logged in an enterprise landscape?**

Well enough that someone can reconstruct a specific action months later without your help. In practice that means recording what was requested, what the AI proposed, what it actually did, which identity it used, which downstream system accepted it, and which version of the prompt and model produced the result. The test is not whether a log exists but whether it answers the question an auditor or a controller will actually ask — why did this record change, on whose authority, and can you show me the same decision made twice the same way.

---

# Production AI Observability in the Enterprise

Source: https://gravam.com/blog/production-ai-observability
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-07-28
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: You can't fix what you can't see. How to observe AI running inside an enterprise — quality, cost, latency, drift and failures — as data, not complaints.

**An AI step can return a valid response, on time, with no error — and be completely wrong, or quietly costing three times what it did last week.** That is the thing normal monitoring misses. The uptime dashboard says green, every request is a clean 200, and meanwhile output quality has drifted, a model update changed the behaviour, or a prompt edit doubled the token cost. In a database-backed system, "it returned successfully" mostly means "it worked." With a model in the path, success and correctness are different signals — and if you only watch the first, the operations team is your quality monitoring, finding out by working the exceptions.

## Success is not correctness

Start from the failure that makes AI observability different: **a call can succeed and still fail.** A confidently wrong answer, a subtly-off summary, an output that no longer parses the way the receiving system expects — all of these return 200. Standard monitoring (errors, latency, uptime) is necessary and completely blind to them.

So AI observability is two layers: the normal one (is it up, fast, erroring?) plus an AI-specific one (is it **good**, is it **drifting**, is it **costing what it should**?). The second layer is the one pilots skip and production cannot afford to — it is a big part of [why so many AI apps feel like demos](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems): they are monitored like static systems, so quality degrades invisibly.

## The six things worth watching

| Dimension | The question | Why it is silent without monitoring |
| --- | --- | --- |
| **Quality** | Are outputs still good? | A wrong answer returns 200 like a right one |
| **Cost** | Tokens/spend per call and per user? | A cost regression bills you, not errors |
| **Latency** | How slow, how variable? | Slow AND correct is still a bad experience |
| **Failures/fallbacks** | How often do calls error, retry, or fall back? | A fallback firing constantly hides a real problem |
| **Drift** | Are outputs changing over time? | Your edit — or a model update — shifts behaviour quietly |
| **Usage** | Which steps are actually used? | You cannot prioritise monitoring blind |

The two most-neglected are **quality** and **cost**, precisely because neither shows up in error rates. Cost ties straight to [unit economics](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow) — the same arithmetic decides whether a capability is affordable at real volume, and a monitoring gap here is a margin leak you meet on an invoice. Quality ties to your evals — which is the only practical way to monitor it at all.

Which of the six matters most depends on where the model sits in the flow. Mapping that first — [what the workflow looks like end to end](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow) — shows which step's degradation would reach a system of record. Instrument that step hardest.

> The AI failures that hurt most are the ones that return 200. If your monitoring only knows "up or down," it is blind to every failure that matters — cost, drift and quality all degrade with a perfectly healthy status code.

## Monitoring quality: sample and score

Quality is the hard one, because there is no status code for "good." The practical approach is the same discipline as pre-ship [evals](https://gravam.com/blog/ai-evaluation-and-regression-testing), pointed at production:

1. **Log inputs and outputs** — enough to reproduce a bad result later (with real care about privacy and personal data; log what you need, not everything, and keep it where that data class is allowed to live).
2. **Sample** a slice of real traffic regularly — you do not score every call, you score enough to see a trend.
3. **Score** the sample against your defined "good" — the same criteria your [eval set](https://gravam.com/blog/ai-evaluation-and-regression-testing) uses.
4. **Watch the number.** A drop in the score is a quality regression, visible as data before it is visible as rework.

The key point: you already built the "good" definition for your evals; production quality monitoring is that same definition, run on live samples instead of a fixed test set. Build the eval once, use it twice.

## Log for the question you will be asked

There is a second reason to log in a controlled environment, and it is not monitoring. Sooner or later someone asks about one specific record: why did this change, on whose authority, and would the same input produce the same result today? That means holding the request, what the model proposed, what was actually done, the identity it ran under, and the prompt and model versions behind it. Aggregate dashboards cannot reconstruct a single decision, and a single decision is what gets asked about. Even at that grain, a log the AI layer writes about itself is its own account rather than independent evidence, which is why [an agent's logs are not an audit trail](https://gravam.com/blog/ai-agent-logs-are-not-an-audit-trail) until they are reconciled to what the system of record recorded.

## Drift: your behaviour changes when you did not

Drift deserves its own attention because it is the failure that happens while nobody did anything. A [model update](https://gravam.com/blog/prompt-and-model-versioning) from the provider, a deprecated version, a silent change behind an alias — any of these can shift behaviour under you, and without observability the first anyone hears of it is someone downstream noticing. Monitoring outputs over time turns "the model changed" into a chart: a shift in the quality score, cost or output shape that you investigate deliberately instead of meeting as an incident.

## Failures and fallbacks: watch the safety net

If you built [fallbacks](https://gravam.com/blog/ai-output-contracts-and-failure-handling) — and you should — you have to watch how often they fire. A fallback path is a safety net, and a net catching things constantly means something upstream is broken. The trap is that fallbacks make failures **invisible** by design: the process still completes, so nothing looks wrong, while the primary path fails silently behind it. Monitor fallback rate as its own signal, with an owner and a threshold, or the safety net becomes a blindfold.

## Keep it proportionate

None of this has to be heavy, and it should not start heavy. The same instinct applies as measuring only the few things that change a decision: scale the rigour to what the step can affect. A minimal, honest setup is logging inputs, outputs, cost and latency, a periodic sampled quality score against your evals, and an alert on cost and fallback rate with a named recipient. That is enough to catch the failures that return 200. A platform can come later; the mistake is not a simple setup, it is having **none** and calling green uptime "monitoring."

## What I would monitor in the AI layer

Monitor the AI layer separately from the application layer, because success and correctness are different signals and only one has a status code. Reuse the eval definition to sample-score production quality — build the "good" once, run it live. Log at the grain of a single decision, because that is the grain someone will ask about. Watch cost and fallback rate as first-class alerts, since both fail silently while every request looks healthy. And keep it proportionate: the goal is not a monitoring cathedral, it is that when an AI step degrades — in quality, cost or behaviour — you find out from a number rather than from whoever had to clean up after it.

***

_See also [prompt & model versioning](https://gravam.com/blog/prompt-and-model-versioning), [how to measure ROI from an AI workflow](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow), and why, in an enterprise landscape, [this is an architecture problem before it is a model problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem)._

## Questions this article answers

**Q: What is AI observability in production?**

AI observability is being able to see what your AI features are actually doing in production — the quality of outputs, the cost and latency per call, whether behaviour is drifting, and how often things fail or fall back — so problems surface as data you can act on rather than as complaints from the people downstream. It is the AI-shaped extension of normal application monitoring: you still watch errors and latency, but you also watch things a database-backed system never has, like output quality and cost-per-call, because those are exactly the things that can degrade silently while every request still returns a 200. Without it, the operations team is your monitoring, and they find out by working the exceptions.

**Q: What should you monitor for an AI feature?**

Six things: quality (are outputs still good, sampled and scored against your evals), cost (tokens and spend per call and per user, so a cost regression is visible immediately), latency (AI calls are slow and variable, and slow is a quality problem), failures and fallbacks (how often calls error, retry or hit a fallback path), drift (whether outputs are changing over time, from your own edits or a model update), and usage (which features are used, so you know what to watch most). The point is that an AI feature can be failing on quality or bleeding money while returning perfectly valid responses — so the standard 'is it up?' monitoring misses exactly the failures that matter most.

**Q: How do you detect AI quality problems in production?**

By sampling real production outputs and scoring them — ideally against the same eval criteria you use before shipping — rather than waiting for someone downstream to complain. Log inputs and outputs (with privacy care), sample a slice regularly, and score them, so a drop in quality shows up as a falling number, not a rising exception queue. Two things make it work: logging enough to reproduce a bad output, and having a defined 'good' to score against. Quality is the hardest thing to monitor because it is not a 200-or-500 signal — a confidently wrong answer looks identical to a right one at the HTTP level, so you have to look at the content, not just the status code.

---

# AI Output Contracts and Failure Handling

Source: https://gravam.com/blog/ai-output-contracts-and-failure-handling
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-07-28
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: A model will return the wrong shape, or a confident lie. How to design output contracts, validation and fallbacks so an enterprise process fails safely.

**The model will fail. Not might — will: the wrong shape, an invented value, a confident answer that is simply wrong. The only question is what the process around it does when that happens.** Most AI features are built for the happy path — the demo where the model returns exactly what was hoped for — and have no considered answer for the response that is malformed, off-spec, or plausibly wrong. That is [why so many AI builds feel like demos](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems): the first weird output either breaks the feature or, worse, flows downstream as if it were valid. In an enterprise landscape, "downstream" is not a screen someone can shrug at. It is a posting, a payment run, a master data change, a queue somebody works on Monday. Designing the failure path as deliberately as the success path is most of what separates a capability that can go live from one that stays a pilot. Here is how I think about it.

## Treat the model's output as untrusted input

The mental shift: **the model's response is untrusted input, like a file from a third party or a form from a user.** No integration team takes an inbound file and posts it unvalidated — you check the format, the fields and the totals, and you have a defined behaviour for the day it arrives wrong. A model's output deserves at least that much suspicion, because it can be wrong in more ways than a file ever could: wrong shape, wrong values, wrong facts, or perfectly-formed nonsense.

So the boundary between "the model returned something" and "our systems act on it" needs a checkpoint. That checkpoint is the output contract.

## Output contracts: define what "valid" means

An output contract is the shape and constraints a response must satisfy to be usable: a schema, required fields, allowed values, bounds. It turns free-form text you hope to parse into a validated interface with a pass/fail. Three things it buys you:

- **A clean failure signal.** An off-spec response fails validation **at the boundary** instead of breaking three functions deep or, worse, being silently processed as valid.
- **A place to enforce constraints.** Not just "is it JSON" but "is this value in range, does this field exist, does this code resolve" — the semantic checks that catch a plausible-but-wrong output.
- **Something two teams can point at.** When the model side and the receiving system are owned by different people, the contract is what makes "the behaviour changed" a testable claim rather than an argument in a call.

The contract is also the thing that breaks silently when a [prompt or model changes](https://gravam.com/blog/prompt-and-model-versioning) — which is why it is worth versioning and validating, not assuming. A model update that shifts the output format should be caught by a failing contract, not discovered by whoever works the exception queue.

## The failure ladder: validate, retry, fall back, degrade

When the contract fails — and it will — you want a defined ladder, not an exception. Each rung is a more graceful response to a worse situation:

| Rung | When | What happens |
| --- | --- | --- |
| **Validate** | Every response | Check against the contract; pass → use it |
| **Retry** | Validation failed | Try again, often with a corrective instruction |
| **Fall back** | Retries exhausted | A simpler model, a cached/default result, a manual route |
| **Degrade** | No safe result possible | An honest "we could not do that," not a crash or a guess |

The rung people skip is **degrade** — the honest failure. When nothing works, the right answer is a clear, truthful "this did not work, and here is what was not done," routed to whoever needs to act on it. Not a spinner forever, not a silent skip, and above all not a fabricated result presented as real.

One rung applies to all of them in a controlled environment: **every step should leave a record.** Someone will eventually ask why a specific record was changed at 03:12 on a Tuesday, and "it retried and recovered" is only an answer if the retry was logged.

> The most dangerous AI output is not the one that errors — it is the confident wrong answer that looks exactly like a right one. Every part of failure handling exists to catch or bound that, because it is the failure that ships silently and is discovered by someone downstream.

## Hallucinations: contain, do not pretend

You cannot fully prevent a model inventing things, so you design so it does the least damage:

- **Constrain.** An output contract plus grounding data (the model works from **your** systems' data, not its memory) leaves less room to invent.
- **Validate what you can.** A cited source that does not exist, a value out of range, a reference that does not resolve — catch the checkable lies.
- **Keep a named person accountable for high stakes.** The model proposes and a person disposes — the same principle as [using AI without letting it decide](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows) — and the usual control holds: the identity that produces the proposal should not be the one that approves it. How much of this you need depends on where the capability sits, and [that placement question](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems) comes before the accuracy question.
- **Be honest about confidence.** Do not present every output as certain. An interface that signals "this is a proposal, check it" is both more truthful and more robust than one that implies the machine is always right.

## Never let the AI step sink the process around it

A structural rule worth stating plainly: **a failed AI call should never take down the process it sits in.** Isolate it — the enrichment fails, but the document still saves; the summary fails, but the case still routes; the model is unreachable, but the batch still completes and raises the untouched items as exceptions. The process degrades to its pre-AI baseline instead of breaking. This is ordinary resilience engineering, routinely forgotten for AI calls because they get bolted onto an existing flow as if they always succeed. The test is cheap: turn the model off and watch what the process does.

## Designing the failure path first

Design the failure path first, not last — treat the model's output as untrusted input and put a validated contract at the boundary. Build the ladder: validate, retry with correction, fall back to something safe, and degrade honestly when nothing works, because "we could not do that" beats a confident lie every time. Log each rung, because a control environment asks about one specific transaction, not about averages. Contain hallucinations instead of pretending they will not happen, and never let a failed AI call sink the process around it. The model failing is not the edge case — it is the case you build for, and doing it well is most of what makes an AI capability something an operations team will actually trust.

***

_See also [prompt & model versioning](https://gravam.com/blog/prompt-and-model-versioning) and [production AI observability](https://gravam.com/blog/production-ai-observability)._

## Questions this article answers

**Q: What is an output contract for an AI feature?**

An output contract is the defined shape and constraints the model's response must satisfy before the surrounding system may use it — a JSON schema, required fields, allowed values, length bounds. It turns the model's output from free-form text your code hopes to parse into a validated interface with a pass/fail check. The reason it matters is that a model will eventually return the wrong shape — an extra field, prose where you expected JSON, a value out of range — and without a contract that is validated, your code either fails or, worse, silently passes a malformed result into a system of record. With a contract, an off-spec response is caught at the boundary and handled, instead of flowing downstream as if it were valid.

**Q: How do you handle AI failures in a product?**

By assuming the model will fail and designing the failure path as deliberately as the success path. The layers are: validate the output against a contract so malformed responses are caught; retry (often with a corrective instruction) when validation fails; fall back to a safe alternative — a simpler model, a cached result, a defined manual route — when retries do not work; and never let a failed AI call take down the process around it. The goal is graceful degradation: when the AI part fails, the process does something sensible and honest rather than breaking or, worst of all, passing a confident wrong answer downstream as if it were correct.

**Q: How do you handle hallucinations in an AI product?**

You cannot fully prevent them, so you design so they do the least damage: constrain the model with an output contract and grounding data so there is less room to invent; validate what you can (a cited source that does not exist, a value out of range, an account that does not resolve); keep a named person accountable for high-stakes outputs rather than auto-acting on them; and be honest about confidence rather than presenting every answer as certain. The mindset is that a hallucination is a failure mode to contain, not an edge case to ignore — the dangerous version is the confident wrong answer that looks exactly like a right one, so the defences are about catching or bounding it, not pretending it will not happen.

---

# Enterprise AI Evaluation & Regression Testing

Source: https://gravam.com/blog/ai-evaluation-and-regression-testing
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-07-28
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: How to build eval sets for AI running inside an enterprise — cases, scoring, a regression gate — so a prompt or model change is judged on evidence, not vibes.

**"It feels better" is how AI features quietly get worse.** Someone tweaks a prompt, tries two or three examples, they look good, it ships — and the behaviour has just changed for every input nobody tried, some of it for the worse. That is the core reliability problem of building with models: the output space is huge, and eyeballing a handful of cases tells you almost nothing about the rest. Inside an enterprise it's also a governance problem, because "it looked better to me" is not evidence anyone can approve a change on. Evals are the answer, and they're the practice that most separates an AI capability a team can improve confidently from one nobody dares touch. [Prompt and model versioning](https://gravam.com/blog/prompt-and-model-versioning) gives you the safe way to change things; evals are how you know a change was actually an improvement. This is how I build them.

## Evals are a test suite for a fuzzy function

The reframe that makes evals click: an AI step is a function with a huge, fuzzy output space, and an eval set is its **test suite**. Same idea as code tests — known inputs, expected results, run on every change — adapted to the fact that "expected" is sometimes a rule and sometimes a judgement.

Once you hold that framing, the whole practice follows: build a representative set, define how to score it, run it on every change, and gate on the result. The payoff is the same as tests give code — the confidence to change things without breaking what worked, and something concrete to show whoever has to sign the change off.

## Building the set: cover three kinds of case

An eval set is only as good as its coverage. Three kinds of case earn their place:

| Case type | What it is | Why it matters |
| --- | --- | --- |
| **Normal** | The typical, happy-path inputs | The bulk of real volume — must stay good |
| **Edge** | Boundary, unusual-but-valid, tricky inputs | Where quality quietly degrades first |
| **Regression** | The exact inputs that have failed before | So a fixed bug can never silently come back |

The regression cases are the ones people skip and the ones that pay off most: **every incident becomes a new eval case.** A bad output someone reports isn't just fixed — it's added to the set, so any future change that would reintroduce it fails the eval. Over time the set becomes a memory of every way the capability has been wrong, and a standing guarantee it won't be that way again silently. That is also the most useful thing an incident review can produce: not an action item, a case.

Two practical notes. Cases should come from real volume rather than from what someone imagined in a workshop — the distribution of odd inputs is never what people expect. And the set inherits the classification of the data in it: if the cases carry real customer or transaction data, the eval set is production data and has to live where that data is allowed to live.

> Turn every incident into an eval case. Do that consistently and your eval set stops being a test suite and becomes institutional memory — a growing proof that the capability can't regress in any way it's failed before.

## Scoring: rule-based where you can, judgement where you must

Scoring is where evals live or die, and the rule is simple: **make as much rule-checkable as the task allows.**

- **Exact / rule-based** — for structured or right-answer outputs (a field, a classification, valid JSON against a schema). Cheap, deterministic, unarguable. This is the scoring you can fully trust.
- **Criteria / rubric** — for open-ended outputs, a defined rubric of what "good" means, applied by a person on a sample or by a model-as-judge (another model scoring against your rubric). More coverage, but more subjective — treat its numbers as directional, not absolute.

The design move that makes evals more reliable is _structuring the output so more of it is rule-checkable_ — the same instinct as an [output contract](https://gravam.com/blog/ai-output-contracts-and-failure-handling). If part of the response is a structured field, you can score that part exactly and reserve the fuzzy scoring for the genuinely open part. Deterministic scoring is the bedrock; build as much of your eval on it as the task permits.

## The regression gate: run on every change

An eval set that isn't run automatically is a good intention. The discipline is a **gate**: every change — prompt, settings, model version — runs the set against a known-good baseline, and a change that drops the score on cases that used to pass is a regression to investigate, not a release to ship.

This is exactly a code regression suite, applied to the model layer:

1. **Baseline.** The current eval score is the bar.
2. **Change.** Edit the prompt, or adopt a new model version.
3. **Run.** Score the whole set.
4. **Compare.** Improved, held, or regressed?
5. **Gate.** A regression doesn't ship until someone understands it.

Step 5 is the point. Without the gate, a "better" prompt that broke three edge cases reaches live before anyone notices — and the people downstream become your regression suite, reporting failures as rework. Attach the score to the change record while you're at it: it turns an approval from a judgement about the person making the change into a judgement about evidence. It's also what makes adopting a new model version _safe_ — you don't trust "it's newer, it's better," you run your evals and see whether it's better on _your_ tasks.

And the same evidence answers a bigger question. The measured exception rate on a step — how often it's wrong, and whether the wrongness is detectable — is what tells you whether that step is a candidate for [automation, augmentation or autonomy](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy). Without evals, that decision is an assertion.

## Keep it proportionate

None of this needs a platform, and the first version shouldn't be one. An eval set is a folder of cases in version control and a job that scores them — start with ten cases that matter and grow it every time something breaks. It's the same instinct as measuring only the few things that change a decision: the mistake isn't a small eval set, it's having none and shipping prompt changes on vibes. Ten real cases scored on every change beats a hundred nobody runs, and it beats a tooling selection that takes two quarters.

## Where I would start with an eval set

Build the eval set from the start, small, and grow it from real failures — every incident becomes a permanent case. Score as much as possible with rules, and structure outputs so you can; reserve subjective scoring for the genuinely open parts and treat its numbers as directional. Gate every change on the set, keep the score with the change record, and never let a regression ship unexamined — that gate is the whole value, because it's what lets a team change the capability without the people downstream discovering the breakage first. Evals turn "I think this is better" into "this scored better," and that single shift is what makes an AI capability something an organisation can improve with confidence instead of fear.

***

_See also [prompt & model versioning](https://gravam.com/blog/prompt-and-model-versioning) and [production AI observability](https://gravam.com/blog/production-ai-observability)._

## Questions this article answers

**Q: What is an AI eval dataset?**

An AI eval dataset is a curated set of representative inputs, each paired with an expected output or a scoring rule, that you run a prompt or model against to measure quality objectively — the AI equivalent of a test suite. Instead of eyeballing a few examples after a change, you run the whole set and get a score, so 'it feels better' becomes 'it scored higher.' A good eval set covers the normal cases, the edge cases, and the specific failures that have burned you before — every production incident becomes a new eval case, so it can never silently recur. It's the single practice that most separates an AI capability you can change confidently from one nobody dares touch.

**Q: How do you score AI outputs in an eval?**

By the strictest method the task allows. Exact-match or rule-based scoring is best where the output is structured or has a right answer (a field value, a classification, valid JSON) — it's cheap, deterministic and unarguable. For open-ended outputs, you fall back to criteria-based scoring: a rubric of what 'good' means, applied either by a human on a sample or by a model-as-judge (another model scoring against your rubric), each with trade-offs. The rule of thumb is to make as much of the output rule-checkable as you can — structure it so parts can be scored exactly — and reserve subjective scoring for the genuinely open parts, because deterministic scoring is the part of an eval you can actually trust without second-guessing.

**Q: What is regression testing for AI?**

Regression testing for AI is running your eval set on every change — a prompt edit, a settings change, a new model version — and comparing the score to the previous baseline, so a change that quietly breaks something is caught before it ships. It works exactly like code regression tests: you have a known-good baseline, and a change that drops the score on cases that used to pass is a regression to investigate, not a release to push. The gate is the discipline: a change that regresses the eval doesn't ship until someone understands why. Without it, the people downstream are your regression suite, and a 'better' prompt that broke three edge cases reaches them before you notice.

---

# Prompt & Model Versioning: Enterprise AI Governance

Source: https://gravam.com/blog/prompt-and-model-versioning
Topic: Enterprise AI Systems — https://gravam.com/topics/enterprise-ai-systems
Author: Tan Gravam
Published: 2026-07-28
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: A prompt is production code and a model is a dependency you don't control. How to version prompts, handle model changes and stop silent regressions.

**A prompt is production code, and the model behind it is a dependency you don't control. Most AI builds treat both like scratch notes — and it shows.** This is a big part of [why so many AI-built apps feel like demos](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems): the prompt lives in someone's dashboard, nobody can say which version is live, the model floats on whatever alias the SDK defaults to, and "testing" is trying three examples by hand. That's fine for a prototype and a slow-motion disaster for a capability other people's work depends on. Production AI needs the same governance as any other production system — adapted to the two things that make it different: prompts you author and a model you rent. Here's how I keep it from silently drifting.

## Two things change your output — and you own one of them

Every AI feature's behaviour is a product of two inputs:

1. **Your prompt** (and its settings) — which you write and control.
2. **The model** — which the provider controls and can change under you.

The failure mode is treating the first as casual and the second as fixed. It's the opposite: the prompt deserves the discipline of code, and the model deserves the wariness of an external dependency with its own release schedule. Get those two right and most "why did it suddenly get worse?" mysteries never happen.

## What to version — and why

"Versioning" is vague until you list what actually needs it. For an AI capability, the versioned unit is bigger than just the prompt text:

| What to version | Why it matters |
| --- | --- |
| **Prompt text** | The literal instructions — the core of the behaviour |
| **Model + version** | A different model (or version) is a different system |
| **Settings** | Temperature, max tokens, tools — they change output too |
| **Output contract** | The shape downstream code depends on (schema, fields) |
| **Eval dataset** | The bar you measure against — versioned with the prompt |

The one people forget is the **output contract**. If the receiving system parses the model's response, the _shape_ of that response is an interface between the model and everything after it — and a prompt or model change can break it silently, producing output that's still plausible prose but no longer parses. Pin the contract, validate against it, and fail loudly when it breaks rather than passing a malformed result downstream.

## Prompts are code: treat them like it

Concretely, that means:

- **The prompt lives in the codebase**, in version control, not only in a provider's dashboard where changes are untracked and un-reviewable.
- **Changes are deployed, not tweaked live.** A prompt edit is a change like any other — reviewed, versioned, releasable, reversible — and it travels the same path through non-production environments as anything else that alters behaviour.
- **You can always say which version is live**, who approved it, and how to roll back to the previous one in one step.

A prompt edited directly in production is an undocumented change to system behaviour, and no control environment has a friendly name for that. It's the same principle as [writing the ticket before doing the work](https://gravam.com/blog/decision-log-and-change-control) rather than hacking in the dark: the discipline that feels like overhead on day one is what lets a team move fast without breaking anyone on day one hundred.

## The model is a dependency you don't control

You can pin your own code; you can't fully pin someone else's model. So you manage it like any external dependency that can change:

- **Pin to specific model versions** rather than floating aliases wherever the provider lets you — so "the model changed" is a decision you make, not a surprise you receive.
- **Read the release notes.** Model versions get deprecated and updated; a deprecation nobody planned for is an outage with a countdown on it.
- **Never adopt a new model version blind.** Run it against your eval set first (next section). A newer, "better" model can be better on average and worse on _your_ specific tasks or output format.

This is the genuinely new problem: a functional change to your system that you never initiated and that appears in nobody's change log. It's one of the clearest illustrations of why [enterprise AI is an architecture problem before it's a model problem](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem) — the governance has to sit around the component, because the component moves.

> Your system can regress while your code sits untouched, because the model moved. If you're not running evals against model changes, the people downstream are your regression test — and they report failures as rework.

## Eval datasets: the regression suite for AI

The single practice that most separates a capability you can change safely from one nobody dares touch is an **eval dataset**: a curated set of representative inputs with known-good expected outputs (or scoring criteria) that you run any prompt or model change against, and get a _score_.

It does for AI what a test suite does for code:

- **Objective judgement.** "It feels better" becomes "it scored higher on the set." Vibes don't survive contact with a real change; scores do.
- **Regression safety.** A change that quietly breaks a case everyone had forgotten shows up immediately, before it reaches live.
- **Safe model migration.** A new model version is judged on evidence — improved, held, or regressed — not on a hopeful skim of three outputs.

Build it deliberately: the normal cases, the edge cases, and the ones that have burned you before (every incident becomes a new eval case). Version it alongside the prompt, because the bar and the thing being measured belong together. The full practice — cases, scoring, regression gate — is in [AI evaluation and regression testing](https://gravam.com/blog/ai-evaluation-and-regression-testing).

## The production loop

Put together, governed AI capabilities run on a loop that looks a lot like normal engineering, with two AI-shaped additions:

1. **Change** the prompt, settings, or model — as a versioned change with a record.
2. **Eval** against the dataset — improved, held, or regressed?
3. **Validate the output contract** — does it still parse and conform?
4. **Deploy** deliberately, through the same environments as any other change, knowing the live version.
5. **Log and monitor** real outputs — so drift, yours or the model's, shows up as data.
6. **Roll back** in one step if something regresses; **add the failure to the eval set** so it can't recur silently.

Steps 2 and 3 — evals and the output contract — are the AI-specific ones, and they're exactly the ones pilots skip. They're also what let you keep people in the loop on _quality_ without hand-checking every output — the same spirit as [using AI without letting it decide](https://gravam.com/blog/ai-automation-vs-augmentation-vs-autonomy).

## What good looks like

- **Prompt, model version, settings and output contract are all versioned** in the codebase, not tweaked live.
- **The model is pinned and its release notes are read**; a new version is adopted only after it passes evals.
- **An eval dataset scores every change**, and every incident becomes a new eval case.
- **Outputs are validated against a contract** and monitored live, so drift is data rather than an escalation.
- **Rollback is one step**, because you always know what's deployed and who approved it.

None of this is heavy — a prompt in git, a pinned model, a folder of eval cases, and the discipline to run them before shipping. But it's the difference between an AI capability that improves safely over time and one that becomes a haunted house where nobody dares touch the prompt because nobody knows what will break. Treat prompts as code and the model as a dependency, and the "magic" becomes something an organisation can engineer, change and trust.

***

_See also [why most AI pilots never become operating systems](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems) and [AI output contracts and failure handling](https://gravam.com/blog/ai-output-contracts-and-failure-handling)._

## Questions this article answers

**Q: Why do you need to version prompts?**

Because a prompt is production code — it determines what the system produces — and if you change it without versioning, you can't say what produced yesterday's output, can't roll back a change that made things worse, and can't tell whether a regression came from your edit or from somewhere else. Versioning a prompt means the exact text (and its settings) is tracked, tied to a version, and deployed deliberately, the same way you'd treat any code or configuration that shapes system behaviour. The moment a prompt is doing real work against real data, 'I tweaked it in the dashboard' stops being acceptable — you need to know which version is live, what changed, who changed it, and how to go back.

**Q: What happens when the model provider updates the model?**

Your system can change behaviour even though you changed nothing — because the model is a dependency you don't fully control. A provider update, a version deprecation, or a silent change to a model alias can shift outputs, break an output format your code depends on, or alter quality in ways the people downstream notice before you do. The defenses are pinning to specific model versions rather than floating aliases where you can, running an eval set against any new model version before adopting it, and monitoring live output so a shift shows up as data rather than as incidents. Treat the model as an external dependency with its own release notes, because that's exactly what it is.

**Q: Why does prompt versioning need an eval dataset?**

Because a version change needs a verdict. An eval dataset — a curated set of representative inputs with known-good expected outputs (or scoring criteria) — is the AI equivalent of a regression test suite: instead of eyeballing a few examples and hoping, you run the whole set and get a score, so a prompt change or a new model version is judged on evidence: did it improve, hold, or regress. It's what turns 'this feels better' into 'this passes,' and it's the single practice that most separates an AI capability you can change safely from one nobody dares touch.

---

# Is There a Gartner Magic Quadrant for TMS?

Source: https://gravam.com/blog/gartner-magic-quadrant-treasury-management-systems
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-09-01
Reviewed: 2026-09-01
Summary: There is no dedicated Gartner Magic Quadrant for treasury management systems. What Gartner actually covers, and how to shortlist a TMS without a quadrant.

**There is no Gartner Magic Quadrant for treasury management systems.** If you've been searching for one to anchor a TMS shortlist, that absence isn't your search skills — the quadrant genuinely doesn't exist for corporate TMS. What exists is adjacent: a Gartner Peer Insights review market for TMS, an old Magic Quadrant that covered bank-side treasury platforms, and analyst coverage of treasury technology from other firms. Knowing what each of those actually is stops a common selection mistake: outsourcing the shortlist to a chart that was never built for your question.

> **Figure — The Gartner Magic Quadrant for treasury management systems that does not exist**
>
> On the left, an empty two-by-two chart with a question mark in it, labelled no TMS quadrant. On the right, under the words what exists, three things — Peer Insights reviews, a 2011 quadrant for the bank side, and other analysts' coverage.
>
> There is no Gartner Magic Quadrant for corporate treasury management systems — only what sits next to it.

## What people are usually remembering

Gartner did publish a [Magic Quadrant for Treasury and Trading Core Systems](https://www.gartner.com/en/documents/1836814) — in 2011. Its scope was banking and capital-market participants managing trading and treasury positions across asset classes, not corporates choosing a system for cash visibility, payments and [FX hedging](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps). That is the document that surfaces when someone insists "there was a Gartner quadrant for treasury" — there was, it was bank-side, and it is old enough that citing it in a selection today would be malpractice.

## What Gartner actually offers today

Gartner covers the corporate TMS market through [Peer Insights](https://www.gartner.com/reviews/market/treasury-management-systems) — a review platform where practitioners rate the systems they run. That is genuinely useful input: real users, named products, structured ratings. But it is a review aggregator, not an analyst evaluation — no positioning of vendors against each other, no completeness-of-vision axis, and reviews skew toward whoever's customers were asked to write them.

_A caveat that belongs in the open: analyst coverage changes, and much of Gartner's research sits behind a subscription. If a dedicated TMS quadrant ever appears, this page is wrong the day it does — verify current coverage on Gartner's own site before repeating the claim in a board deck._

## Analyst coverage that does exist

Treasury technology is not an analyst desert — it's just not a Magic Quadrant market:

- **IDC** has published MarketScape assessments covering treasury and risk management applications.
- **Specialist analysts and practitioner bodies** — treasury-focused research houses, and associations such as AFP — publish vendor overviews, standardized RFP templates and selection guidance.
- **Peer references** remain the highest-signal source of all: companies your size, in your industry, running the system you're considering, telling you what the implementation actually cost.

## Why the quadrant wouldn't answer your question anyway

> A quadrant ranks vendors. A selection ranks fit. The best vendor in the top-right corner can still be the wrong system for your category.

The TMS market splits into [distinct categories](https://gravam.com/blog/best-treasury-management-system) — enterprise suites, mid-market systems, cash-visibility tools, [modular platforms](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) — and the right choice is decided by your company's size, instrument complexity and ERP landscape, not by any vendor's general standing. A leaders-quadrant system built for multinational in-house banks is an expensive mistake for a mid-market team that needs cash visibility and payment approvals. That category-fit judgment is precisely what a two-axis chart cannot encode — and it's the actual selection decision.

## What to do instead

Run the selection as a process you own rather than a chart you borrow:

1. Write down [requirements](https://gravam.com/blog/treasury-management-system-requirements-checklist) from your own workflows — not from vendor feature lists.
2. Put them in a written [RFP](https://gravam.com/blog/how-to-write-a-tms-rfp) so every vendor answers the same questions on the record — the [TMS RFP template](https://gravam.com/tools/tms-rfp-template) is the structure, free.
3. Score [scripted demos](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) against your scenarios, not the vendor's happy path.
4. Call references in your category, and build the [business case](https://gravam.com/blog/treasury-management-system-business-case) on what they actually paid and how long it actually took.

That process produces something no quadrant can: a decision that survives the question "why this system, for us?" — asked by an auditor, a CFO or your own team two years in.

***

_See also [how to run a TMS selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process) and [the best treasury management system: how to choose](https://gravam.com/blog/best-treasury-management-system)._

## Primary sources

- Gartner — Magic Quadrant for Treasury and Trading Core Systems (2011, banking and capital markets scope) — accessed 2026-09-01 — https://www.gartner.com/en/documents/1836814
- Gartner Peer Insights — Treasury Management Systems market (user reviews) — accessed 2026-09-01 — https://www.gartner.com/reviews/market/treasury-management-systems

## Questions this article answers

**Q: Is there a Gartner Magic Quadrant for treasury management systems?**

No — Gartner does not publish a Magic Quadrant dedicated to corporate treasury management systems. Gartner covers the TMS market through its Peer Insights review platform, which collects user reviews of TMS vendors, but there is no analyst quadrant that ranks corporate TMS vendors the way buyers often expect. The Magic Quadrant people sometimes half-remember — Treasury and Trading Core Systems — dates from 2011 and was scoped to banks and capital-market participants, not corporate treasury.

**Q: What can I use instead of a Magic Quadrant to compare TMS vendors?**

Use Gartner Peer Insights for structured user reviews, analyst research that does cover treasury technology (IDC has published MarketScape assessments of treasury and risk management applications, and specialist analysts and practitioner bodies such as AFP cover the space), and — most importantly — your own structured selection: a requirements checklist, a written RFP, scripted demos scored against a scorecard, and reference calls with companies your size in your category.

**Q: Why doesn't a vendor quadrant answer the TMS selection question?**

Because a quadrant ranks vendors on general execution and vision, while your decision depends on category fit: company size, instrument complexity, ERP landscape and budget put you in a specific TMS category, and the best vendor in a quadrant's top-right corner can still be the wrong system for your category. A leader built for multinational in-house banks is oversized for a mid-market cash-visibility problem — and no single chart encodes that.

---

# Modular Treasury Management System vs Monolithic Suite

Source: https://gravam.com/blog/modular-vs-monolithic-treasury-management-system
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-08-09
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: A modular treasury management system is bought module by module on a shared core treasury system. Which modules separate, and when it beats a single suite.

**A modular treasury management system is a TMS you license and implement module by module — cash management, payments, risk, debt and investments, accounting, bank connectivity — on a shared core. A core treasury system is that shared part: the transactions, positions, master data and posting logic every module reads from. A monolithic TMS arrives as a single all-in-one suite instead.** Vendors present this as a philosophical difference. In my experience it's a practical one, and it shows up in exactly two places: what your first implementation costs, and what every boundary between modules costs you afterwards. If you're still working out [what a TMS is](https://gravam.com/blog/what-is-a-treasury-management-system) at all, start there — this post assumes you know you need one and are deciding what shape it should take.

> **Figure — A modular treasury management system: modules on a shared core**
>
> A wide block labelled Core treasury system. Four modules plug into it from above — Cash and liquidity, Payments, Risk and hedging, and In-house banking. One of them, Risk and hedging, is lifted out of its slot, which is left empty.
>
> Each module can be added, left out or replaced; the core is what all of them stand on.

## What "modular" actually means

A modular TMS lets you buy and switch on capability in slices. The slices differ by vendor, but the recurring set is:

- **Cash and liquidity** — bank connectivity, statements, positions, forecasting.
- **Payments** — approval workflows, payment files, a [payment factory](https://gravam.com/blog/what-is-a-payment-factory) if centralized.
- **Risk and hedging** — exposures, deals, valuations, hedge accounting.
- **In-house banking** — intercompany accounts, netting, on-behalf-of structures.

The point isn't the list; it's that each slice can be licensed, implemented and gone live with **separately**, in whatever order your problems arrive — while sharing one data model, one set of static data and one security model underneath. That "underneath" is the part doing the work.

### Which modules are typically separable

Those four are the headline slices. In practice the catalogue is cut finer, and the same six or seven functions commonly turn up as separately licensed modules. What each one does, and what it needs from the core before it can run:

| Module | What it covers | What it needs from the core |
| --- | --- | --- |
| **Cash management** | Bank statements, the daily position, [cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility), liquidity forecasting | Bank account master data, entities, currencies |
| **Payments** | Payment requests, approval workflow, file generation, status tracking | Bank accounts, counterparties, users and approval roles |
| **Risk management** | Exposure capture, hedging deals, valuation, limits — the [treasury risk](https://gravam.com/blog/what-is-treasury-risk-management) discipline | Deal capture, positions, market data, counterparties |
| **Debt and investments** | Loans, facilities, deposits, securities — [debt and investment management](https://gravam.com/blog/debt-and-investment-management-in-treasury) | Deal capture and the transaction lifecycle, cash flows |
| **Treasury accounting** | Postings, accruals, valuation entries, hedge accounting | Every transaction and position the other modules created |
| **Bank connectivity** | The [channels to the banks](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) and the formats that travel them | Bank and account master data, security and certificates |
| **In-house banking** | Intercompany accounts, netting, on-behalf-of payments — the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) | Entities, internal accounts, payments and accounting |

Two things about that list are true generally and worth saying plainly. The module names and the exact cut differ by vendor — one system's "cash management" includes connectivity, another sells it apart — so compare what a module does, not what it is called. And "separable" means separately licensed and switched on, not independent: read the right-hand column and every module leans on the same shared data.

## The core treasury system

That shared underneath has a name: the **core treasury system**. It's the engine every module reads from and writes to — deal capture and the transaction lifecycle, positions, counterparties and bank account master data, and the posting logic that turns treasury activity into accounting entries.

### Core treasury system vs add-on modules

The distinction is about dependency, not importance. An **add-on module** is a capability you can license, leave out or replace without disturbing the rest: stop using the forecasting module and payments carry on. The **core treasury system** is what every module depends on — remove it and each of them loses the transactions, positions and [master data](https://gravam.com/blog/treasury-master-data-management) it runs on. A quick test for any component in a vendor's catalogue: _if this were taken away, what else would stop working?_ If the answer is "only that function", it is a module. If the answer is "everything", it is core, whatever the price list calls it.

That test also explains why the boundary is not always where the brochure draws it. Some functions sold as modules are core in practice — treasury accounting is often one, because every other module's transactions have to post somewhere.

The core is also the part you cannot swap later. Replace a reporting module and you've had a bad quarter; replace the core and you've replaced the system. Which leads to the selection advice I give most often: **evaluate the core, not the modules.** Demos are built around the modules because that's where the screens are. But ten years in, what you'll live with daily is whether the core's data model matched how your treasury actually works — the same reason [requirements](https://gravam.com/blog/treasury-management-system-requirements-checklist) should be written before any demo is watched.

> Modules are what the vendor demos. The core is what you live with. Evaluate the part you can't replace.

## What "monolithic" actually means

A monolithic TMS — the all-in-one suite — ships the whole footprint as one product: one implementation, one upgrade cycle, no internal seams. You may still phase the rollout, but you've bought the whole thing, and the modules were never designed to exist apart.

That's not a pejorative. The suite's strength is **coherence**: nobody has to integrate cash with risk, because they were never separate. The costs are the mirror image — you pay (in licence, and in implementation attention) for capability you may not switch on for years, and the upgrade cycle is all-or-nothing: the whole footprint moves together, on the vendor's schedule, whether this year's release helps your treasury or not.

## The trade-offs that actually decide it

**Phasing.** This is modularity's honest advantage. Treasury needs rarely arrive at once — visibility is urgent now, the [payment factory](https://gravam.com/blog/what-is-a-payment-factory) is next year, hedge accounting is when the auditors start asking. A modular system matches spend and [implementation effort](https://gravam.com/blog/treasury-management-system-implementation-guide) to each phase, and keeps the first project small enough to succeed. First projects that try to implement everything are how [TMS implementations fail](https://gravam.com/blog/why-tms-implementations-fail).

**The seams.** Modularity's honest cost. Every boundary — between modules, and between what you bought and what you kept elsewhere — is an integration to build, test and maintain through every upgrade on both sides. A modular architecture with many seams can quietly cost more than the suite you rejected on price.

**Lock-in, honestly assessed.** The suite locks you in obviously. But a modular core does too — the modules only pretend to be independent until you try to run one on somebody else's core. The real difference is _granularity of exit_: a modular estate lets you replace an edge without replacing the middle.

**Total cost.** Module-by-module pricing looks gentler and compounds worse; the suite's number is uglier and more honest. Do the arithmetic over the roadmap, not the first invoice — the same discipline as the [total cost of ownership](https://gravam.com/blog/tms-pricing-and-licensing-models) exercise.

SAP's treasury footprint is the modular pattern at its clearest: Cash Management, Transaction Manager, the analyzers, BCM, In-House Cash — separate components, activated separately, on one core and one data model. I've written a [whole guide to which SAP treasury modules you actually need](https://gravam.com/blog/sap-treasury-implementation-roadmap-and-module-selection); the reasoning there is this post's argument applied to one vendor's catalogue.

## The two shapes, and the one in between

Those trade-offs are easier to hold side by side than in sequence. And once you lay them out, a third shape appears between the two the vendors name — a modular core with specialist tools around it, which is what "the boundary between what you bought and what you kept elsewhere" looks like after it has actually been built. Call it core-plus-satellites. It is as often an outcome as a decision, which is exactly why it belongs in the comparison rather than at the end of it.

| Dimension | Modular (one core, bought in phases) | Core plus satellites | Monolithic suite |
| --- | --- | --- | --- |
| **Integration burden** | Seams only where the estate meets what you kept elsewhere; module-to-module is not an integration | The most seams — every satellite is an interface to build, test and maintain | No internal seams; cash and risk were never separate products |
| **Upgrade cadence** | One core release; you carry only the modules you switched on | Each vendor on its own calendar, and every release on either side re-tests the seam | All-or-nothing — the whole footprint moves together, on the vendor's schedule |
| **Data-model ownership** | The core owns it: one data model, one set of static data, one security model | The core owns the middle, each satellite owns its own — so ownership has to be settled at every boundary | One data model end to end, by construction |
| **Bank connectivity** | Arrives with the cash and liquidity slice, which is usually the first phase — so it is the first work you do | Often the piece kept outside, which makes connectivity a seam rather than a module | Ships with everything else, whether or not it is what you needed first |
| **Cost shape over time** | Gentler first invoice; compounds as modules switch on | Several contracts plus the integration to maintain — can quietly exceed the suite you rejected on price | Uglier number up front and more honest; you pay for footprint you may not switch on for years |
| **Exit cost** | You can replace an edge without replacing the middle; the core is still the part you cannot swap | The most granular exit — a satellite goes on its own; the core still does not | Replacing anything means replacing the system: obvious lock-in, at least priced honestly |

No column wins. There is only the column whose costs you would rather carry in year five, which is the [total cost of ownership](https://gravam.com/blog/tms-pricing-and-licensing-models) question asked over the roadmap instead of the first invoice.

## When a modular treasury management system is the right choice

Modular is the right choice when the scope is genuinely phased and the phases are known. In practice that means most of these hold:

- **The needs arrive in sequence.** There is one urgent problem now — usually visibility or payments — and the rest is a year or more away.
- **Part of the footprint is already covered elsewhere and is staying.** If the ERP already runs payments well, buying that capability a second time inside a suite is cost without benefit. This is the same question as [ERP treasury or a standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms), asked module by module.
- **The team can absorb one implementation at a time, not five.** A small treasury running a full-suite project alongside the day job is the common way a good system gets a bad go-live.
- **There is a written roadmap for the later modules.** Without one, modular is just a smaller purchase.

A single suite is the better choice when the opposite holds: the whole footprint is needed within one programme, nothing existing is being kept, and the organisation would rather pay for coherence than own [integrations](https://gravam.com/blog/designing-erp-tms-integration). Neither answer is the modern one or the legacy one; they are two ways of paying for the same capability.

## How I'd decide

Write the roadmap first: what treasury must do this year, next year, and plausibly in five. Then:

- **Needs arriving in phases, appetite for one small win at a time** → modular, and implement strictly one phase at a time.
- **Full footprint needed, one vendor relationship wanted, integration appetite low** → the suite, with a phased rollout inside it.
- **Either way** — evaluate the core against your requirements, count the seams before signing, and run the decision through a [proper selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process) rather than a demo beauty parade.

The architecture label matters less than vendors suggest. The roadmap fit, and the seams, are what you'll be living with in year five — and by then, nobody remembers what the first invoice said.

## What to ask in the RFP

Every row of that matrix is a question a vendor can answer in writing, which is more useful than watching it answered in a demo. Six worth putting in the document:

- **Which of these components share one core?** Name the ones that run on the same data model, static data and security model — and the ones that are separate products presented as a single footprint.
- **List every interface we would own.** Between your modules and the systems we are keeping: who builds each one, who maintains it, and what happens to it at each upgrade on either side.
- **What is the release cadence, and what has to move together?** Specifically: can a module we run stay on a release the rest of the footprint has already passed?
- **Which system owns which master data at each boundary** — bank accounts, counterparties, payment status?
- **Price the roadmap, not phase one.** Licence and implementation for every module we might switch on over five years, laid out year by year.
- **What does it take to replace one module and keep the rest?** Ask it about a module, then ask the same question about the core. The gap between the two answers is your real exit cost.

Write these into the requirements before the RFP goes out — the [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist) is the fuller list, and the [TMS RFP template](https://gravam.com/tools/tms-rfp-template) is where they turn into questions a vendor has to answer on the record.

***

_See also [the four kinds of TMS](https://gravam.com/blog/best-treasury-management-system) and [TMS vs ERP vs spreadsheets](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets)._

## Questions this article answers

**Q: What is a modular treasury management system?**

A modular TMS is one you license and deploy in parts — cash and liquidity, payments, risk and hedging, in-house banking — each module usable on its own but built on a shared core: one data model, one set of static data, one security model. You start with the module that solves today's problem and add the others when their problem becomes real, instead of buying and implementing the whole footprint on day one. The promise is a smaller first project and a system that grows with the treasury; the tax is that every boundary between what you bought and what you didn't is an integration question.

**Q: What is a core treasury system?**

The core treasury system is the engine the modules share: deal capture and the transaction lifecycle, positions, static data such as counterparties and bank accounts, and the posting logic that connects treasury activity to accounting. Cash visibility, payments, risk analytics and reporting all sit on top of it and read from it. It matters because the core is the part you can't swap later without replacing everything — which is why evaluating the core, not the demo-friendly modules around it, is the real job in selection.

**Q: What is the difference between a core treasury system and add-on modules?**

The core treasury system holds the data and logic everything else depends on: transactions and their lifecycle, positions, master data such as bank accounts and counterparties, and the rules that turn treasury activity into accounting entries. Add-on modules are capabilities licensed on top of it — cash and liquidity, payments, risk and hedging, debt and investments, treasury accounting, bank connectivity, in-house banking. A module can be added, left out or replaced without touching the rest; the core cannot. The practical test is to ask what breaks if the component is removed: if only that function stops, it is a module; if every other function loses its data, it is the core.

**Q: Should you choose a modular TMS or an all-in-one suite?**

Decide on your roadmap, not the architecture label. If treasury's needs arrive in phases — visibility first, payments next, hedging later — a modular system matches spend and implementation effort to each phase and keeps the first project small. If you know you need the full footprint and want one throat to choke, a suite trades flexibility for coherence: no internal integration seams, one upgrade cycle, one data model end to end. The wrong reason to go modular is a cheaper first invoice with no roadmap for the rest; the wrong reason to buy a suite is a feature list you'll never switch on.

---

# The Best Treasury Management System: How to Choose

Source: https://gravam.com/blog/best-treasury-management-system
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-29
Updated: 2026-07-30
Reviewed: 2026-07-30
Summary: There is no single best TMS — the right one depends on your category. A vendor-neutral guide to the four kinds of TMS, who each fits, and how to decide.

**There is no single best [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system) — and the honest version of the question is "which category fits my complexity, and which vendor in it fits my priorities?"** "Best TMS" lists rank products as if every treasury were the same shape. They aren't. A single-entity company that wants a dependable daily cash position and a large group hedging across a dozen currencies and fifty bank accounts are not shopping in the same market, and a tool that's perfect for one is waste or shortfall for the other. So this isn't a ranking. It's the vendor-neutral way to find the right _category_ first — and then choose inside it on your own criteria.

## The four categories of TMS

Almost every option a treasury looks at falls into one of four buckets. The skill is matching the bucket to your complexity before you compare a single feature.

| Category | What it is | Fits you when… |
| --- | --- | --- |
| **Spreadsheet model** | A structured workbook you own and maintain | You're single-entity with simple cash, and speed and control matter more than scale |
| **ERP treasury module** | Treasury embedded in the ERP you already run (e.g. [SAP TRM](https://gravam.com/blog/what-is-sap-treasury-and-risk-management)) | You're ERP-centric, want one integrated record, and your needs are moderate |
| **Specialist / best-of-breed TMS** | A dedicated treasury system from a treasury vendor | Complexity — many entities, banks, instruments, risk — justifies a system built only for treasury |
| **Point solution / aggregator** | A narrow tool for one job (forecasting, bank connectivity, hedge accounting) | You have one sharp gap, not a whole-treasury need |

The [spreadsheet vs ERP vs specialist question](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets) is really this table compressed to three of its rows — worth reading once you've placed yourself.

## Who each fits

- **Spreadsheets** stop being "not a real TMS" the moment you're honest that a workbook _is_ your treasury system. It's the right answer for simple, single-entity cash — cheap, fast, fully under your control — right up until it isn't: the fragility, the key-person risk and the wrong-the-moment-someone's-on-holiday problem are the signal you've [outgrown it](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets).
- **The ERP treasury module** wins when integration is the whole point: one system of record, no interface to reconcile, treasury sitting next to the accounting it posts to. If you already run the ERP, this is the option to disprove before you look elsewhere.
- **A specialist TMS** earns its cost when treasury complexity — multi-entity, multi-bank connectivity, forecasting, exposure and hedge management, risk analytics — is deep enough that a general system can't reach it. This is where "best" gets most contested, and where a disciplined selection matters most.
- **Point solutions** are for a single, sharp gap. They're a trap when you buy three of them to avoid choosing a real system and end up integrating a landscape you never designed.

## The vendor landscape by category

Categories only become useful when you can put real names in them — so here is the map, with the caveat stated plainly: **these are categories, not endorsements**. The table shows where each vendor's centre of gravity sits, so you know which shortlist a name belongs on. It is not a ranking, and inclusion is not a recommendation.

| Vendor | Category | Centre of gravity |
| --- | --- | --- |
| [SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) | ERP treasury module (embedded in S/4HANA) | Large, SAP-centric groups |
| Oracle Treasury | ERP treasury module (embedded in Oracle E-Business Suite) | Enterprises running Oracle EBS |
| Kyriba | Dedicated best-of-breed TMS (positions as a "liquidity performance platform") | Enterprise and mid-market |
| FIS Treasury and Risk Manager | Dedicated best-of-breed TMS | Quantum edition at the large, complex end; a second edition (Integrity) spans simpler books |
| ION Treasury | Dedicated best-of-breed TMS — a family of them | Wallstreet Suite for the largest, most complex organisations; Reval (SaaS) mid-to-large; Treasura is a cash-only tool |
| Ripple Treasury (formerly GTreasury) | Dedicated best-of-breed TMS | Multinational enterprise |
| Coupa Treasury (formerly Bellin tm5) | Dedicated TMS, embedded in a spend-management platform | Large and mid-sized organisations |
| Nomentia | Dedicated, modular treasury and cash management suite | European mid-market to enterprise |
| Atlar | Dedicated TMS of the newer API/AI-first generation | Mid-market and enterprise, with a customer base leaning to scaling tech and fintech |
| Trovata | Point solution / aggregator — bank-API cash visibility and forecasting (now also sells a fuller TMS tier) | Mid-market to enterprise |
| TIS | Point solution / aggregator — payments hub and bank connectivity with cash visibility; complements a TMS rather than replacing one | Mid-sized to large multinationals |
| Serrala | Point solutions / suite — AR, AP and payments automation with treasury components, including SAP-embedded deployment | Mid-sized and large finance functions |

Two things this table cannot do for you. First, it dates: vendors reposition and get acquired — GTreasury became Ripple Treasury after Ripple bought it, Bellin became Coupa Treasury — so treat the map as a starting point and verify each vendor's current positioning during your own selection. Second, it cannot weight your priorities: two vendors in the same cell can still fit you very differently, which is exactly what the scoring step below is for.

## How to actually decide

Notice that none of the above named a winner — because the winner depends on you. The decision runs in two moves:

1. **Place yourself in a category** from complexity, not marketing: entities, currencies, banks and formats, instruments, and how deep your integration needs run. That single step removes most of the market.
2. **Choose inside the category on your own weighted priorities** — not a feature-count arms race. Decide what actually matters to _you_ (connectivity, forecasting, risk, usability, total cost), weight it, and score the shortlist against it. A [free TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) makes that judgement explicit and comparable instead of a boardroom gut-feel, and a [business case](https://gravam.com/tools/tms-business-case-calculator) turns the shortlist into a defensible spend.

The full mechanics — requirements, the [TMS RFP](https://gravam.com/blog/how-to-write-a-tms-rfp), demos, references — live in the [selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process), and the [build-vs-buy](https://gravam.com/blog/build-vs-buy-treasury-management-system) and [SaaS-vs-on-premise](https://gravam.com/blog/saas-vs-on-premise-treasury-management-system) calls sit inside it. So does the modular-vs-monolithic architecture call — whether you buy a [core treasury system](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) and add modules in phases, or the footprint as one suite.

## The honest answer

The "best treasury management system" is the one whose category matches your complexity and whose fit matches your priorities — which is why a list can't tell you and a framework can. Get the category right and you've eliminated most of the wrong answers for free; score the rest on criteria you set, and "best" stops being someone else's ranking and becomes a decision you can defend.

***

_Score your shortlist with the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard), and see also [how TMS pricing and licensing actually work](https://gravam.com/blog/tms-pricing-and-licensing-models) and [why TMS implementations fail](https://gravam.com/blog/why-tms-implementations-fail) — the best system on paper is not the best one badly implemented. And if you were hoping an analyst chart would settle it: [there is no Gartner Magic Quadrant for TMS](https://gravam.com/blog/gartner-magic-quadrant-treasury-management-systems)._

## Primary sources

- AFP — What Is a Treasury Management System? — accessed 2026-07-29 — https://www.financialprofessionals.org/glossary/treasury-management-system
- Treasury Today — ERP vs TMS: the best of enemies — accessed 2026-07-29 — https://treasurytoday.com/technology/erp-vs-tms-the-best-of-enemies/
- Atlar — A guide to treasury management tooling: Excel, TMS, and ERP modules — accessed 2026-07-29 — https://www.atlar.com/guides/treasury-management-tooling-excel-tms-erp
- SAP PRESS — Introducing Treasury and Risk Management (TRM) with SAP S/4HANA — accessed 2026-07-29 — https://www.sap-press.com/introducing-treasury-and-risk-management-trm-with-sap-s4hana_5295/
- Strategic Treasurer — Treasury Aggregators: An In-Depth Look — accessed 2026-07-29 — https://strategictreasurer.com/treasury-aggregators-depth-look/
- Derivative Path — Hedge Accounting Software for ASC 815 and IFRS 9 Compliance — accessed 2026-07-29 — https://derivativepath.com/platform/hedge-accounting/
- Kyriba — Liquidity Performance Platform (vendor site) — accessed 2026-07-30 — https://www.kyriba.com/
- ION — Treasury and Risk Management Solutions (Wallstreet Suite, Reval, IT2, City Financials, Treasura) — accessed 2026-07-30 — https://iongroup.com/treasury/
- FIS — Treasury and Risk Manager, Quantum Edition (vendor site) — accessed 2026-07-30 — https://www.fisglobal.com/products/fis-treasury-and-risk-manager-quantum-edition
- Ripple Treasury (formerly GTreasury) — vendor site — accessed 2026-07-30 — https://treasury.ripple.com/
- Coupa — Coupa Acquires Treasury Management Leader BELLIN Group (press release, 2020) — accessed 2026-07-30 — https://www.prnewswire.com/news-releases/coupa-acquires-treasury-management-leader-bellin-group-301074921.html
- Nomentia — Smart Treasury Suite (vendor site) — accessed 2026-07-30 — https://www.nomentia.com/
- Atlar — AI-Native Treasury Platform (vendor site) — accessed 2026-07-30 — https://www.atlar.com/
- Trovata — Cash management, forecasting and TMS on bank APIs (vendor site) — accessed 2026-07-30 — https://trovata.io/
- TIS — Payments hub, bank connectivity and cash visibility (vendor site) — accessed 2026-07-30 — https://tispayments.com/
- Serrala — Finance automation platform with treasury components (vendor site) — accessed 2026-07-30 — https://www.serrala.com/
- Oracle — Oracle Treasury User Guide (E-Business Suite Release 12.2) — accessed 2026-07-30 — https://docs.oracle.com/cd/E26401_01/doc.122/e48862/T356981T356983.htm

## Questions this article answers

**Q: What is the best treasury management system?**

There is no single best treasury management system — the right one depends on your category and complexity, not a ranking. A large multi-entity group hedging across currencies and connecting to dozens of banks needs a very different system from a single-entity company that just wants a reliable cash position. The useful question is not 'which TMS is best?' but 'which category fits my complexity, and which of those vendors fits my priorities?' — and that second step is a weighted judgement you should make on your own criteria, not a vendor's.

**Q: What are the main types of treasury management system?**

Four broad categories: a spreadsheet model (cheapest, fine for simple single-entity cash); your ERP's embedded treasury module (integrated when you're ERP-centric, e.g. SAP Treasury and Risk Management); a specialist best-of-breed TMS (the deepest, most treasury-specific capability, at more cost and integration effort); and point solutions or aggregators (narrow tools for one job — cash forecasting, bank connectivity, hedge accounting). Most 'best TMS' searches are really trying to find the right category first.

**Q: How do I decide which TMS is right for us?**

Start from complexity, not brand: how many entities and currencies, how many banks and formats, what instruments you hold, and how deep your integration needs run. That maps you to a category. Within a category, score the shortlist on your own weighted priorities rather than a feature count — a free scorecard makes that explicit — and justify the spend with a business case rather than a gut feel.

---

# TMS Pricing, Licensing and Total Cost of Ownership

Source: https://gravam.com/blog/tms-pricing-and-licensing-models
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: How TMS vendors price and licence their software — SaaS vs perpetual, what they charge on — and the total cost of ownership that sits behind the quote.

**Treasury management system vendors price their software in two broad ways — a recurring SaaS subscription or an upfront perpetual licence plus annual maintenance — scaled on dimensions like modules, users, volume, entities and bank connections. But the licence is the smaller part of what you'll pay.** From the buyer's side of these deals, the number the vendor leads with is the least useful one in the conversation. The real cost lives in implementation, connectivity, your own people's time and the quiet way pricing scales as you grow — the parts that don't fit on the first quote. This guide covers both halves: how the price is built, and the total cost of ownership (TCO) it feeds into. Pricing is the input; TCO is the answer you need.

## The two licensing models

Almost every TMS you'll evaluate is sold under one of two models, and the choice shapes the _shape_ of your cost as much as its size.

- **SaaS / subscription.** You pay a recurring fee — usually annual, sometimes monthly — to use software the vendor hosts, runs and upgrades. There's no large upfront licence to capitalise; it's an operating expense that recurs for as long as you use the system. This is now the default for new deals, and most vendors have made it their primary or only model.
- **Perpetual licence plus maintenance.** You buy the right to run the software indefinitely as an upfront cost, then pay an annual maintenance fee — typically a percentage of the licence — for support and updates. On top of that you carry the cost of hosting, running and upgrading it yourself. This is the older, on-premise-flavoured model, and it's steadily giving way to subscription.

The distinction matters beyond accounting treatment. SaaS spreads spend smoothly and predictably over years (opex) and turns upgrades into change you absorb rather than projects you run; perpetual front-loads a capital outlay (capex) and adds the standing cost of infrastructure and the team to run and upgrade it. On-premise can look cheaper if you ignore those run costs — which is exactly why you must not. The [deployment side of this choice](https://gravam.com/blog/saas-vs-on-premise-treasury-management-system) — who hosts, who upgrades, who carries the risk — drives the cost profile as much as the price list does.

## The dimensions vendors price on

Whichever model you're under, the number itself is built from a handful of pricing dimensions. Vendors mix and match these, which is precisely what makes quotes hard to compare like-for-like:

- **Modules and functionality.** You licence the capabilities you need — cash and liquidity, payments, risk and hedging, debt and investment — and the price reflects the footprint. A treasury running only cash and payments pays for a different scope than one adding full FX and hedge accounting. Whether those modules arrive one at a time or as one suite is the [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) decision, and it changes how the price compounds.
- **Users or user tiers.** Named users, concurrent users, or banded tiers ("up to N users"). Watch the tier boundaries: the jump from one band to the next can be steeper than the headline suggests.
- **Transaction or volume.** Some pricing scales with payment or transaction volume, so a growing payment factory quietly costs more each year with no new functionality.
- **Entities, bank accounts and connections.** The number of legal entities, bank accounts, or bank connections you run is a common lever — and one of the most consequential, because a multi-entity group with many banking relationships accumulates these fast.

None of these is wrong on its own. The trouble starts when you compare two offers priced on different dimensions and assume the cheaper headline means the cheaper system.

## Total cost of ownership: the costs beyond the licence

TCO answers "what will this system _really_ cost us, all in, over its life?" It's measured across a multi-year horizon — three to five years is common — because that's the timeframe over which implementation and recurring costs actually play out, and for most treasuries the licence or subscription is _not_ the largest line over that horizon. A full TCO includes:

- **Licence / subscription:** the recurring or upfront software cost described above.
- **Implementation and professional services:** configuration, project work, testing and cutover. Often the single biggest one-time cost, and in complex deployments it can rival or exceed the software itself.
- **Bank connectivity and onboarding:** getting each [bank connected, tested and live](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) — across SWIFT, host-to-host, EBICS or API — is real, billable effort, and it's usually on the project's critical path.
- **Integration and data migration:** connecting the TMS to [your ERP](https://gravam.com/blog/designing-erp-tms-integration) and other systems, and extracting, cleaning and loading opening data.
- **Data and market-data feeds:** FX rates, interest rates and other market data usually arrive as separate subscriptions, sometimes from third parties, not bundled in the price.
- **Internal resource:** your people's time during and after the project. Large, real, and the most commonly ignored line.
- **Training and change:** getting the organization actually using it.
- **Ongoing support and upgrades:** the run cost every year, whether upgrades arrive as effort (on-premise) or as change absorption (SaaS).
- **Change over time:** new banks, new entities, new requirements, each with a cost.

### One-time vs recurring

Split those lines into **one-time** (implementation, migration, initial integration and onboarding) and **recurring** (subscription or maintenance, feeds, support, upgrades, ongoing internal effort), then project the recurring costs across the horizon. This is what reveals that a cheaper-to-buy system can be dearer to _own_, and vice versa — and it's the number that belongs at the centre of the [business case](https://gravam.com/blog/treasury-management-system-business-case). If you want to see what your own quote implies, the [TMS business-case calculator](https://gravam.com/tools/tms-business-case-calculator) turns those cost lines and the benefits into an annual figure, payback period and multi-year ROI.

### The hidden costs

The lines buyers miss most:

- **Internal effort:** treated as "free" because it's not an invoice, but it's real capacity spent.
- **Customization maintenance:** every [customization](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) is a permanent liability to test and carry through every upgrade.
- **Integration upkeep:** bank formats and connections change; keeping interfaces working is ongoing.
- **Exit / switching cost:** getting your data out and moving later, rarely thought about at purchase.

## How to compare offers honestly

Two vendors, two quotes, two entirely different structures — this is the normal state of a TMS selection. (It is also why a [TMS RFP](https://gravam.com/blog/how-to-write-a-tms-rfp) should ask every vendor to price against the same structure.) To compare them without fooling yourself:

- **Normalise to total cost over a multi-year horizon.** Five years is a reasonable frame. Add subscription (or licence plus maintenance), implementation, connectivity, feeds, integration, support and your own team's time, and compare the totals — not the headline licences.
- **Ask what's excluded.** The gaps between quotes are usually in what one vendor bundled and another didn't: market data, connectivity onboarding, a certain number of connections, support tier. The exclusions are where the surprises live.
- **Stress-test how it scales.** Model the price not at today's size but at where you'll be in three years — more entities, more connections, more volume. Per-entity and per-connection pricing that looks fine now can scale badly precisely as your treasury grows into the value the system was meant to deliver.
- **Cost the years after go-live.** Year one is the easy year to price. Upgrades, new banks and the customizations you'll be asked for are where under-budgeted programmes come apart.

Do that inside a [structured selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process) and the cost comparison sits beside fit, not above it.

## Why the licence fee predicts cost so poorly

The price list and the demo make pricing look like a solved arithmetic problem: pick your modules, count your users, read off the number. In reality the licence is the figure everyone anchors on and the one that predicts your actual spend the least. I've seen two systems with near-identical subscription prices diverge enormously once implementation, connectivity onboarding and multi-year scaling were counted — and the one that looked cheaper on the quote turned out dearer to own.

> The licence is the price of admission, not the cost of the trip. Implementation, integration and years of running the thing are where the real money goes — and none of it is on the first quote.

The vendors know this — not as a conspiracy, but because the licence is the number that's easy to quote early, so it's the one that leads. Your job is to refuse to let it anchor the decision: treat the sticker price as an input, not an answer, include your own people's time, normalise everything to total cost over years, and model how the pricing behaves as you grow. Do that, and the licence fee shrinks back to what it should have been all along — one line in a much larger total-cost picture, not the number that ambushes you at renewal. The cheapest licence and the lowest total cost are rarely the same system; TCO is how you tell them apart.

***

_See also [the TMS business case](https://gravam.com/blog/treasury-management-system-business-case) and [what a TMS actually is](https://gravam.com/blog/what-is-a-treasury-management-system)._

## Questions this article answers

**Q: How is a TMS priced?**

Most modern treasury management systems are priced as a recurring subscription, scaled by some combination of the modules you licence, the number of users or a user tier, transaction or payment volume, and the number of entities or bank connections. The subscription is only one line, though — implementation, bank connectivity onboarding, market-data feeds and ongoing support are separate costs, and together they usually exceed the licence itself.

**Q: What is the difference between SaaS and perpetual licensing?**

SaaS (subscription) means you pay a recurring fee — usually annual — to use software the vendor hosts and upgrades; it's an operating expense with no large upfront licence. A perpetual licence means you buy the right to run the software indefinitely as an upfront capital cost, then pay annual maintenance (typically a percentage of the licence) for support and updates, and you carry the cost of hosting and upgrading it yourself. SaaS spreads cost smoothly over time; perpetual front-loads it.

**Q: What drives TMS cost?**

The biggest cost drivers are rarely the sticker licence. They are the scope of what you implement, the number of banks and connections you onboard, how much integration and data migration your landscape needs, and how the pricing scales as you add entities, users or connections. A system priced attractively for your size today can become expensive as you grow, which is why cost has to be judged over a multi-year horizon rather than on the first quote.

**Q: What is the total cost of ownership of a TMS?**

The total cost of ownership (TCO) of a treasury management system is the full cost of acquiring and running it over its lifetime: not just the software licence or subscription, but implementation, integration, data migration, internal staff effort, training, ongoing support and maintenance, upgrades, and the cost of future changes. It's typically measured over a multi-year horizon (commonly three to five years) because over that span the implementation and recurring costs usually outweigh the licence.

**Q: What are the hidden costs of a treasury management system?**

The costs buyers most often miss are: internal staff effort during and after implementation, integration with banks and the ERP, data migration, the maintenance burden of any customizations, periodic upgrades, training and change management, and the cost of exiting or switching later. Customization is a particular trap because each one is a permanent maintenance liability. Estimating TCO means listing all of these across several years, not just the numbers on the vendor's quote.

---

# TMS Data Migration: Moving Master Data and Open Deals

Source: https://gravam.com/blog/tms-data-migration
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-26
Reviewed: 2026-09-26
Summary: TMS data migration means moving master data, open positions and live deals into a new treasury system — cleanly, and reconciled so your positions still tie out.

**TMS data migration is the work of moving your treasury data — master data first, then open positions and live deals — into a new [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system) so that the new system produces exactly the same positions, cash flows and valuations as the old one on the day you cut over.** It sounds like a loading exercise. It isn't. It's a data-quality exercise wearing a loading exercise's clothes, and it's where a well-run [TMS implementation](https://gravam.com/blog/treasury-management-system-implementation-guide) quietly goes wrong.

I've watched programmes that nailed the design and the bank connectivity still stumble at go-live because the data underneath wasn't owned early enough. So this is the phase I'd tell you to worry about first, not last.

## What actually moves

Not everything, and not in one go. Migration has a strict order, and the order is the point.

**Master (static) data first.** This is the reference layer everything else points at:

- **Bank accounts and house banks** — the accounts you hold, at which banks, with which identifiers.
- **Counterparties and business partners** — the banks, brokers and internal entities you deal with.
- **Instruments** — the definitions of the products you trade (loans, deposits, FX, swaps).
- **Standing settlement instructions (SSIs)** — where money actually goes when a deal settles.

**Then the transactional layer** — open positions and live deals: the loans still outstanding, the deposits not yet matured, the FX and swaps still on the book. Each of these carries its correct **opening valuation** and accrued interest, not just its original trade terms.

**Then a decision about history.** How many years of closed, matured, settled transactions do you drag along? Usually the answer is: far less than people first assume.

## Master data is the whole game

Here's the principle that saves programmes: **migrate master data clean, and prove it clean, before anything references it.**

A deal in a TMS is mostly pointers. It points at a counterparty, a bank account, an instrument, a settlement instruction. If the counterparty record is wrong, every deal that references it is wrong — silently, and in a way that doesn't surface until a payment goes to the wrong place or a position won't reconcile. A single dirty bank account or a duplicated business partner doesn't cause one problem; it seeds hundreds, each traceable months later to a record nobody cleaned.

> Dirty static data doesn't corrupt one deal. It corrupts every deal that points at it — and you find out at the worst possible time.

This is why static-data quality is the whole game. You cleanse it, de-duplicate it, and validate it _before_ load — not "to fix later" once positions are already sitting on top of it. The same discipline shows up in [why TMS implementations fail](https://gravam.com/blog/why-tms-implementations-fail): the root cause is almost never the load mechanics. It's that no one owned the data.

## Open items and opening balances

Migrating a live deal is not copying a row. It's reconstruction.

The test is simple and unforgiving: after migration, the new system's **future cash flows, position and valuation for that deal must be identical to the legacy system's** as of the cutover date. Same principal and schedule, same accrued interest, same mark-to-market. If your legacy system says a swap is worth a certain amount today and generates a certain stream of payments, the new system must agree — to the cent.

That means opening balances and opening valuations are migrated deliberately, not derived hopefully. You're not re-deriving history in the new system; you're seeding it with a correct starting point so that from cutover forward it computes the same answers the old system would have. Get one accrual convention or one valuation date wrong and the position drifts from day one.

## The approach: extract, cleanse, load, reconcile

The mechanics are conventional. The discipline around them is not.

1. **Extract** the data out of the legacy system and any spreadsheets it quietly depends on.
2. **Cleanse and transform** — de-duplicate, correct, and map legacy structures to the new system's model. This is where most of the real effort lives.
3. **Load** into the new system, master data before transactional data, always.
4. **Reconcile** — and this is the step teams under-budget. Tie every balance, position and valuation back to the source and resolve every break.

The reconcile step is what turns a migration from an act of faith into an act of evidence. And the strongest form of it is a **parallel run**: for a period before cutover, both the old and new systems process the same reality, and you compare their output. A real month-end in both. A real valuation in both. When they produce the same numbers across real cycles, you've earned the right to trust the new one. Until then, you haven't. The same reconcile-and-prove muscle applies to any finance system migration — treasury just punishes a mismatch faster, because a wrong position is visible the next morning.

> Budget reconciliation as its own workstream with its own owner, not as the tail end of "load." A migration is finished when the numbers tie out and stay tied out through a parallel run — not when the load job reports success.

## Control totals, then sign-off

Reconciliation has a concrete shape: **control totals** per layer, source against target, exactly as for any [interface](https://gravam.com/blog/interface-monitoring-and-reconciliation). Record counts catch what was lost; amount sums catch what was corrupted. Source has 12,438 open items totalling €X, so target must have 12,438 totalling €X — for master data, opening balances and open deals alike. It ends in an explicit **sign-off** that the migrated data is accepted, by the person who will live with it, not by the load job.

## Rehearse it: mock migrations

Like the [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) itself, the migration should not be run live for the first time. **Mock migrations** — trial loads on real data — surface the bad mappings, the cleansing that was missed and the load errors while they are still cheap. Each rehearsal improves the runbook; the live migration should be the _n_th time the team has done it, and the parallel run above is what the last rehearsal turns into. The free [cutover and go-live checklist](https://gravam.com/tools/cutover-go-live-checklist) has a migration section for the go/no-go itself.

Cleansing deserves the same treatment: a **workstream**, started early and staffed with people who know the data, not a task the week of cutover. "These 400 records are duplicates — which one survives?" is a business decision, and business decisions take time.

## What about history?

The instinct is to bring everything. Resist it.

You generally **don't migrate deep transactional history into the operational TMS.** The new system needs enough to compute today's positions and forward cash flows correctly — the open book and its opening state — not fifteen years of settled deals cluttering the system it has to run on tomorrow. For the history itself, keep the legacy system readable in read-only mode for a defined period, or archive it somewhere you can query for audit. Then start the new system clean.

This keeps the transactional system lean and keeps the migration scope honest: every year of history you insist on loading is data you must also cleanse, map and reconcile — for records that are already closed.

## Where it quietly goes wrong

If you take one thing away from this: **data migration is rarely hard because loading is hard.** The load is a solved problem. It goes wrong because nobody owned data quality early, so cutover weekend arrives with static data migrated "as-is to fix later," positions that don't reconcile, and a team discovering at the worst possible moment that the new system and the old one disagree.

The documentation makes it a tidy box on a plan — one phase, a few weeks, "migrate and reconcile data." The reality is a thread running through the whole programme. Name a **data owner on day one**, cleanse master data long before load, treat reconciliation as evidence rather than a formality, and prove the whole thing with a parallel run. Do that, and cutover is boring. Skip it, and cutover is the moment you discover what you should have owned six months earlier.

For where this phase sits in the wider programme, see the [implementation guide](https://gravam.com/blog/treasury-management-system-implementation-guide).

## Questions this article answers

**Q: What data is migrated into a TMS?**

Two kinds. First, master (static) data — bank accounts, house banks, counterparties and business partners, instrument definitions, and standing settlement instructions — which everything else references. Then transactional data: open positions and live deals (loans, deposits, FX, swaps) with their correct opening valuations. You usually leave deep history in the legacy system rather than loading it into the new one.

**Q: How do you migrate open deals into a new TMS?**

You reconstruct each live deal in the new system so its future cash flows, position and valuation come out identical to the legacy system on the cutover date. That means loading the deal against clean master data, applying the correct opening valuation and accrued interest, and reconciling the result to the cent — not just importing the trade and hoping the numbers agree.

**Q: How do you validate TMS data migration?**

You reconcile, then you run in parallel. After loading, tie balances, positions and valuations back to the legacy system and resolve every break. Then run both systems side by side over real cycles — a month-end, a payment run, a valuation — and confirm they produce the same numbers before you trust the new one and switch off the old.

---

# TMS Cloud Security and Data Residency

Source: https://gravam.com/blog/tms-cloud-security-and-data-residency
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: A cloud TMS holds your bank details and payment capability — the security, certification and data-residency questions to ask a vendor before you sign.

**A cloud treasury management system holds your bank account details, your payment capability and your financial data — which makes it a high-value target — and it runs in someone else's infrastructure, which makes its security a shared-responsibility question, not a box the vendor ticks on your behalf.** When you buy a TMS today it is almost certainly [SaaS](https://gravam.com/blog/saas-vs-on-premise-treasury-management-system): the vendor hosts and operates it, and the natural follow-on question is how that data is secured and where it lives. This guide is the set of questions I'd want answered before signing — general guidance, not advice for any specific organisation.

## Why treasury raises the stakes

Most software holds data. A TMS holds the two things an attacker actually wants: information and the ability to move money. It aggregates bank balances, stores account and counterparty details, and — the part people underweight — it can originate and approve payments. A compromise isn't an embarrassing data leak; it's a route to fraudulent payments and a map of how your cash moves. That's why it belongs on your [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist) as a scored, evidenced criterion, not a reassuring line in the sales deck.

And because the system runs in the vendor's cloud, "is it secure?" is the wrong question. The honest framing is the shared-responsibility model: the vendor secures the infrastructure, platform and application they host; you remain responsible for who has access, how duties are segregated, how payments are approved, and whether your configuration is sound. A great deal of real-world SaaS harm is customer-side misconfiguration, not a vendor breach — both halves have to be solid, and each side should be able to show its work.

## Certifications and assurance: what to actually ask for

Vendors will list certifications. Your job is to read them, not collect logos:

- **SOC 2 (ideally Type II).** An independent auditor's report on the controls around security, availability and confidentiality. Type I says the controls were _designed_ adequately at a point in time; **Type II** says they _operated_ effectively over a period — usually six to twelve months. Type II tells you the controls are lived, not laminated.
- **ISO 27001.** Certification that the vendor runs a recognised information-security management system — an audited framework for managing risk, not a single technical control.
- **Independent penetration testing.** Evidence that a third party regularly tries to break in, and — more telling — that findings get remediated.

The critical move is to ask to **see the reports**, typically under NDA, then read three things: the date (is it current?), the scope (does it cover the service you're actually buying, or a sibling product?), and the exceptions the auditor noted. A vendor that shares a current, in-scope report without friction is telling you something reassuring. One that offers only a webpage badge is telling you something too.

> A certification logo is a marketing claim. The audit report behind it is the evidence. In selection, insist on the second — before you sign, not after an incident makes you wish you had.

## Data residency and sovereignty

Data residency is _where_ your data physically lives and is processed. For a lot of software that's a footnote; for treasury it can be a binding constraint, for three overlapping reasons:

- **Privacy law.** Regimes such as GDPR govern where personal data — including the people behind bank and counterparty records — may be stored and transferred.
- **Banking secrecy and sector rules.** Some jurisdictions require that financial data about their entities stay in-country, or restrict cross-border transfer.
- **Government-access concerns.** Where data is stored can determine which government can compel access to it, which is a real consideration for some groups and regulators — the "data sovereignty" question sitting underneath residency.

So the question to a vendor is concrete: in which region(s) will _our_ instance be hosted and processed, will you **commit to that in the contract**, and where do backups, support access and any sub-processors sit? Multi-tenant SaaS often runs in a fixed set of regions; if you need a specific one, confirm it's actually offered rather than assumed — residency is the constraint most likely to override the SaaS default.

## Access and identity

The controls you own start here, and they're where customer-side incidents concentrate. What good looks like:

- **SSO**, so TMS access is governed by your corporate identity provider and a leaver loses access everywhere at once.
- **MFA**, enforced — non-negotiable for a system that can move money.
- **Role-based access**, granular enough to give people only what their job needs.
- **Segregation of duties inside the tool**, so whoever creates a payment can't also approve and release it — the control that most directly blocks internal fraud.
- **Audit trails** that record who did what and when, and that you can actually export and review.

What varies is how well the tool _enforces_ these versus how well it _demos_ them — exactly the thing to probe during a structured [selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process) rather than take on faith.

## Encryption, resilience and the payment path

Encryption is table stakes but worth confirming: data encrypted **in transit** (nothing moves in the clear) and **at rest** (a stolen disk or backup is useless). Then resilience, because a TMS you can't reach on a payment-run morning is its own kind of failure — ask for **backup and disaster recovery** with stated RPO/RTO targets and evidence they're tested, and **business continuity** for the service as a whole. Knowing [what RTO and RPO actually mean for treasury](https://gravam.com/blog/disaster-recovery-business-continuity-treasury) — and what targets you genuinely need — puts you in a far stronger position to judge the vendor's answer.

Give the **payment path** its own scrutiny, because it's where security and fraud meet. How are payment instructions protected end to end? Are approval limits and segregation of duties enforced by the system rather than by convention? How are the connections to your banks secured and monitored — the certificates, keys and signing that [bank connectivity security](https://gravam.com/blog/bank-connectivity-security) covers? It's the flow most worth an attacker's effort.

## Treat security as an evidenced selection criterion

The through-line: make security a criterion you _score with evidence_, the way you'd score functionality — give it a weighted line of its own in the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) so it survives the demo-day enthusiasm. Ask for the SOC 2 and ISO reports, get the residency commitment in writing, walk the access controls and payment path with someone technical, and — because moving vendors later is hard — ask how you'd get your data out when you leave. A vendor that answers fluently and hands over documents is a different proposition from one that reassures you warmly.

## Docs-vs-reality

Here's the pattern I've watched play out. Security gets a slide and a confident nod in selection while attention stays on features and price. It gets _real_ scrutiny exactly once — after an incident, or after an auditor asks a question no one can answer — and by then you're negotiating from weakness, mid-contract, with the leverage gone. That leverage exists in precisely one window: before you sign, when the vendor wants your business and will hand over the SOC 2 report, commit to a region, and walk you through the payment controls. After signing, the same requests become favours. Security and residency are cheapest to secure as questions in a selection, and most expensive to discover as gaps in production — and if you're still framing the wider decision, [what a TMS is and does](https://gravam.com/blog/what-is-a-treasury-management-system) sets the context these questions sit inside.

## Questions this article answers

**Q: Is a cloud TMS secure?**

It can be, and a reputable cloud TMS is often more secure than what a corporate treasury could run itself — but 'secure' is not a property the vendor delivers alone. Security in a cloud TMS is a shared responsibility: the vendor secures the infrastructure, platform and application they host, while you remain responsible for user access, segregation of duties, approval controls and how your people configure and use the system. The right question isn't 'is it secure?' but 'who is responsible for which part, and can each side show its work?'

**Q: What is data residency and why does it matter for treasury?**

Data residency is where your data is physically stored and processed — which country or region the servers sit in. It matters for treasury because a TMS holds bank account details, payment data and financial information that may be subject to privacy law (such as GDPR), banking secrecy, or rules about which governments can compel access to data. Regulated entities and some jurisdictions require that certain data never leaves a defined region, so where the vendor runs your instance can be a binding constraint, not a preference.

**Q: What security certifications should a TMS have?**

Look for independent, audited assurance rather than self-declared claims: a SOC 2 Type II report and ISO 27001 certification are the common baselines, and regular third-party penetration testing is expected. What matters is not only that the vendor names these but that you can see the underlying reports under NDA, that they're current, and that their scope actually covers the service you're buying. A logo on a website is a marketing claim; the report is the evidence.

---

# How to Write a TMS RFP (Request for Proposal)

Source: https://gravam.com/blog/how-to-write-a-tms-rfp
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-30
Reviewed: 2026-07-30
Summary: A TMS RFP is the structured document that asks shortlisted vendors to propose against your requirements — how to write one that gets comparable, useful answers.

**A TMS RFP (request for proposal) is the structured document you send to a shortlist of treasury management system vendors, asking each to propose — with evidence — how they meet your specific requirements, so you can compare them like-for-like.** It's not the whole selection; it's one disciplined step inside it. And its real value isn't the pile of proposals that comes back. It's that writing it forces your own team to agree what actually matters _before_ the demos start and someone falls in love with a slick screen.

I've written, scored and — more painfully — inherited a fair number of these. The good ones are short, prioritized and specific. The bad ones are a copied template three hundred lines long where every requirement is "mandatory," which is another way of saying nothing is.

## Where the RFP sits

The RFP is not the start of anything. By the time you write it, two things should already be true: you know your requirements, and you have a shortlist. It slots into the wider [TMS selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process) like this — requirements first, then a longlist, then a way to cut that longlist down, _then_ the RFP to the survivors.

That cutting-down step usually has a name: the RFI.

## RFI vs RFP: qualify, then discriminate

An **RFI** (request for information) is the lighter, earlier document. You send it to a longlist to answer a simple question — _who is even worth a serious conversation?_ Basic capabilities, company facts, rough fit, indicative cost. It qualifies vendors and turns a longlist of, say, eight or ten into a shortlist of three or four. (The longlist itself starts from knowing [which category of TMS you're shopping in](https://gravam.com/blog/best-treasury-management-system) — ERP module, specialist system or point solution — so you're not comparing across kinds. If you were hoping to lift it from an analyst chart, read [Gartner Magic Quadrant for treasury management systems](https://gravam.com/blog/gartner-magic-quadrant-treasury-management-systems) first.)

An **RFP** (request for proposal) goes to that shortlist and asks each survivor to propose in detail against your requirements. It discriminates between real contenders.

The mistake I see most often is skipping the RFI and firing a full RFP at everyone. You get twenty dense responses, your evaluation team drowns, and — because you never qualified — half of them were never realistic anyway. Qualify first. Then write a serious RFP for the few that earned one.

## What a good RFP contains

The structure matters, because structure is what makes answers comparable. A workable TMS RFP has these sections:

- **Company and treasury context, and objectives.** Who you are, your entity/bank/currency footprint, and — crucially — the two or three problems you're actually trying to solve. Vendors write better, more honest proposals when they understand the job, not just the checklist. Say, too, whether you want the full scope from one suite or a core you'll extend over time — the [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) choice changes how vendors should price and phase their answer.
- **Functional requirements.** The heart of it, drawn straight from your [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist) — cash and liquidity, bank connectivity, payments, financial risk, accounting, reporting — each already prioritized must / should / could.
- **Technical, integration and connectivity requirements.** How it connects to your ERP and middleware, which bank channels and message formats it supports (SWIFT, host-to-host, EBICS, API; MT940, camt, ISO 20022), and how integrations are built and maintained.
- **[Security and data-residency requirements](https://gravam.com/blog/tms-cloud-security-and-data-residency).** Access control, segregation of duties, encryption, certifications, and where your data physically lives and is processed — increasingly a hard constraint, not a footnote.
- **Implementation and support expectations.** Approach, typical timeline, resourcing on both sides, and what support actually looks like after go-live.
- **Commercial and pricing questions.** Licensing model, implementation cost, and the running costs that make up total cost of ownership — asked in a structured way so you can compare, not decode.
- **Vendor and company questions.** Viability, roadmap, reference customers, ownership. You're buying a multi-year relationship.

If you'd rather start from a working document than a blank page, build yours with the free [RFP template builder](https://gravam.com/tools/tms-rfp-template) — every section above as prewritten, editable prompts with must-have / nice-to-have priorities, exportable as markdown.

## Write it so it actually discriminates

A structure isn't enough. Most RFPs fail not on what they ask but on _how_ they ask it. Four habits separate an RFP that tells vendors apart from one that doesn't:

1. **Prioritize every requirement — must, should, nice-to-have.** If everything is mandatory, the RFP can't distinguish anyone; vendors just tick "yes" down the column and you learn nothing. The priorities are what your later scoring is weighted against.
2. **Ask _how_, not _whether_.** "Do you support cash forecasting?" gets a "yes" from everyone alive. "Describe how your system builds a rolling 13-week forecast, including data sources and how variance is tracked" gets you an answer you can actually judge.
3. **Ask for evidence, and tie demos to _your_ scenarios.** Request examples, screenshots, reference situations — and make clear the demo will run your month-end, your payment run, your awkward intercompany case. That expectation shapes the proposals you get back, and it sets up the [vendor demos and scorecard](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) that follow.
4. **Agree the scoring scheme before responses arrive.** Weighted by your priorities, owned by the whole evaluation team. Decide how you'll score _before_ you read a single answer, or the scoring quietly bends to fit the vendor you already liked. If you want a working starting point, the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) is a weighted scoring model you can set up in minutes and adapt to your own criteria.

> The RFP's real job isn't to collect proposals. It's to force your own team to agree what actually matters — in writing, with priorities — before the demos dazzle everyone. A vague RFP produces vague, unscoreable answers, and no amount of vendor effort fixes that.

## The mistakes that keep coming back

Having cleaned up after a few of these, the failure patterns are dull and repeatable:

- **A wishlist with no priorities.** Everything is "must," so nothing discriminates, and vendors compete on feature-count instead of fit.
- **A copied generic template.** It reflects some other company's process — or no company's — instead of your real requirements and your real footprint. Vendors can smell a boilerplate RFP, and they answer it with boilerplate.
- **Yes/no questions.** Every well-run vendor answers "yes" to a capability question. You've collected a wall of yeses and learned nothing that separates them.
- **No scoring model agreed up front.** Responses arrive, and the evaluation becomes a debate about how to evaluate — which is exactly when politics and the last good impression win.

## The honest summary

Treat the RFP as documentation of a decision you're still making, not a form to send out and see what comes back. Its output on paper is a set of proposals; its real output is a treasury team that has argued through — and written down — what it genuinely needs, in priority order, before anyone's judgement gets clouded by a demo.

Get that right and the rest of the [selection process](https://gravam.com/blog/how-to-run-a-tms-selection-process) has a spine: comparable answers, a scored shortlist, and demos that test claims instead of making them. If you're still upstream of all this and want the ground-level definition, start with [what a TMS actually is](https://gravam.com/blog/what-is-a-treasury-management-system) — everything above assumes you already know why you're buying one.

## Questions this article answers

**Q: What is a TMS RFP?**

A TMS RFP (request for proposal) is a structured document you send to a shortlist of treasury management system vendors, setting out your prioritized requirements and asking each vendor to describe — with evidence — how they meet them, plus pricing, implementation approach and company background. Its job is to produce comparable, like-for-like responses you can score against your needs on a common basis, rather than judging vendors on marketing.

**Q: What is the difference between an RFI and an RFP?**

An RFI (request for information) is a lighter, earlier document used to gather basic information from a longlist of vendors and narrow it to a shortlist — it answers 'who is worth talking to?'. An RFP (request for proposal) goes to that shortlist and asks each vendor to propose in detail against your specific requirements so you can select between real contenders. The RFI qualifies; the RFP discriminates. Skipping the RFI and sending a full RFP to twenty vendors wastes everyone's time and buries your team in responses.

**Q: What should a TMS RFP include?**

Company and treasury context and objectives; prioritized functional requirements (cash, connectivity, payments, risk, accounting, reporting); technical, integration and connectivity requirements; security and data-residency requirements; implementation and support expectations; commercial and pricing questions; and vendor/company questions. Each section should be written so answers are comparable, and every requirement should ask 'how do you meet this?' rather than a yes/no that every vendor passes.

---

# Treasury Transformation: A Practical Guide

Source: https://gravam.com/blog/treasury-transformation-guide
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-30
Reviewed: 2026-08-19
Summary: Treasury transformation is upgrading how treasury operates, usually around a new TMS. Why it succeeds on outcomes and delivery discipline, not technology.

**Treasury transformation is the work of significantly upgrading how a company's treasury operates — its systems, processes and capabilities — usually centered on implementing or replacing a [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system) and redesigning the processes and controls around it.** It's a major, cross-functional change programme, and here's the thing most people get wrong about it: it succeeds or fails far less on the _technology_ than on clarity of outcomes, delivery discipline, and adoption. Plenty of transformations install a perfectly good system and still fail to deliver, because the system was the easy part. This is a guide to what treasury transformation actually involves, and what actually determines whether it works.

## What it is

Treasury transformation is _change_, not maintenance: a deliberate, significant upgrade to how [treasury operates](https://gravam.com/blog/what-does-a-corporate-treasury-do). It usually centers on a new or replacement TMS, but it's broader than that: it typically redesigns cash and risk processes, rebuilds [bank connectivity](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), introduces centralization structures, and strengthens controls. The system is the anchor; the transformation is everything reshaped around it.

## What drives it

Transformations start for recognisable reasons, usually several at once:

- **Outgrowing spreadsheets:** cash and complexity scale across more banks, entities and currencies until manual working becomes untenable.
- **M&A:** an acquisition fragments the treasury landscape and forces consolidation.
- **Ageing systems:** an old or unsupported system that has to be replaced.
- **Centralization:** a move to [pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling), an [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank), or a [payment factory](https://gravam.com/blog/what-is-a-payment-factory).
- **Control and audit pressure:** the need for better visibility, [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) and audit readiness.

The common thread: the current way of working can no longer support the business _safely_.

## What it typically involves

A treasury transformation usually spans:

- **A TMS implementation:** selecting and deploying the core system.
- **Process redesign:** reshaping cash, forecasting and risk processes around the new capability.
- **Connectivity:** rebuilding how the company [connects to its banks](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) and moves statements and payments.
- **Centralization structures:** pooling, in-house banking, payment factories.
- **Controls:** embedding segregation of duties and approval workflows.

## Why it's hard

> A treasury transformation touches the money, runs across many functions, and can't disrupt period-end. That combination — high stakes, cross-functional, no room to fail loudly — is what makes it one of the harder programmes a finance function ever runs.

It's cross-functional (treasury, IT, accounting, tax, the business), it carries [data-migration](https://gravam.com/blog/tms-data-migration) risk (opening balances must be exact), it demands genuine [adoption](https://gravam.com/blog/change-management-for-finance-system-rollouts) from risk-averse users, and it can't break the close while it's happening. Any one of those is hard; together they're why transformations so often overrun.

## What actually determines success

Not the technology. The things that decide it are the _delivery_ fundamentals:

- **Clear outcomes.** Defining, up front, [what's true when this is done](https://gravam.com/blog/how-to-define-a-measurable-outcome), and measuring it, rather than installing a system and hoping. Tech-led transformations that skip this build the wrong thing well.
- **Delivery discipline.** [Fit-gap](https://gravam.com/blog/fit-gap-analysis-for-finance-systems), [testing that reconciles the numbers](https://gravam.com/blog/testing-strategy-for-finance-systems), a rehearsed [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems): the unglamorous discipline that separates a smooth go-live from a crisis.
- **Governance.** A structure that can make the [cross-functional decisions](https://gravam.com/blog/governance-and-steering-for-finance-programmes) a transformation constantly throws up.
- **Adoption.** Getting the people to actually use it, because a system nobody adopts delivers no benefit.

→ _The full discipline: [Finance Systems Delivery](https://gravam.com/topics/finance-systems-delivery)._

## The role of the TMS and the architecture

The [TMS](https://gravam.com/topics/treasury-management-systems) is the anchor, but choosing and implementing it well is a discipline in itself, from [build-vs-buy](https://gravam.com/blog/build-vs-buy-treasury-management-system) through [selection](https://gravam.com/blog/how-to-run-a-tms-selection-process) to [implementation](https://gravam.com/blog/treasury-management-system-implementation-guide). And much of the real value and risk lives not in the system but in the [architecture](https://gravam.com/topics/treasury-systems-architecture): the [integrations](https://gravam.com/blog/designing-erp-tms-integration), [formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) and [data model](https://gravam.com/blog/treasury-data-model) that connect it all. A transformation that treats the TMS as the whole job, and the connections as an afterthought, discovers its mistake in testing.

## A sensible sequence

1. **Understand the current state:** what treasury does today, and what's actually broken.
2. **Define the outcomes:** measurable, agreed, before selecting anything.
3. **Select** the right system, for the right reasons.
4. **Implement** with fit-gap discipline and real testing.
5. **Migrate and cut over** cleanly, at a period boundary.
6. **Realize the benefits:** [check they actually landed](https://gravam.com/blog/benefits-realization-for-finance-systems), not just that the system went live.

That sequence is for a deterministic system. Three of its steps behave differently when the thing in the middle is a model — fit-gap, readiness and where the pilot sits — which is the subject of [where to start with enterprise AI](https://gravam.com/blog/where-to-start-with-enterprise-ai).

## Where treasury transformations stall

- **Technology-led, not outcome-led.** Installing a system without clarity on what it's for, so it succeeds technically and fails commercially.
- **Underestimating data and adoption.** Budgeting the software and forgetting the migration and the people: where transformations actually stall.
- **No governance.** Cross-functional decisions with no home, so the programme drifts.
- **Big-bang without discipline.** An ambitious scope with no fit-gap, testing or rehearsal, so the risk all lands at once.
- **Declaring victory at go-live.** Never checking whether the outcomes were achieved.

Treat treasury transformation as a _change programme_ anchored on outcomes and delivered with discipline — not a technology install — and the odds shift dramatically in your favour. The system matters, but it's the smallest part of the story. What determines success is everything this site's [delivery guide](https://gravam.com/topics/finance-systems-delivery) is about: turning a vague ambition into clear outcomes, and delivering them without losing control.

***

_See also [what does a corporate treasury do](https://gravam.com/blog/what-does-a-corporate-treasury-do) and the [Finance Systems Delivery guide](https://gravam.com/topics/finance-systems-delivery)._

## Questions this article answers

**Q: What is treasury transformation?**

Treasury transformation is the work of significantly upgrading how a company's treasury operates (its systems, processes and capabilities), usually centered on implementing or replacing a treasury management system and redesigning the processes and controls around it. It's a major, cross-functional change programme, not just a technology project, and it typically also touches bank connectivity, cash and risk processes, and centralization structures like pooling or an in-house bank.

**Q: What drives a treasury transformation?**

Common triggers include a business outgrowing spreadsheets as cash and complexity increase across multiple banks, entities and currencies; a merger or acquisition that fragments the treasury landscape; the need to replace an ageing or unsupported system; a push to centralize treasury (pooling, in-house banking, payment factories); and pressure to strengthen controls, visibility and audit readiness. Usually it's several of these at once, and the common thread is that the current way of working can no longer support the business safely.

**Q: Why do treasury transformations succeed or fail?**

Treasury transformations succeed or fail far more on delivery discipline than on the technology. The common failure pattern is a technology-led project that installs a system without being clear on the outcomes it's meant to achieve, underestimates data migration and user adoption, and lacks the governance to make cross-functional decisions. Success comes from defining measurable outcomes up front, selecting and implementing the right system with discipline, migrating data cleanly, testing that numbers reconcile, and winning genuine adoption. The system is necessary but never sufficient.

---

# What Does a Corporate Treasury Do?

Source: https://gravam.com/blog/what-does-a-corporate-treasury-do
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Corporate treasury manages a company's money — cash, liquidity, funding and risk. What treasury actually does, and how it differs from accounting.

**Corporate treasury manages a company's money — its cash, liquidity, funding and financial risk, along with the banking relationships, systems and controls behind them.** In plain terms: treasury makes sure there's cash where and when it's needed, sees and moves money across the group, raises and manages the company's funding, protects it against financial risks like currency and interest-rate moves, and runs the systems that make all of that work. If accounting is the company's memory, treasury is its bloodstream — the function that keeps money flowing so the business stays solvent, funded and protected. Here's what that actually involves, and where to go deeper on each part.

## What corporate treasury is

Every company, above a certain size, needs someone whose job is _the money itself_ — not recording it, but managing it: making sure it's there, putting it to work, raising more when needed, and protecting it from the things that can erode it. That's treasury. In a small firm it might be one person wearing several hats; in a large group it's a dedicated function with specialists, policies and systems. The scope is the same either way — cash, liquidity, funding, risk, and the machinery behind them.

## The core responsibilities

### Cash and liquidity management

The day-to-day heart of treasury: knowing how much cash the group has and where, moving it to where it's needed, and — critically — making sure there's always enough available to meet obligations as they fall due. This covers the [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position), [cash forecasting](https://gravam.com/blog/13-week-cash-flow-forecast), [global visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility), and structures like [pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) and [in-house banks](https://gravam.com/blog/what-is-an-in-house-bank).
→ _Full guide: [Corporate Cash & Liquidity Management](https://gravam.com/topics/cash-and-liquidity-management)._

### Funding and capital

Making sure the company has the financing it needs — raising and managing debt, maintaining credit facilities, and keeping enough funding headroom that a shortfall never becomes a crisis. Getting this wrong is [liquidity risk](https://gravam.com/blog/liquidity-risk-management), the one financial risk that actually ends companies.

### Financial risk management

Identifying, measuring and managing the financial risks the business runs — [currency (FX)](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure), [interest rate](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury), and [counterparty](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) risk — so that market moves and partner failures don't threaten the business. The goal is keeping risk within a deliberately chosen appetite, not eliminating it.
→ _Full guide: [Treasury Risk Management](https://gravam.com/topics/treasury-risk-management)._

### Bank relationships and connectivity

Treasury owns the company's relationships with its banks — which banks hold which cash, how [payments and statements move](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), and keeping the account structure and fees under control. The plumbing that connects the company to the banking system is treasury's to design and run.

### Treasury systems and controls

All of the above runs on systems — a [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system), the ERP, bank connections and market data — and on the controls that keep money safe, like [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems). Building and running that landscape well is a discipline in itself.
→ _Full guides: [Treasury Management Systems](https://gravam.com/topics/treasury-management-systems) and [Treasury Systems Architecture](https://gravam.com/topics/treasury-systems-architecture)._

## Treasury vs accounting

The most common point of confusion:

|  | Accounting | Treasury |
| --- | --- | --- |
| **Focus** | Recording what happened | Managing the money |
| **Direction** | Backward (the record) | Forward (what's needed next) |
| **Answers** | "Were we profitable?" | "Do we have the cash — and is it protected?" |
| **Deals in** | Transactions & statements | Cash, funding & risk |

They work hand in hand, but a company can be [profitable and still fail](https://gravam.com/blog/liquidity-risk-management) if treasury doesn't ensure the cash is there. Accounting is the memory; treasury is the money and the future.

## Why treasury matters

Treasury is quiet when it's working and catastrophic when it isn't. It's the function that keeps the company **solvent** (cash to meet obligations), **funded** (financing in place), and **protected** (risks within appetite). None of it shows up in a good quarter — and all of it shows up in a bad one. Treasury's job is to make sure the bad one never becomes fatal.

## How treasury runs

Treasury operates through three things working together: **people** (the treasurers and analysts who make the calls), **policy** (the [risk](https://gravam.com/blog/treasury-risk-management-policy) and cash policies that turn appetite into rules), and **systems** (the technology that gives visibility and control, and enforces the controls). Weakness in any one undermines the others — great people with no system fly blind; a great system with no policy has no guardrails.

## Delivering treasury change

Treasury capabilities don't build themselves — new systems, new processes and whole [treasury transformations](https://gravam.com/blog/treasury-transformation-guide) have to be _delivered_, and that's a discipline of its own: turning vague demands into clear outcomes, and getting through [selection](https://gravam.com/blog/how-to-run-a-tms-selection-process), [implementation](https://gravam.com/blog/treasury-management-system-implementation-guide) and go-live without losing control.
→ _Full guide: [Finance Systems Delivery](https://gravam.com/topics/finance-systems-delivery)._

## Go deeper

This site covers each part of treasury in depth:

- **[Treasury Management Systems](https://gravam.com/topics/treasury-management-systems)** — the systems treasury runs on, from selection to implementation.
- **[Corporate Cash & Liquidity Management](https://gravam.com/topics/cash-and-liquidity-management)** — seeing, moving and forecasting cash.
- **[Treasury Risk Management](https://gravam.com/topics/treasury-risk-management)** — FX, interest rate, counterparty risk and hedging.
- **[Treasury Systems Architecture](https://gravam.com/topics/treasury-systems-architecture)** — how the ERP, TMS, banks and data connect.
- **[Finance Systems Delivery](https://gravam.com/topics/finance-systems-delivery)** — how treasury and finance change actually gets delivered.

Corporate treasury, in one line: it's the function that manages the company's money so the business always has it, uses it well, and doesn't lose it. Everything else is detail — and the guides above are where the detail lives.

## Questions this article answers

**Q: What does a corporate treasury do?**

Corporate treasury manages a company's money — making sure cash is available where and when it's needed (liquidity), seeing and moving cash across the group (cash management), raising and managing funding and debt, managing financial risks such as currency, interest rate and counterparty risk, and running the banking relationships, systems and controls that make it all work. In short, treasury keeps the company solvent, funded and financially protected, day to day and over the long term.

**Q: What is the difference between treasury and accounting?**

Accounting records what has happened — it produces the financial statements and looks backward at transactions. Treasury manages the actual money and looks forward — ensuring there's cash to meet obligations, funding in place, and financial risks controlled. Accounting tells you whether the company was profitable; treasury makes sure it has the cash to keep operating. They work closely together but answer different questions: accounting is about the record, treasury is about the money and the future.

**Q: What are the main functions of corporate treasury?**

The core functions are: cash and liquidity management (knowing and controlling the group's cash, and ensuring liquidity is always available); funding and capital (raising and managing debt and financing); financial risk management (managing FX, interest rate, and counterparty risk); bank relationship management and connectivity; and running the treasury systems and controls that support all of it. Larger treasuries also handle areas like investments, cash pooling, and in-house banking.

---

# How to Run a TMS Selection Process

Source: https://gravam.com/blog/how-to-run-a-tms-selection-process
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-08-02
Reviewed: 2026-09-01
Summary: A TMS selection process is the structured path from ‘we need a system’ to ‘we chose the right one’ — requirements, RFP, scripted demos, scorecard, references.

**A TMS selection process is the structured path from "we need a system" to "we chose the right one" — requirements, RFP, scripted demos, scorecard, references, negotiation.** Its entire purpose is to make the decision on _evidence tied to your needs_, rather than on which vendor gives the best sales pitch. Run it well and you buy the right system for the right reasons, with your eyes open — though [which category of TMS you're choosing between](https://gravam.com/blog/best-treasury-management-system) is the step before this one. Run it as a beauty parade — a few slick demos and a gut call — and you buy the best-presented product, which is a very different thing from the best-fitting one.

## Why a structured process

Buying a TMS is a long, expensive, hard-to-reverse commitment. Vendors are good at selling; their demos are rehearsed to look effortless. Without a structure that forces the comparison onto _your_ requirements, the decision drifts toward whoever performed best in the room — and the gaps only surface in [implementation](https://gravam.com/blog/treasury-management-system-implementation-guide) or, worse, after go-live. The process exists to keep the decision honest.

> The purpose of a selection process isn't procurement box-ticking. It's to make sure you're comparing systems on how well they do _your_ job — not on how well their salesperson does theirs.

## The stages

A sound selection narrows the field, stage by stage, always on evidence:

1. **Requirements.** Define and prioritize what you actually need — the foundation everything else rests on.
2. **Longlist.** Identify the candidate vendors worth approaching — and don't wait for [a Magic Quadrant to hand you the list](https://gravam.com/blog/gartner-magic-quadrant-treasury-management-systems), because there isn't one for TMS. Decide early whether you want one suite or a core you'll extend, because the [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) choice puts different vendors on the list.
3. **[RFP](https://gravam.com/blog/how-to-write-a-tms-rfp).** Issue a structured request against your requirements; gather comparable responses.
4. **Shortlist.** Narrow to two or three real contenders on the RFP evidence.
5. **Scripted demos.** Have each shortlisted vendor run _your_ scenarios.
6. **Score.** Evaluate against a weighted scorecard, as a team.
7. **References & due diligence.** Talk to real customers; check viability and roadmap.
8. **(Proof of concept)** — for higher-risk or complex needs, a hands-on trial.
9. **Negotiate & decide.** Terms, price, implementation — then choose, on the evidence.

## Requirements come first

Everything hinges on this: a selection anchored on a clear, prioritized [requirements set](https://gravam.com/blog/treasury-management-system-requirements-checklist) evaluates vendors against _your needs_. A selection without one evaluates them against _their features_ — and every vendor's features look great in their own demo. Prioritize must-have versus nice-to-have now, because that weighting is what makes the later scoring mean anything.

## The RFP

The RFP turns your requirements into structured questions and asks each vendor how they meet them, plus pricing, implementation approach and company background. Done well it produces _comparable_ answers you can line up side by side. The trap is the generic feature checklist that every vendor ticks "yes" to — ask instead _how_ they meet the requirement, and weight the answers by your priorities. If you'd rather start from a structure than a blank page, there's a [ready-made TMS RFP template](https://gravam.com/tools/tms-rfp-template) you can adapt.

## Scripted demos, not canned ones

The single highest-value stage. Don't watch the vendor's polished standard demo — give each shortlisted vendor _your_ scenarios (your month-end, your payment run, your awkward intercompany case) and watch them do it live. That's where the difference between "we support that" and "here's it working on your problem" appears. This is exactly what the [demo questions and scorecard](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) are for.

## References and due diligence

Talk to _real_ customers — ideally ones like you, and ideally not only the references the vendor hand-picks. Ask what went wrong in their implementation, what support is really like, what they'd do differently. And check the vendor itself: financial viability, product roadmap, how upgrades and support actually work. You're buying a multi-year relationship, not a one-off product.

## Scoring and deciding

Score against a **weighted scorecard** completed by the whole evaluation team — treasury, IT, and the people who'll use it — so the decision reflects prioritized evidence, not the loudest voice or the last good demo. And weigh the things that aren't features: implementation risk and cost, [total cost of ownership](https://gravam.com/blog/tms-pricing-and-licensing-models), and [deployment model](https://gravam.com/blog/saas-vs-on-premise-treasury-management-system). The best-fitting system on paper is a poor choice if it's ruinous to implement or run.

## Why TMS selections go wrong

- **Buying the demo.** Choosing the best presentation instead of the best fit — the classic and most expensive error.
- **No requirements baseline.** Evaluating on vendor features because you never defined your own priorities.
- **Feature-checklist tyranny.** A yes/no matrix everyone passes, revealing nothing about _how well_ each fits.
- **Ignoring implementation and TCO.** Picking on licence price and features, then being blindsided by the cost and risk of actually deploying and running it. With an AI product there is a second cost on your side of the line — the queue of everything it gets wrong — and [pricing that residue](https://gravam.com/blog/evaluating-enterprise-ai-vendor-claims) is part of the evaluation.
- **Decision by loudest voice.** No weighted, team-based scoring, so the choice reflects politics rather than evidence.

Anchor on prioritized requirements, gather comparable RFP evidence, make vendors run _your_ scenarios, score as a team, check real references, and weigh cost and risk alongside features — and TMS selection becomes a decision you can defend and won't regret. The goal isn't the best system; it's the best system _for you_, chosen for reasons you can name. To score the shortlist as a team on weighted criteria, use the free [TMS Vendor Scorecard](https://gravam.com/tools/tms-vendor-scorecard).

***

_See also the [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist) and [vendor demo questions and scorecard](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard)._

## Primary sources

- AFP — Standardized Treasury Management System Request for Proposal — accessed 2026-07-29 — https://www.financialprofessionals.org/home/standardized-treasury-management-system-request-for-proposal
- AFP — How to Evaluate a Treasury Management System Provider — accessed 2026-07-29 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/how-to-evaluate-a-treasury-management-system-provider
- AFP — How to Conduct a Successful RFP for a Financial Service Provider — accessed 2026-07-29 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/how-to-conduct-a-successful-rfp-for-a-financial-service-provider
- Treasury Today — Choosing a treasury management system — accessed 2026-07-29 — https://treasurytoday.com/banking/choosing-a-treasury-management-system/
- The Global Treasurer — Picking Treasury Vendors That Pay Off — accessed 2026-07-29 — https://www.theglobaltreasurer.com/2025/06/04/treasury-implementation-vendor-selection/

## Questions this article answers

**Q: What are the stages of a TMS selection process?**

A structured TMS selection typically runs: define requirements, build a longlist of candidate vendors, issue an RFP against your requirements, narrow to a shortlist, run scripted demos using your own scenarios, score against a weighted scorecard, check references and vendor viability, optionally run a proof of concept, then negotiate and decide. The discipline is that each stage narrows the field on evidence tied to your requirements, rather than on the strength of a sales pitch.

**Q: Where does the RFP fit in a TMS selection process?**

In the sequence set out here, the RFP sits between the longlist and the shortlist. You send candidate vendors a structured document setting out your prioritized requirements and asking each to describe how they meet them, along with pricing, implementation approach and company information. Because the responses come back against the same requirements, they are comparable and evidence-based rather than marketing — and that is what lets you narrow the longlist to the shortlist that goes on to scripted demos and weighted scoring. Practice varies on the exact placement: many teams send a lighter RFI to the longlist first and reserve the full RFP for the shortlist that survives it.

**Q: How do you avoid choosing the wrong TMS?**

Anchor the whole process on your own prioritized requirements, and evaluate vendors against those — not against whoever demos best. Use scripted demos built on your real scenarios so you see the system do your work, not a polished canned flow; score with a weighted scorecard completed by the whole evaluation team; check references with real customers; and weigh implementation cost, total cost of ownership and vendor viability, not just features. The most common mistake is buying the best demo instead of the best fit.

---

# SaaS vs On-Premise Treasury Management System

Source: https://gravam.com/blog/saas-vs-on-premise-treasury-management-system
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-07-29
Summary: Cloud SaaS is the default TMS deployment model; on-premise the exception for control, data-residency or integration. How they differ on cost, upgrades and exit.

**Cloud SaaS is now the default deployment model for treasury management systems; on-premise is the exception, chosen for specific control, data-residency or integration reasons.** In a SaaS model the vendor hosts and runs the system, manages upgrades and keeps it available; on-premise, you own and operate all of that yourself. The choice shapes your [cost model](https://gravam.com/blog/tms-pricing-and-licensing-models), upgrade cadence, [security responsibilities](https://gravam.com/blog/tms-cloud-security-and-data-residency) and how you integrate — and while SaaS is right for most, the point is to choose _deliberately_ for a real reason, not to default into either out of habit or nervousness. (Deployment is the second question, though — [which kind of TMS you're buying at all](https://gravam.com/blog/best-treasury-management-system) comes first.)

## What the two models are

- **SaaS / cloud** — the vendor hosts the application (typically multi-tenant), you access it over the internet, and the vendor runs the infrastructure, upgrades and availability. You configure and use; they operate.
- **On-premise** — the software runs on infrastructure _you_ own and manage. Your team handles hosting, patching, upgrades, backups and availability.
- **(Hosted / private cloud** — a middle ground: single-tenant, vendor- or partner-hosted. Worth knowing it exists, but the core trade-off is SaaS vs on-prem.)

Note this is a _different_ decision from [build vs buy](https://gravam.com/blog/build-vs-buy-treasury-management-system): you can buy a packaged TMS and deploy it either way. Build-vs-buy is _whose software_; SaaS-vs-on-prem is _where and who runs it_.

## Why SaaS became the default

- **No infrastructure to run.** No servers, patching or capacity planning — the vendor's problem.
- **Vendor-managed upgrades.** You stay current automatically, rather than running upgrade projects.
- **Faster to deploy.** No procurement and standing-up of infrastructure before you start.
- **Predictable operating cost.** A subscription (opex) instead of large upfront capital plus a run team.

For most treasuries, these advantages are decisive — which is why new TMS deployments are overwhelmingly SaaS. Strategic Treasurer's Treasury Technology Survey found over 82% of treasury solutions in use were already SaaS-based by 2023, on a track it projects to pass 95% globally by 2026–2027.

## What on-premise still offers

On-prem isn't obsolete; it's _specialised_. It still wins when you need:

- **Data residency / regulatory control** — a hard requirement that data stays in a specific place or environment.
- **Deep customization or integration** — tight coupling to an on-premise landscape, or control the multi-tenant model won't allow.
- **Security policy** — organisations whose policies mandate self-hosting for the most sensitive systems.

If one of these is a genuine, binding constraint, on-prem is the right call. If none is, it's usually just inertia.

## SaaS vs on-premise at a glance

|  | SaaS / cloud | On-premise |
| --- | --- | --- |
| **Who runs it** | Vendor hosts and operates | You host and operate |
| **Upgrades** | Vendor-run, automatic — stay current | Yours to run; easy to defer and stall |
| **Deployment** | Faster; no infrastructure to stand up | Slower; procure and build infrastructure |
| **Cost model** | Subscription (opex), predictable | Upfront licence + hardware + run team (capex) |
| **Security** | Shared — vendor secures infra, you secure data & access | You own the whole stack |
| **Best for** | Most corporates, by default | Binding data-residency, deep integration or policy needs |

## Cost model: capex vs opex

> SaaS shifts spend from **capex to opex**: a predictable subscription instead of upfront licences, hardware and a run team. On-prem can look cheaper on a spreadsheet if you ignore the cost of the people, infrastructure and upgrade projects needed to run it — which is exactly the cost that's easy to forget. Compare [total cost of ownership](https://gravam.com/blog/tms-pricing-and-licensing-models), not licence price.

## Upgrades and staying current

This is the quiet decider. SaaS upgrades are frequent, vendor-run, and mostly unavoidable — which sounds like a loss of control but is actually a gift: you _stay current_ without effort. On-prem puts upgrades in your hands, which means they're easy to _defer_ — and deferred upgrades are how treasuries end up stranded on an old, unsupported version that's expensive and risky to move off. The freedom to not upgrade is a trap.

## Security is shared, either way

Moving to SaaS does **not** outsource your security. The **shared responsibility model** splits it: everything the vendor hosts — infrastructure, platform, application — is theirs to secure; your data, user access, [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) and secure configuration stay yours. Gartner's prediction for the years through 2025 — that 99% of cloud security failures would be the customer's fault — is the shape of what I saw over that period too: the incidents were misconfiguration and access mistakes, not vendor breaches. On-prem, you own the whole stack — more control, and more to get wrong.

## How to decide

1. **Start from SaaS as the default.** It's right for most; make it the baseline.
2. **Test for a real on-prem reason.** Is there a _binding_ data-residency, integration or policy constraint? If yes, on-prem or private-hosted. If no, stay with SaaS.
3. **Compare true TCO**, including the people and upgrades on-prem requires.
4. **Check the exit.** How do you get your data out, and move, if you leave the vendor? Ask before you sign, not after.

## Hosting model choices that age badly

- **On-prem by inertia.** Chosen out of "we host everything," then under-invested — so it's never upgraded and slowly rots.
- **SaaS without checking constraints.** Signing up before confirming data-residency or an integration the multi-tenant model can't support.
- **Assuming SaaS = secure.** Treating the vendor's security as total and neglecting customer-side access controls.
- **Ignoring exit.** No thought to data portability, so a later switch is far harder than the first purchase.

Default to SaaS, choose on-premise only for a real and binding reason, compare genuine total cost, and check your exit before you commit — and the deployment decision becomes one you won't regret in three years. Then the harder work — [selecting the right vendor](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) and [implementing well](https://gravam.com/blog/treasury-management-system-implementation-guide) — is where your attention belongs. Deployment model belongs as a weighted criterion in that comparison, and the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) gives you a ready-made place to score it alongside everything else.

***

_See also [build vs buy a TMS](https://gravam.com/blog/build-vs-buy-treasury-management-system), [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) — the other axis of the same architecture decision — and [the TMS requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist)._

## Primary sources

- NIST SP 800-145 — Software as a Service (SaaS) definition (CSRC glossary) — accessed 2026-07-29 — https://csrc.nist.gov/glossary/term/software_as_a_service
- AWS — Shared Responsibility Model — accessed 2026-07-29 — https://aws.amazon.com/compliance/shared-responsibility-model/
- TIS — Seven Key Findings from the 2023-2024 Treasury Technology Survey (Strategic Treasurer) — accessed 2026-07-29 — https://tispayments.com/blog/seven-key-findings-from-the-2023-2024-treasury-technology-survey/
- ACT, The Treasurer — Cloud technology and the treasury — accessed 2026-07-29 — https://www.treasurers.org/hub/treasurer-magazine/cloud-technology-and-treasury
- CIO — The top cloud security threat comes from within (Gartner prediction) — accessed 2026-07-29 — https://www.cio.com/article/416343/the-top-cloud-security-threat-comes-from-within.html

## Questions this article answers

**Q: What is the difference between SaaS and on-premise treasury systems?**

A SaaS (cloud) treasury system is hosted and run by the vendor; you access it over the internet and the vendor manages the infrastructure, upgrades and availability. An on-premise system is installed on infrastructure you own and run, so your team is responsible for hosting, upgrades, security patching and availability. SaaS trades control for convenience and a predictable operating cost; on-premise trades convenience for control and deep integration with your own environment.

**Q: Is SaaS or on-premise better for a TMS?**

For most corporates today, SaaS is the better default: no infrastructure to run, vendor-managed upgrades that keep you current, faster deployment, and a predictable subscription cost. On-premise is better only for specific reasons — strict data-residency or regulatory constraints, a need for deep customization or integration to an on-premise landscape, or security policies that require it. Choose on-premise deliberately for a real reason, not out of habit.

**Q: Who is responsible for security in a SaaS treasury system?**

Security is shared. The vendor's half covers what they host — infrastructure, platform, application; your half covers your data, user access, segregation of duties, and how your people use the system. This 'shared responsibility model' is a common source of confusion — moving to SaaS does not outsource your access controls or your obligation to configure the system securely, it only moves the infrastructure layer to the vendor.

---

# Build vs Buy a Treasury Management System

Source: https://gravam.com/blog/build-vs-buy-treasury-management-system
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-07-29
Summary: For almost every corporate, buying a TMS beats building one, because a package embeds decades of connectivity and compliance. When build makes sense, and why.

**For almost every corporate, buying a treasury management system beats building one.** A packaged TMS already embeds decades of bank connectivity, statement and payment formats, valuation logic and regulatory compliance — everything you would otherwise have to build from scratch and then maintain _forever_. Treasury technology is rarely a company's competitive differentiator, and the true cost of "build" isn't the first version — it's the permanent obligation to keep it current as banks, formats and regulations change underneath it. Build only in genuinely rare cases; for the rest, the honest answer is buy, and the real skill is buying _well_.

## The question

"Build vs buy" sounds like a technology decision. It's really a _focus_ decision: is running treasury software something your company should be in the business of doing? For a bank or a fintech, maybe. For a manufacturer, a retailer, a services firm — almost certainly not. The question isn't "can we build it?" (you probably can) but "should we own it forever?"

## Why buy wins for almost everyone

A packaged TMS gives you, on day one, things that took the vendor years and hundreds of customers to build:

- **Bank connectivity** — [SWIFT, host-to-host, EBICS, API](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) — already built, tested and maintained.
- **Formats** — [MT940, camt, pain.001](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) and their endless bank-specific variations, handled.
- **Domain logic** — valuation, exposure, accounting, already encoded.
- **Compliance** — regulatory changes delivered as updates, not projects.
- **Upgrades** — someone else's job to keep it modern.

You're not buying software; you're buying _not having to build and maintain all of that_.

## The real cost of build

The trap in build is that the first version looks affordable. The bill arrives afterwards, forever:

> A bought TMS is cheap to change and expensive to buy. A built TMS is cheap to start and expensive to never stop paying for. The build cost you can't see is the one that matters.

Banks change formats. New banks get added. Regulations shift. Every one of those is development and testing you now own alone — where a vendor spreads it across its whole customer base. And it requires a _permanent_ team: build a TMS, and you've committed to staffing treasury-software engineers indefinitely, or watching your system rot.

| Dimension | Build | Buy (packaged TMS) |
| --- | --- | --- |
| Upfront cost | Cheap to start | Licence + implementation |
| Lifetime cost | Expensive to never stop paying | Maintenance spread across the vendor's customers |
| Connectivity & formats | Build and maintain yourself | Already embedded (SWIFT, MT940, camt, pain.001) |
| Compliance | Your ongoing development | Delivered as vendor updates |
| Team | Permanent treasury-software engineers | Configure; no core engineering |
| Upgrades | Your job forever | Someone else's job |
| When it fits | Rare genuine differentiator | Almost every corporate |

## The spreadsheet is a third option — with a ceiling

Many treasuries "build" without noticing, in Excel. It's the cheapest possible start and genuinely fine at small scale. But it hits a hard [ceiling](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets): no controls, no audit trail, no [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems), key-person risk, and errors that scale with the business. The spreadsheet isn't build vs buy — it's the thing you're deciding to _replace_.

## Build vs buy vs configure

The most important nuance: **packaged systems are configured, not built.** A good TMS is designed to be tailored — to your entities, accounts, workflows — through [configuration, not custom code](https://gravam.com/blog/configuration-vs-customization-finance-systems). The failure mode is buying a package and then _customizing it so heavily it becomes a bespoke build_: you inherit build's maintenance burden and lose buy's upgradeability. This is exactly what [fit-gap discipline](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) protects against — close gaps by configuration or process change, and reserve true customization for the rare gap that warrants it.

## How to decide

Three tests:

- **Differentiation.** Is your treasury process a genuine competitive advantage, or just familiar? Build only for genuine, defensible differentiation.
- **Total cost of ownership.** Compare buy's licence + implementation against build's _lifetime_ — initial build plus permanent maintenance and staffing. Honest TCO almost always favours buy.
- **Risk and focus.** Can you keep a treasury-software team current forever? Do you want that to be a thing your company does?

## Build vs buy traps that cost the most

- **Build hubris.** "We can build something better/cheaper" — true for v1, false across the decade of maintenance nobody costed.
- **Underestimating maintenance.** Budgeting the build, not the forever.
- **Buying then over-customizing.** Turning a package into a de facto build and getting the worst of both.
- **Confusing configure with build.** Treating necessary configuration as if it were bespoke development, or vice versa.

For the overwhelming majority of corporates, the answer is buy a packaged system and configure it well. Spend your energy not on building the software, but on [selecting the right one](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) and [implementing it properly](https://gravam.com/blog/treasury-management-system-implementation-guide) — that's where the value and the risk actually live. When you reach a shortlist, score the candidates on your own weighted priorities with the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) rather than a feature count. And "the right one" starts with [which category of TMS fits you](https://gravam.com/blog/best-treasury-management-system) — the market splits into four kinds, and knowing yours narrows everything downstream.

***

_See also [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) — buying doesn't end the architecture question — and [the TMS business case](https://gravam.com/blog/treasury-management-system-business-case)._

## Primary sources

- EBICS — Electronic Banking Internet Communication Standard (EBICS SC) — accessed 2026-07-29 — https://www.ebics.org/en/home
- AFP — Best Practices in Treasury Connectivity (channels, formats, vendor-maintained bank connections) — accessed 2026-07-29 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/best-practices-in-treasury-connectivity
- AFP — Treasury Management System: Overview, Functionalities and Benefits — accessed 2026-07-29 — https://www.financialprofessionals.org/glossary/treasury-management-system
- Nordea — Message Implementation Guideline camt.053.001.02 (BankToCustomerStatement) — accessed 2026-07-29 — https://www.nordea.com/en/doc/nordea-mig-camt-053-001-02-bank-to-customer-statement.pdf
- Nordea — Message Implementation Guideline pain.001.001.03 (CustomerCreditTransferInitiation) — accessed 2026-07-29 — https://www.nordea.com/en/doc/nordea-message-implementation-guide-cap-pain.001.001.03.pdf
- Westpac BankRec — MT940 statement format — accessed 2026-07-29 — https://bankrec.westpac.com.au/docs/statements/mt940/

## Questions this article answers

**Q: Should you build or buy a treasury management system?**

For almost every corporate, buying beats building. A packaged TMS already embeds decades of bank connectivity, statement and payment formats, valuation logic and regulatory compliance — all of which you would otherwise have to build and then maintain forever. Building only makes sense in rare cases where treasury technology is a genuine competitive differentiator and you have a permanent software team to own it, which is almost never true for a corporate treasury.

**Q: Why is building a treasury system so expensive?**

Because the cost isn't the first version — it's forever. Bank connectivity and message formats change, regulations evolve, banks are added and removed, and every one of those requires ongoing development and testing. A packaged vendor spreads that maintenance across hundreds of customers; if you build, you carry all of it alone, permanently, with a team you have to keep staffed and current. The build is cheap to start and expensive to never stop paying for.

**Q: Is configuring a packaged TMS the same as building one?**

No — configuring a packaged TMS is not building one, and the distinction matters. Packaged systems are meant to be configured — tailored to your entities, accounts and processes through settings, not code. Building means creating the core capability from scratch. The danger is buying a packaged system and then customizing it so heavily that it becomes a de facto bespoke build, inheriting the maintenance burden of build with none of the benefits — the worst of both worlds.

---

# TMS Vendor Demo Questions and Evaluation Scorecard

Source: https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: How to evaluate TMS vendors: the questions to ask in a demo, and a weighted scorecard to compare them — driven by your requirements, not their sales script.

**Evaluate TMS vendors against your own prioritized requirements using a weighted scorecard, and drive the demos with your scenarios and hard questions — not the vendor's script.** Score each on functional fit, bank connectivity, integration, implementation approach and viability, weighted by what actually matters to you. The vendor with the best-looking demo is not the same as the one that best fits your needs — and telling them apart is the whole job.

This gives you the questions to ask and a scorecard to compare vendors fairly. It assumes the field is already narrowed — usually by a [TMS RFP](https://gravam.com/blog/how-to-write-a-tms-rfp) built from something like the [TMS RFP template](https://gravam.com/tools/tms-rfp-template) — so the demos are a shortlist exercise, not a first look.

## Don't let the vendor run the demo

A vendor demo is designed to impress on the vendor's strengths, using the vendor's clean data and happy path. If you sit back and watch, you learn what they're good at, not whether they fit _you_. So take control: send every vendor the **same handful of your real scenarios** in advance, and make the demo about those.

> Give each vendor identical scenarios: "build our position from these bank statements," "run this payment through an approval flow like ours," "produce a forecast from data like ours." Same scenarios, same scoring, every vendor. It turns a beauty parade into a comparison.

## Questions to ask in a TMS demo

### Cash & forecasting

- [ ] Build today's group cash position live from statements like ours — how many clicks, how much manual work?
- [ ] Show a forecast built from data like ours; how is accuracy measured over time?
- [ ] How does it handle our entity and currency structure?

### Bank connectivity

- [ ] Which of _our specific banks_ do you have pre-built connectivity for?
- [ ] What formats and channels (SWIFT, host-to-host, EBICS, API; MT940, camt.053, pain.001)?
- [ ] How long does onboarding a new bank typically take, and who does the work?

### Payments

- [ ] Show a payment through an approval workflow and segregation of duties like ours.
- [ ] How is the full audit trail — who approved what, when — exported?
- [ ] Sanctions / compliance screening: built in or integrated?

### Risk & accounting

- [ ] Show FX exposure capture, valuation and hedge accounting (if relevant to us).
- [ ] How are accounting entries generated and posted back to _our_ ERP?

### Integration & implementation

- [ ] How does this integrate with our ERP — real interfaces, documented APIs?
- [ ] Walk us through a typical implementation: phases, timeline, who does the work.
- [ ] What are the most common reasons your implementations run late?
- [ ] How is data migration handled?

### Vendor & support

- [ ] What does support look like after go-live? SLAs?
- [ ] What's on the product roadmap, and how often do you release?
- [ ] Reference customers of our size and complexity we can speak to?

## The evaluation scorecard

Score each vendor 1–5 on each dimension, weight by importance to you, and total. The weights matter as much as the scores — set them from your priorities _before_ you see the demos, so a polished presentation can't quietly re-weight your judgement.

| Dimension | Suggested weight | What you're scoring |
| --- | --- | --- |
| **Functional fit** | 30% | Coverage of your prioritized must/should requirements |
| **Bank connectivity** | 20% | Pre-built coverage for _your_ banks, formats, onboarding effort |
| **Integration** | 15% | Clean, documented ERP integration; realistic effort |
| **Implementation** | 15% | Credible approach, timeline, who does the work, references |
| **Vendor viability** | 10% | Stability, roadmap, support, reference quality |
| **Total cost of ownership** | 10% | Licence + implementation + run, over the horizon |

**Weighted score = Σ (dimension score × weight).** Do it for every vendor on the same scenarios, and the winner is visible in the numbers — not in whose demo felt best.

> Don't rebuild this in a spreadsheet — use the free [**interactive TMS vendor scorecard**](https://gravam.com/tools/tms-vendor-scorecard): set your weights, score each vendor 1–5, and the weighted totals and ranking update live. Export to CSV when you're done. Nothing you enter leaves your browser.

> Notice functional fit is only 30% and licence price only 10%. That's deliberate. Most failed selections over-weight the feature list and the licence, and under-weight connectivity and implementation — the things that actually decide whether the system works and goes live on time.

## What a passing answer has to show

A question only works if you know what a _good_ answer looks like — otherwise a confident non-answer scores the same as real evidence. Set the evidence bar before the demo, and score against it.

| Question | A weak answer (score low) | The evidence you actually need |
| --- | --- | --- |
| Which of _our_ banks are pre-built? | "We support all major banks" | Named coverage for _your_ banks, with the format/channel for each |
| Build our position live | A polished, canned happy-path | _Your_ statements, the click-count and every manual step exposed |
| Typical implementation? | "Usually a few months" | A phase plan, who staffs it, and the named reasons projects slip |
| ERP integration? | "We have an API" | A documented interface, a real effort estimate, a reference doing it |
| Forecast accuracy | "Highly accurate" | _How_ accuracy is measured and improved over time, on data like yours |

The pattern: a passing answer is **specific to you and shows the work**; a failing one is a confident generality. Score the generalities down, however smooth they sound.

## How to score fairly

- **Same scenarios, same scorers.** One panel scoring every vendor against identical scenarios.
- **Score during, decide after.** Fill the scorecard right after each demo while it's fresh; compare totals once all are in.
- **Tie requirements to scores.** Each functional line should trace to your [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist), so "fit" means fit to _your_ must-haves.

## How demos distort a TMS scorecard

- **Demo dazzle.** Choosing the slickest presentation, which rewards presentation skill, not fit.
- **Feature-counting.** Picking the longest feature list instead of the best fit to prioritized needs.
- **Ignoring connectivity and implementation.** The two dimensions that most determine success, most often under-scored because they're less exciting in a demo.
- **No weights up front.** Setting importance after the demos, so the impressive vendor retroactively looks essential.

The same discipline matters more, not less, when the product's central claim is about accuracy — a probabilistic system's demo is not a fair sample of its behaviour, which changes what you have to ask. See [how to judge an enterprise AI vendor's claims](https://gravam.com/blog/evaluating-enterprise-ai-vendor-claims).

## Making the decision

Combine the weighted scores with the business case and the references. The right choice is the vendor that best fits your prioritized requirements, connects to your banks, integrates cleanly and can be implemented realistically — proven on your scenarios, scored on your weights. Then the hard part begins: implementing it without losing control.

***

_Build your requirements first ([checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist)), then the [business case](https://gravam.com/blog/treasury-management-system-business-case), then plan the [implementation](https://gravam.com/blog/treasury-management-system-implementation-guide)._

## Questions this article answers

**Q: How do you evaluate a treasury management system vendor?**

Score each vendor against your own prioritized requirements using a weighted scorecard — functional fit, bank connectivity, integration, implementation approach and vendor viability — and drive the demos with your own scenarios and hard questions rather than the vendor's script. Weight the dimensions by what matters to you, run the same scenarios for every vendor, and decide on fit and total effort, not on which demo was most polished.

**Q: What questions should you ask in a TMS demo?**

Ask them to run your real scenarios — build today's position from your banks, run a real payment with your approval flow, show a forecast from your data. Then probe connectivity (which of my banks are pre-built?), integration (how does this connect to my ERP?), implementation (typical timeline, who does the work, what goes wrong?), data migration, and support and roadmap. Avoid letting them demo only their happy path.

**Q: What matters most when selecting a TMS?**

Fit against your prioritized must-haves, the strength and coverage of bank connectivity for your banks, a realistic integration and implementation path, and vendor viability. Licence price matters least of these — a cheap system with poor connectivity or a painful implementation costs far more overall. Weight your scorecard accordingly.

---

# Treasury Management System Implementation Guide

Source: https://gravam.com/blog/treasury-management-system-implementation-guide
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: How a TMS implementation really runs: mobilize, design, bank connectivity, data migration, testing, cutover, hypercare. The phases, timeline and critical path.

**A TMS implementation runs in phases — mobilize, design, build, bank connectivity, data migration, testing, cutover and hypercare — usually over several months to more than a year, with bank connectivity and data migration as the real critical paths.** The software configuration is rarely what takes the time. What takes the time is everything around it: onboarding banks, cleaning and migrating data, testing properly, and running it as a treasury change programme rather than an IT install.

This guide walks the whole thing end to end (the phases, what each one delivers, a realistic timeline and what actually moves it, and the team you need) so you can plan a programme that goes live on schedule instead of one that discovers connectivity and data three months in. If you're still deciding what a TMS is or whether you need one, the [overview](https://gravam.com/blog/what-is-a-treasury-management-system) sits under all of it.

## The shape of a TMS implementation

At a high level, every implementation moves through the same arc, even if the labels differ by vendor and method:

1. **Mobilize & scope:** team, governance, requirements, plan.
2. **Design:** target operating model and the configuration decisions.
3. **Build & configure:** set the system up to the design.
4. **Bank connectivity:** statements and payments, live with every bank _(runs in parallel from early)_.
5. **[Data migration](https://gravam.com/blog/tms-data-migration):** clean and load master and open data.
6. **Testing:** system integration testing, then user acceptance testing.
7. **Cutover & go-live:** the controlled switch to the new system.
8. **Hypercare:** intensive support after go-live.

The mistake is to run these strictly in sequence. Bank connectivity and data cleaning have long lead times and external dependencies, so they start early and run alongside build, not after it.

## Phase 1: Mobilize & scope

Stand up the programme before the software. Name a **single accountable owner** for the outcome, embed treasury subject-matter experts (not part-time advisors), and put a technical/integration lead and a data owner in place. Confirm scope against a **prioritized requirements list** (see the [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist)) and agree governance: who decides, how changes are controlled, and how risks, assumptions, issues and dependencies are surfaced — a [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) reviewed at every steering meeting is the minimum (there's a free [RAID log template](https://gravam.com/tools/raid-log-template) if you need one).

**Delivers:** charter, team and RACI, agreed scope, plan, governance.

## Phase 2: Design

Design the target operating model, then the configuration to support it. The single most consequential decision here is the **system of record** (which system owns bank master data, payment status, exposures), especially where a TMS coexists with an ERP. Every boundary you leave ambiguous here comes back later as a reconciliation job that never ends.

**Delivers:** target operating model, configuration/design document, integration design, [system-of-record map](https://gravam.com/tools/system-of-record-map).

## Phase 3: Build & configure

Configure the system to the design: entities, accounts, workflows, limits, accounting rules, reports. Keep it anchored to the design and the requirements, not to whatever the demo showed or a stakeholder asks for mid-flight. Undisciplined scope here is how a system ends up doing many things adequately and your two real needs poorly. If the scope is genuinely large, phase it — cash visibility first, payments and risk after — which is the strongest argument on the modular side of the [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) choice.

**Delivers:** configured system in a build/test environment; interface build underway.

## Phase 4: Bank connectivity (the critical path)

Start this early and treat it as the critical path it almost always is. For each bank you must agree the channel (SWIFT, host-to-host, EBICS, API), the statement formats (MT940, camt.053, BAI2) and payment formats (pain.001 / ISO 20022, local formats), then test statements in and payments out end to end, including acknowledgements (pain.002).

The software can be "live" in a test environment in weeks; then you wait for the banks. Each bank channel is its own small project, and every step of it runs on the bank's timeline, through the bank's implementation team, in the bank's queue — not yours. Multiply that by the number of banks and regions in scope and you have the single biggest variable in the plan.

> The software config is on your schedule. The banks are on theirs. Plan the banks first and the configuration second — never the other way around.

A programme that starts talking to its banks in the first fortnight has options; one that starts three months in has a slipped go-live it hasn't discovered yet.

**Delivers:** each bank connected and tested for statements and payments.

## Phase 5: Data migration

Migrate master data (bank accounts, counterparties, cost centres, signatories, payment details) and open items (deals, loans, investments). The rule that saves programmes: **clean the data before you migrate it, and give it an owner.** Migrating dirty master data "to fix later" is how a wrong-account payment or an unreconcilable position traces back, months on, to a record no one owned.

**Delivers:** cleaned, migrated, reconciled data; migration and reconciliation controls.

## Phase 6: Testing

Test in two passes. **System integration testing (SIT)** proves the system and its interfaces work together: ERP in, bank flows out, accounting back. **User acceptance testing (UAT)** proves it works for the people who'll run it, against real business scenarios: a real month-end, a real payment run, a real forecast. Protect this window; it's the one most often squeezed when earlier phases run long, which just moves the defects into production.

Train alongside UAT, not after it: the treasury team should learn the real configured system, with its workflows and approval chains, not a generic vendor demo — and the people doing UAT are the first ones who need to be fluent.

**Delivers:** passed SIT and UAT; a defect log worked down to an agreed go/no-go bar; a trained treasury team.

## Phase 7: Cutover & go-live

Cutover is the controlled switch from old to new. Plan it as a sequenced runbook (final data loads, connectivity cutover, reconciliation, sign-offs) and rehearse it with at least one **dry run**. Gate go-live on an explicit **readiness assessment**, not a calendar date.

- [ ] Data migrated and reconciled; balances tie out
- [ ] All banks connected and confirmed in production
- [ ] UAT passed; open defects within the agreed threshold
- [ ] Cutover runbook rehearsed (dry run completed)
- [ ] Roll-back plan defined
- [ ] Users trained; support model stood up
- [ ] Go/no-go decision taken by the accountable owner

An expanded, interactive version of this list, where the critical items gate the verdict, is the [cutover and go-live checklist](https://gravam.com/tools/cutover-go-live-checklist); work through it before the go/no-go meeting, not in it.

**Delivers:** live system; signed-off go-live.

## Phase 8: Hypercare

For the first weeks after go-live, run intensive support: the project team stays close, issues are triaged fast, and the first real month-end is treated as part of the programme, not "business as usual." Exit hypercare on stability criteria, not a date.

**Delivers:** stabilized operation; formal handover to run-and-maintain.

## A realistic timeline

Resist a fixed number; it's driven by scope. When someone asks me how long "a TMS implementation" takes, my honest first answer is a question: how many banks, how many entities, how many modules? What actually moves it:

| Driver | Faster | Slower |
| --- | --- | --- |
| **Banks to onboard** | 1–2 | Many, across regions (each an independent lead time) |
| **Entities & currencies** | Single | Many, global |
| **Scope** | Cash visibility only | Cash + payments + risk + accounting |
| **Integration** | One clean feed from ERP | Several source systems, market data, GL write-backs |
| **Data quality** | Clean already | Needs remediation |
| **Decision-making** | One accountable owner | Committee, slow sign-off |

A tightly scoped, few-banks implementation can be a few months. A multi-bank, multi-entity global rollout with full scope is comfortably a year or more, and the difference is mostly connectivity, data and decision speed, not the software. Treat anyone who quotes one exact figure without first asking about your bank count, entity count and module scope as guessing: they might be close by luck, but not by method.

### Where the time actually goes

The timeline in the vendor's sales deck is a configuration timeline, and it's usually accurate about configuration — that part genuinely moves fast. It just isn't where implementations slip. They slip on **bank onboarding**, because the banks move at their own pace and there are more of them than the plan assumed; on **data migration**, because the master data turned out dirtier than anyone admitted and cleaning it wasn't scheduled; and on **decision latency**, the days and weeks lost waiting for a design decision no single person felt able to make. A committee that meets fortnightly to ratify design choices quietly adds weeks between every phase.

None of those three is about the software, which is why the fix is the sequencing rule from the top of this guide, not a scheduling trick: connectivity and data cleaning from the opening weeks, in parallel with the build, and a protected testing window at the end.

## The team you need

| Role | Owns |
| --- | --- |
| **Programme owner (treasury)** | The outcome, end to end: accountable, not a committee |
| **Treasury SMEs** | The business design; how cash, payments and risk actually run |
| **Technical / integration lead** | ERP and bank interfaces, environments |
| **Data owner** | Master-data quality, migration, reconciliation |
| **Vendor / implementation partner** | Product configuration and method |
| **Test lead** | SIT and UAT, scenarios, defect triage |

## Where implementations go off the rails

Every failure pattern here has the same root: the change is treated as software, not treasury. It's covered in depth in [why TMS implementations fail](https://gravam.com/blog/why-tms-implementations-fail), but the short version is: own the outcome, start connectivity and data early, be honest about what a forecast can do in year one, and protect testing. Do that and the phases above go from a gamble on the vendor to a change you're genuinely running.

***

_See also the [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist), [why implementations fail](https://gravam.com/blog/why-tms-implementations-fail) and the wider [treasury transformation guide](https://gravam.com/blog/treasury-transformation-guide)._

## Questions this article answers

**Q: What are the phases of a TMS implementation?**

Typically: mobilize and scope, design (target operating model and configuration decisions), build and configure, bank connectivity, data migration, testing (system integration testing then user acceptance testing), cutover and go-live, and hypercare. Bank connectivity and data run in parallel from early on because they are the usual critical paths.

**Q: How long does a TMS implementation take?**

It depends almost entirely on scope. A focused single-entity, few-banks cash implementation is typically a matter of months; a multi-entity, multi-bank, multi-module programme runs considerably longer — often past a year. Anyone quoting one exact number without knowing your bank, entity and module count is guessing. The software configuration is rarely the long pole.

**Q: What makes a TMS implementation take longer?**

The number of entities, banks and connections; the number of modules in scope (cash only versus cash plus risk plus payments); integration complexity; data quality; and how quickly the organisation makes decisions. Timelines slip on bank onboarding, data migration and decision latency — not on configuring the software.

**Q: Who should own a TMS implementation?**

Treasury should own it, as a treasury change programme, not IT, and not the vendor. You need a single accountable owner for the outcome, treasury subject-matter experts embedded (not just consulted), a technical/integration lead, a data owner, and clear governance. The most common failure is running it as an IT install with treasury on the sidelines.

---

# Building the Business Case for a Treasury Management System

Source: https://gravam.com/blog/treasury-management-system-business-case
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-02
Summary: How to build a credible TMS business case: the quantifiable benefits, the full cost of ownership, and how to make it stand up to CFO scrutiny.

**The business case for a TMS rests on quantifiable benefits — optimized cash, efficiency, error and fraud reduction, and better risk decisions — set against the full cost of ownership, plus the control and resilience value that's real but harder to put a number on.** "It'll pay for itself" is not a business case. A credible one ties every benefit to a specific problem the system solves, measures it against today's baseline, and uses numbers conservative enough to survive CFO scrutiny.

Here's how to build one that stands up.

## Why "it'll pay for itself" isn't a business case

Treasury teams often justify a TMS on intuition — everyone can see the spreadsheets are painful. But a CFO approving spend wants to know _how much_ pain, _worth how much_, against _what cost_, versus _what alternative_. If you can't put defensible numbers on it, the project competes badly against ones that can. The discipline of quantifying also sharpens your own thinking about what the system must actually deliver.

## The benefit categories

Build the case from these, quantifying each against a measured baseline of how things work today.

- **Optimized cash.** The headline lever. Accurate, timely visibility of group cash lets you reduce idle balances, cut short-term borrowing, and put surplus to work. Even a modest reduction in average idle cash or borrowing, applied to real balances and rates, is often the single biggest number in the case.
- **Efficiency.** Automating position-building, statement reconciliation and payments frees skilled people from manual work. Quantify it as time saved on specific tasks (hours per day building the position, per month on reconciliation), valued at loaded cost.
- **Error and fraud reduction.** Fewer manual touch-points and enforced payment controls reduce costly errors and fraud exposure. Harder to quantify precisely; base it on your own incident history and the cost of a single serious event avoided.
- **Better FX and risk decisions.** Seeing exposures clearly and in time supports better hedging and fewer surprises. Value it against the cost of exposures currently managed late or in a spreadsheet.
- **Control, audit and resilience.** A clean audit trail, enforced segregation of duties, and not depending on one analyst's workbook. Genuinely valuable, legitimately hard to quantify — present it as risk reduction, not a hard saving.

> Split benefits into "hard" (defensible numbers a CFO will accept) and "soft" (real but not easily quantified). Build the financial case on the hard numbers alone, and present the soft benefits as additional upside. A case that _needs_ the soft benefits to work won't be believed.

## The cost side: total cost of ownership

Cost is more than the licence — understating it is the fastest way to lose credibility later.

- **Licence / subscription** — the recurring software cost.
- **Implementation** — vendor/partner fees, and often the larger line: your own people's time, bank onboarding, data migration and testing.
- **Run** — ongoing support, connectivity, upgrades, admin.
- **Internal effort** — the team's time during and after the project, which the licence quote never includes.

State cost over the same multi-year horizon as the benefits, so the comparison is fair.

## A simple business-case framework

Keep it transparent:

1. **Baseline** — quantify today's cost and risk (idle cash, borrowing, hours spent, incidents).
2. **Benefits** — by category, hard numbers, conservative assumptions, tied to the baseline.
3. **Cost** — total cost of ownership over the horizon.
4. **Net benefit & payback** — benefits minus cost per year; when it turns positive.
5. **Non-financial** — control, audit, resilience, as risk reduction.
6. **Cost of doing nothing** — what the risk and inefficiency compound to if you don't act.

The output isn't a single ROI number; it's a defensible story: _here's the problem, here's what it costs us today, here's what fixing it is worth, here's what it costs to fix, and here's why waiting is expensive._

## Where business cases fall apart

- **Overstated soft benefits.** Leaning on "better decisions" and "efficiency" without a baseline. One challenged assumption and the whole case wobbles.
- **Understated cost.** Quoting the licence and forgetting implementation, connectivity, data and internal effort. Credibility evaporates when the real bill lands.
- **No baseline.** Claiming savings with nothing to measure against. If you can't say what it costs today, you can't prove what you'll save.
- **Ignoring the alternative.** Not comparing against the cheaper option — your ERP's treasury module, or a better spreadsheet process — so the case looks like advocacy, not analysis. (See [TMS vs ERP vs spreadsheets](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets).)

## Making it credible to the CFO

Lead with the problem and the baseline, not the solution. Use conservative, traceable numbers and show your assumptions. Build the financial case on hard benefits alone. Present control and resilience as risk reduction. And frame the cost of doing nothing honestly — because the strongest treasury business cases are as much about the risk you're carrying today as the efficiency you'd gain.

**Build yours:** the free [TMS Business-Case Calculator](https://gravam.com/tools/tms-business-case-calculator) turns your own numbers — hours saved, idle cash mobilized, fees and losses avoided — into annual benefit, payback period and simple ROI you can copy straight into the paper.

***

_See also [whether you need a TMS at all](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets) and the [implementation guide](https://gravam.com/blog/treasury-management-system-implementation-guide)._

## Questions this article answers

**Q: How do you justify a treasury management system?**

Quantify the benefits against the full cost of ownership. Benefits usually come from optimized cash (less idle cash and borrowing, better yield), efficiency (time saved on positioning, reconciliation and payments), error and fraud reduction, and better FX and risk decisions — plus control and audit value that's real but harder to quantify. Cost is licence plus implementation plus run plus internal effort. Anchor every benefit to a specific problem the system solves and a baseline you can measure.

**Q: What is the ROI of a treasury management system?**

The ROI of a treasury management system varies widely by company, but the biggest levers are usually cash optimization and efficiency: seeing group cash accurately lets you reduce idle balances and short-term borrowing, and automation frees skilled people from manual position-building and reconciliation. State ROI as net benefit against total cost of ownership over a few years, using conservative, defensible numbers — an overstated soft-benefit case is the fastest way to lose CFO trust.

**Q: What should a TMS business case include?**

A clear problem statement, a measurable baseline (today's cost and risk), quantified benefits by category, the full cost of ownership (licence, implementation, run, internal effort), a net-benefit and payback calculation, the non-financial benefits (control, audit, resilience), and the risks of doing nothing. Keep the numbers conservative and traceable.

---

# Why TMS Implementations Fail (and How to De-Risk Yours)

Source: https://gravam.com/blog/why-tms-implementations-fail
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-02
Summary: Why TMS implementations fail: rarely the software — it's the treasury change. IT-project thinking, bank connectivity, dirty data, no one owning the outcome.

**TMS implementations rarely fail because of the software.** They fail because of the treasury change around it: the project is run as an IT install instead of a treasury programme, bank connectivity is underestimated, dirty master data is migrated as-is, forecasting expectations outrun the data, and — the pattern behind all of it — tasks are owned but the _outcome_ is not.

Having sat inside a few of these, the failure modes are remarkably consistent, and none of them are really about the product you picked. Here's what actually goes wrong, and how to de-risk your programme before it starts.

## It's almost never the software

Modern treasury systems are mature. When an implementation goes badly, the post-mortem almost never concludes "the software couldn't do it." It concludes some version of "we configured it to match the demo, not the business," or "we ran out of time on connectivity," or "no one had decided who owned the number." The technology is the part most likely to work. The organization around it is the risk.

> A TMS doesn't fix your treasury process — it makes whatever process you have faster and more visible, including the broken parts. Which is why the process questions have to be answered first.

## The failure patterns

### 1. Run as an IT project, not a treasury change programme

The single most common root cause. IT owns the plan, the vendor drives configuration, and the people who actually understand the cash flows are consulted occasionally rather than embedded. The system ends up configured to pass the demo, not to run month-end. Treasury has to own this programme — not attend it.

### 2. Bank connectivity is underestimated

The software is "live" in weeks. Getting every bank onboarded, the right message formats agreed (statements _and_ payments), and every flow tested end to end takes far longer — and depends on banks and third parties you don't control. **Connectivity, not configuration, is almost always the [critical path](https://gravam.com/blog/treasury-management-system-implementation-guide).** Teams discover this three months in, when it's already the thing holding go-live.

### 3. The static data is dirty

Bank accounts, counterparties, cost centres, signatories and payment details get migrated as-is, on the assumption they'll be "cleaned later." They aren't. Then every downstream problem — a payment to the wrong account, a position that won't reconcile — traces back to a master-data record no one owned. Data quality is not a workstream you can defer — [TMS data migration](https://gravam.com/blog/tms-data-migration) done properly starts with cleaning and ownership, not with the load.

### 4. Forecasting expectations outrun the data

Leadership expects an accurate cash forecast on day one. But a forecast is only as good as the source data and the discipline feeding it, and that maturity is built over quarters, not configured in a sprint. Promising day-one accuracy sets the programme up to be judged a failure on the one thing that was never realistic yet.

### 5. No one owns the outcome

Every task has an owner. The _outcome_ — "treasury sees group cash without a spreadsheet, with controls that pass audit" — is owned by a steering committee, which is to say no one. Work in the seams between tasks (integration, edge cases, the definition of done) falls through, and the slip is invisible on a status report where every task is green. This is the pattern behind the other four.

### 6. Scope creep and matching the demo

Without a prioritized, business-anchored requirements list, the implementation drifts toward whatever the vendor showed and whatever each stakeholder asks for in the moment. The result is a system that does many things adequately and the two things you actually needed poorly.

### 7. Testing gets squeezed

Because connectivity and data ran long, testing — especially proper user acceptance testing with real scenarios — gets compressed into the window before a fixed go-live. Defects surface in production instead, during hypercare, when they're most expensive and most visible.

## The pattern behind the patterns

Read those back and the common thread is not technical. It's that **the people who understand the cash flows weren't close enough to the decisions**, and **no one owned the outcome end to end**. Every other failure mode is a symptom of those two. (This is exactly the [unclear-ownership problem](https://gravam.com/blog/07-cost-of-unclear-ownership) that quietly sinks any complex finance-systems delivery, not just treasury.)

## Failure-prevention matrix

Each failure mode has a phase where it takes root and a **leading indicator** you can catch it by — long before it shows up as a slipped go-live. This is the table I'd pin to the programme wall:

| Failure mode | Where it takes root | Leading indicator (catch it here) | Mitigation | Owner |
| --- | --- | --- | --- | --- |
| Run as an IT project | Mobilize / design | Treasury SMEs are "consulted," not embedded | Treasury owns the programme; SMEs in the room | Programme owner (treasury) |
| Connectivity underestimated | Build onward | Bank onboarding hasn't started by the design phase | Start connectivity day one, in parallel | Integration lead |
| Dirty static data | Data migration | "Clean it later" appears anywhere in the plan | Data quality is its own workstream, before migrate | Data owner |
| Forecast expectations outrun data | Go-live / hypercare | Someone promised day-one accuracy | Sell day-one _visibility_; accuracy is earned | Programme owner |
| No one owns the outcome | Everywhere | The outcome is owned by a "steering committee" | Name one accountable person for the outcome | Executive sponsor |
| Testing gets squeezed | Testing / cutover | The UAT window shrinks as earlier phases slip | Ring-fence UAT; don't let it absorb the slips | Test lead |

Read the "leading indicator" column on its own: every one of these is visible _weeks before_ it becomes a crisis, if someone's looking for it.

## How to de-risk your programme

- [ ] **Run it as a treasury change programme.** Treasury owns it; embed the people who run the cash, don't just consult them.
- [ ] **Start bank connectivity first.** Treat it as the critical path it is, in parallel with configuration, not after, and track every bank as a dependency on the [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies).
- [ ] **Make data quality a real workstream.** Clean master data before migration; own it; don't defer.
- [ ] **Set honest forecasting expectations.** Day-one visibility, not day-one accuracy; accuracy is earned over quarters.
- [ ] **Name one outcome owner.** Not a committee — a person accountable for "treasury sees group cash, with controls that pass audit."
- [ ] **Anchor scope to prioritized requirements.** Must/should/could, tied to real needs; resist demo-driven drift.
- [ ] **Protect testing time.** Ring-fence UAT with real scenarios; don't let it be the shock absorber for earlier slips.

## What I'd do differently

If I could change one thing on most of these programmes, it wouldn't be the software or even the plan — it would be **who's in the room and who owns the outcome**. Put treasury in charge, name a single accountable owner, start connectivity and data on day one, and be honest about what a forecast can do in year one. Do that and the implementation stops being a gamble on the vendor and starts being a change you're actually running.

***

_See also [whether you need a TMS at all](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets), the [requirements checklist](https://gravam.com/blog/treasury-management-system-requirements-checklist) and the wider [treasury transformation guide](https://gravam.com/blog/treasury-transformation-guide)._

## Questions this article answers

**Q: Why do treasury management system implementations fail?**

Almost never because of the software. They fail because the project is run as an IT install rather than a treasury change programme; because bank connectivity — the real critical path — is underestimated; because dirty master data is migrated as-is; because forecasting expectations outrun the data; and because tasks are owned but the outcome is not. Fix those and the technology rarely gets in the way.

**Q: What is the hardest part of a TMS implementation?**

Bank connectivity, consistently. The software can be configured in weeks, but onboarding every bank, agreeing message formats, and testing statements and payments end to end takes far longer and depends on third parties you don't control. Connectivity, not configuration, is almost always the critical path — so it should start first.

**Q: How do you make a TMS implementation succeed?**

Run it as a treasury change programme with treasury in the room, name one owner accountable for the outcome (not just the task list), start bank connectivity and data cleaning early, set realistic forecasting expectations, and protect testing time. The pattern behind most failures is the same: the people who understand the cash flows weren't close enough to the decisions.

---

# Treasury Management System Requirements Checklist

Source: https://gravam.com/blog/treasury-management-system-requirements-checklist
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-02
Summary: A practical TMS requirements checklist — cash, connectivity, payments, risk, accounting, reporting, plus the non-functional requirements teams forget.

**A good TMS requirements checklist covers six functional areas — cash and liquidity, bank connectivity, payments, financial risk, accounting and compliance, and reporting — plus the non-functional requirements (integration, [security](https://gravam.com/blog/tms-cloud-security-and-data-residency), data, deployment, support) that teams routinely forget.** But the checklist below is only useful if every line traces back to a real need and is [prioritized must / should / could](https://gravam.com/blog/how-to-write-a-tms-rfp). A requirements list copied from a vendor's feature grid is worse than no list at all.

Use this as a starting point, delete what doesn't apply, and add the two or three things unique to your business that no generic list would contain.

## Start from your problem, not a feature list

Before the checklist, write down the questions you can't answer today and the decisions they block — _"we can't see group cash intraday," "we can't prove who approved a payment," "our forecast is one person's spreadsheet."_ Those become your **must-haves** and your success criteria. Everything on the list below is a prompt; your business need is what makes an item a requirement.

## The requirements checklist

### Cash & liquidity management

- [ ] Automatic import and consolidation of balances and transactions from all banks
- [ ] Intraday and end-of-day cash positioning across entities and currencies
- [ ] Cash flow forecasting (multiple horizons and granularities)
- [ ] Actual-vs-forecast variance tracking and forecast-accuracy measurement
- [ ] Cash pooling support (physical / notional; zero / target balancing)
- [ ] Intercompany positions and internal funding visibility

### Bank connectivity

- [ ] Statement import in your banks' formats (MT940, camt.053, BAI2)
- [ ] Payment file generation in required formats (pain.001 / ISO 20022, local formats)
- [ ] Connectivity channels you need (SWIFT, host-to-host, EBICS, API)
- [ ] Bank onboarding support and pre-built bank connectors
- [ ] Acknowledgement / status handling (pain.002) and end-to-end payment tracking
- [ ] Coverage for all your current banks — and easy addition of new ones

### Payments

- [ ] Centralized payment initiation (payment factory) if required
- [ ] Configurable approval workflows and limits
- [ ] Segregation of duties enforced in the workflow
- [ ] Sanction / compliance screening or integration to a screening tool
- [ ] Payment templates, recurring payments and bulk handling
- [ ] Full, exportable audit trail of who approved what, when

### Financial risk management

- [ ] FX exposure capture, valuation and reporting
- [ ] Interest-rate (and, if relevant, commodity) exposure and instruments
- [ ] Deal capture for hedges and instruments; lifecycle management
- [ ] Limit monitoring and breach alerts
- [ ] Hedge accounting support (IFRS 9 / your standard)
- [ ] Debt and investment portfolio tracking (schedules, interest, covenants)

### Accounting & compliance

- [ ] Automated accounting entries and posting back to the ERP/GL
- [ ] Reconciliation of treasury sub-ledger to the GL
- [ ] Support for your reporting standards and audit requirements
- [ ] Configurable controls, approvals and change logging
- [ ] Data retention and auditability that satisfies your auditors

### Reporting & analytics

- [ ] Standard treasury dashboards (position, forecast, exposure, debt)
- [ ] Configurable / ad-hoc reporting without vendor dependency
- [ ] Board- and CFO-ready reporting outputs
- [ ] Data export and, if needed, a data feed to your BI / warehouse
- [ ] Drill-down from a number to its source (provenance)

### Non-functional (the part teams forget)

- [ ] **Integration** — clean interfaces to your ERP and any middleware; documented APIs
- [ ] **Security** — SSO, role-based access, segregation of duties, encryption
- [ ] **Data** — master-data model, migration support, data quality tooling
- [ ] **Availability & performance** — SLAs, uptime, response times at your volumes
- [ ] **Deployment** — SaaS vs on-prem; hosting, region, data residency
- [ ] **Vendor** — implementation approach, support model, roadmap, references, viability

> Copy the whole list, then do two passes. First pass: delete every line that isn't a real need for _your_ business. Second pass: add the handful of requirements unique to you (a specific bank, a regulatory quirk, an odd entity structure). What's left is a requirements document you can defend — and score vendors against. It also tells you [which category of TMS](https://gravam.com/blog/best-treasury-management-system) you should be shortlisting in the first place: the requirements that survive the cull are usually a clear pointer to spreadsheet, ERP module or specialist system — and, by showing which needs are urgent and which can wait, to the [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) question as well.

## How to prioritize: must / should / could

Tag every surviving requirement:

- **Must** — the system is genuinely unusable for you without it. Keep this list short; if half your requirements are "must," none of them are.
- **Should** — important, but there's a workaround you could live with for a while.
- **Could** — nice to have; a tiebreaker at most.

This is what lets you compare vendors on _what matters to you_ rather than on who has the longest feature list.

## Turn the checklist into a scoreable workbook

A checklist you tick is a start; a checklist you can _trace and score_ is a selection tool. Give every surviving requirement a row with these columns — then the same rows carry all the way into the demo scorecard and, later, UAT:

| Column | What goes in it | Why it earns its place |
| --- | --- | --- |
| **Req ID** | `CASH-01`, `PAY-03`, `CONN-02`… | Lets a demo score or a UAT test trace back to the line |
| **Requirement** | The capability, in _your_ words | Not the vendor's feature name |
| **Category** | Cash · Connectivity · Payments · Risk · Accounting · Reporting · Non-functional | Groups and balances the list |
| **Priority** | Must / Should / Could | Drives the weighting in the scorecard |
| **Business need** | The question it answers / decision it unblocks | Defensibility — a requirement with none gets cut |
| **Evidence** | Demo result, reference answer, UAT test ID | Proof it's actually met, not just claimed |

The payoff is traceability: every requirement line has an ID that flows into the [vendor demo scorecard](https://gravam.com/blog/tms-vendor-demo-questions-and-scorecard) and then into UAT, so "does it meet our needs?" is answered by evidence against IDs, not by which demo felt best.

## How TMS requirement lists lose their value

- **Gold-plating.** A 300-line wish list where everything is "must." It can't be prioritized, so vendors optimize for feature-count and you can't tell them apart.
- **Copying a vendor's grid.** You inherit their framing and their strengths, and you miss the requirements specific to your business.
- **Ignoring the non-functional.** Integration, data, security and support decide whether the implementation succeeds — and they're the lines checklists skip.
- **No traceability.** Requirements no one can tie back to a business need; you can't defend them, and they bloat the evaluation.

## Using this in selection

A prioritized, business-anchored checklist becomes the backbone of your [TMS RFP](https://gravam.com/blog/how-to-write-a-tms-rfp) and your vendor scorecard: each requirement is a scored line, weighted by must / should / could. That turns "which demo impressed us?" into "which system best meets the needs we actually have?" — the whole point of doing this properly. Score the shortlist against those weighted requirements in the free [TMS Vendor Scorecard](https://gravam.com/tools/tms-vendor-scorecard), and build the numbers behind the case with the [TMS Business-Case Calculator](https://gravam.com/tools/tms-business-case-calculator).

***

_See also [do you need a TMS? TMS vs ERP vs spreadsheets](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets)._

## Questions this article answers

**Q: What should a TMS requirements document include?**

Functional requirements across cash and liquidity, bank connectivity, payments, financial risk, accounting and compliance, and reporting — plus the non-functional requirements teams forget: integration, security and segregation of duties, data and master-data handling, deployment, and vendor support. Every requirement should trace back to a real business need, and each should be prioritized must / should / could.

**Q: How do you prioritize TMS requirements?**

Use MoSCoW — must, should, could, won't. 'Must' means the system is unusable for you without it; keep this list short and defensible. 'Should' is important but has a workaround. 'Could' is nice-to-have. Being honest here is what lets you compare vendors on what actually matters instead of on feature-count.

**Q: What non-functional requirements matter for a TMS?**

Integration (how it connects to your ERP and banks), security and segregation of duties, data handling and migration, availability and performance, deployment model (SaaS vs on-prem), and vendor support and roadmap. These decide whether an implementation succeeds far more often than any single functional feature — and they're the ones checklists usually skip.

---

# Do You Need a TMS? TMS vs ERP vs Spreadsheets

Source: https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Do you need a TMS, your ERP's treasury module or just spreadsheets? A readiness scorecard, a head-to-head comparison and the signals it's time to step up.

**You need a treasury management system when the cost and risk of running cash across many banks, entities and currencies in spreadsheets outweighs the cost of the system — and even then, the next question is whether your ERP's treasury module already covers it.** So the choice is really between three levels: spreadsheets, cheapest and fine for simple, single-entity cash (and if you live in one, a few dynamic-column formula patterns go a long way); your ERP's treasury module, one integrated system when you're ERP-centric with moderate needs; and a dedicated TMS, the deepest, most specialized capability — bank connectivity, forecasting, risk — when your complexity justifies the extra system and cost.

The wrong way to decide is by default: "we already have SAP, so we'll use SAP," or "the incumbent spreadsheet still works, so we'll keep it." The right way is to size your complexity honestly, then match each option against it and against the questions you can't answer today. This post gives you a readiness scorecard for the first part and a head-to-head for the second; once you've concluded you're buying a dedicated system, the [guide to choosing a TMS by category](https://gravam.com/blog/best-treasury-management-system) picks up from there.

## It's complexity, not company size

The instinct is to benchmark against revenue: "companies over €X buy a TMS." That's misleading. A fast-growing group with modest revenue but a dozen-plus bank relationships across several currencies can need a system far more than a much larger, single-market business whose cash is simple and predictable enough to run comfortably on spreadsheets.

> Revenue tells you how much cash you have. Complexity tells you how hard it is to see and control — and that's what a TMS actually buys.

Four things drive the decision. Score yourself honestly on each.

- **Bank landscape.** How many banks and accounts do you operate? Each one is a portal to log into, a statement format to reconcile, a set of signatories to manage. Two banks is a spreadsheet; a dozen is a full-time job.
- **Entities and currencies.** Multiple legal entities and currencies multiply the reconciliation, the intercompany flows, and the FX exposure you have to see and manage.
- **Transaction volume and risk.** High payment volumes, material FX or interest-rate exposure, and debt/investment portfolios all raise the cost of doing this by hand — and the cost of getting it wrong.
- **Control and audit needs.** If you must _prove_ who approved each payment and where every number came from — for auditors, for SOX, for the board — spreadsheets and email are a standing finding waiting to happen.

## The treasury readiness scorecard

Score each dimension 0–3, add them up, and read off the recommendation. It's rough on purpose — the point is a shared, honest conversation, not false precision.

| Dimension | 0 | 1 | 2 | 3 |
| --- | --- | --- | --- | --- |
| **Banks / accounts** | 1 bank | 2–3 | 4–8 | 9+ |
| **Entities & currencies** | 1 entity, 1 currency | Few entities, 1–2 currencies | Several entities, multi-currency | Many entities, many currencies |
| **Volume & risk** | Low, no hedging | Some volume, minor FX | High volume or material FX | High volume _and_ material risk |
| **Control & audit** | Informal is fine | Some scrutiny | Audited, SOX-lite | Strict SOX / regulated |

**How to read your total:**

- **0–3 — Stay on spreadsheets (for now).** Your cash is simple. A TMS would be expensive over-engineering. Invest instead in a clean process and good bank-portal discipline.
- **4–7 — Watch the trend, and test your ERP.** You're in the grey zone, which is exactly where the ERP's treasury module often earns its place. If any dimension is trending up (new entities, new banks, a pending acquisition), start building the case and the requirements now, before the pain forces a rushed decision.
- **8–12 — The case is already there.** The question is no longer _whether_ but _which_ system and _how_ to implement it without losing control.

> Run the scorecard with treasury _and_ finance leadership in the room. The disagreements are the valuable part — they surface the risks and complexity that a single person's score would hide.

## The three real options

- **Spreadsheets + bank portals.** The universal starting point. Cheap, flexible, and completely dependent on the discipline of whoever maintains them. No real audit trail, no live multi-bank view.
- **ERP treasury module.** Treasury built into your accounting backbone — SAP's TRM and S/4HANA Cash Management, Oracle's equivalents. One system, shared master data, entries straight to the ledger. Coverage varies by area.
- **Dedicated TMS.** A specialized platform (Kyriba, FIS, ION, Ripple Treasury (formerly GTreasury), Coupa/Bellin and others) focused entirely on treasury. Broadest bank connectivity, strongest forecasting and dealing, at the highest cost and with an integration to build. Within this option there's one more fork: an all-in-one suite or a core you extend over time — see [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system).

## Head-to-head

|  | Spreadsheets | ERP treasury module | Dedicated TMS |
| --- | --- | --- | --- |
| **Cost** | Lowest | Bundled (if you own the ERP) | Highest (licence + implementation) |
| **Cash visibility** | Manual, point-in-time | Good within the ERP | Real-time, multi-bank, consolidated |
| **Bank connectivity** | Human in portals | Often needs an add-on/partner | Core strength; many banks & formats |
| **Cash forecasting** | Fragile | Basic to moderate | Purpose-built, multiple methods |
| **Risk & hedging** | Not really | Varies (SAP TRM is strong) | Core strength |
| **Integration effort** | None (and no integration benefit) | Native — shares GL & master data | You build & maintain ERP↔TMS interfaces |
| **Controls & audit** | Weak | Strong (inherits ERP controls) | Strong, treasury-specific |
| **Best fit** | Simple, single-entity cash | ERP-centric, moderate needs | High complexity, many banks/currencies/risk |

## When spreadsheets are still right

Don't over-buy. If you're a single entity with two or three banks, one or two currencies, low payment volume and no material FX, a well-built spreadsheet and good portal discipline is genuinely the right answer. Buying too early is a real failure mode, so hold off on any system if:

- Your cash is genuinely simple and one person can see it all reliably.
- Your process is still undefined — you don't yet know what "good" looks like. A system will only automate the confusion.
- You'd be buying features you'll never open because a vendor demo was impressive.

In that case, spend on _clarity_ first: define your daily cash process, clean your bank master data, and write down the two or three questions you can't answer today. That work is never wasted — it becomes your requirements when the time does come. The signal to move on is when you can no longer answer _"how much cash do we have, right now?"_ quickly and reliably.

## When ERP treasury is enough

If you're already ERP-centric — most of your finance runs in SAP or Oracle — the treasury module is often the pragmatic choice. You avoid another system to license, integrate and reconcile; treasury shares the same master data and posts straight to the GL; and the controls are inherited from a system your auditors already trust.

> SAP TRM in particular is capable for financial-risk management, hedge accounting and, with S/4HANA Cash Management and One Exposure, a genuinely strong cash picture. The usual gap isn't risk or accounting — it's the breadth of _bank connectivity_ and _forecasting_, which is where dedicated TMS vendors invest most.

The mistake here is assuming coverage you haven't tested. "We have SAP" is not the same as "SAP meets our requirements." Score the ERP against your real must-haves before you commit.

## When you need a dedicated TMS

Reach for a specialized TMS when complexity outgrows what an ERP module comfortably handles: many bank relationships and statement formats, multi-entity multi-currency cash, serious forecasting needs, active dealing and hedging, or an in-house bank / payment factory. This is where the depth of a purpose-built platform pays for its cost and its integration.

Beyond the score, a few lived symptoms almost always mean you're past the tipping point:

- You can't answer "how much cash do we have, group-wide, right now?" without a morning of chasing.
- A wrong month-end number traced back to a broken spreadsheet link no one caught.
- A payment was approved over email and you couldn't cleanly prove who approved it.
- An FX exposure lived in one analyst's workbook, and a hedging decision depended on that file being right.
- You've grown — entities, currencies, acquisitions — faster than your tooling.

## The hybrid reality

For large organizations, this is rarely either/or. The common landscape is **ERP + TMS coexisting**: the ERP owns the ledger, AP and AR; the TMS owns connectivity, positioning, forecasting and dealing; and they integrate. The critical design question then isn't "which one," it's **which system owns which data** — bank master data, payment status, exposures. Getting those system-of-record boundaries right is what keeps the landscape clean instead of a permanent reconciliation project.

## Buying a TMS too early or too late

- **Choosing by inertia.** Defaulting to the ERP because it's there, or to spreadsheets because they're familiar, without testing either against requirements.
- **Buying too early.** A system bought to look mature, then barely used, because the process wasn't ready and no one owned the outcome. Expensive shelfware.
- **Buying too late.** Waiting until a visibility failure or an audit finding forces a rushed selection, which produces a rushed implementation, which produces exactly the mess you feared.
- **Choosing on licence price.** The licence is rarely the biggest cost; a cheap system with poor bank connectivity or a painful integration costs far more in effort and risk.
- **Skipping the system-of-record decision.** Running ERP and TMS without deciding who owns what data guarantees duplicate maintenance and reconciliation pain.

## How to decide

Decide _before_ the crisis, and work in this order: (1) write your requirements from the questions you can't answer today; (2) run the readiness scorecard above with finance leadership, and note where each dimension is _trending_; (3) test your ERP's treasury module against your must-haves honestly; (4) only if it falls short on things that matter, work out [which category of TMS fits you](https://gravam.com/blog/best-treasury-management-system) and evaluate vendors inside it — the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) works just as well for scoring your ERP module against a dedicated system as it does for comparing vendors. If you're a stable 4–7, keep what you have — but keep the requirements warm. Decide on fit and total effort, not on price or habit.

***

_See also [what a TMS is](https://gravam.com/blog/what-is-a-treasury-management-system) and [how to build the TMS business case](https://gravam.com/blog/treasury-management-system-business-case)._

## Questions this article answers

**Q: At what point does a company need a treasury management system?**

When the complexity of your cash — number of banks, entities, currencies and payment volume — plus the cost of a visibility or control failure, outweighs the cost of the system and its implementation. It's rarely triggered by revenue alone. A single entity with two banks and predictable cash usually doesn't need one; a group with a dozen banks across several currencies almost always does.

**Q: What is the difference between a TMS and ERP treasury?**

A dedicated TMS specializes in the treasury layer — multi-bank connectivity, cash positioning and forecasting, payments and financial-risk management — usually with broader, deeper coverage than an ERP module. An ERP's treasury capability (e.g. SAP TRM) is integrated into the accounting backbone, so it shares master data and the ledger, but may be less specialized in areas like bank connectivity and forecasting. Neither is universally better; it depends on your complexity and how ERP-centric you are.

**Q: Can you use SAP or Oracle instead of a dedicated TMS?**

Often, yes. If you're already ERP-centric and your treasury needs are moderate, the ERP's treasury and cash-management modules can be enough and avoid another system to integrate — SAP TRM in particular is capable for risk and hedge accounting. You typically still need to solve bank connectivity, and you should test the ERP against your actual requirements rather than assume 'we have SAP, so we'll use SAP.'

**Q: Is a spreadsheet enough for treasury?**

For a single entity with a couple of banks and predictable cash, yes — a disciplined spreadsheet plus bank portals works. It stops being enough when you can't quickly answer how much cash you have group-wide, when you can't prove who approved a payment, or when errors from broken links start to carry real cost.

**Q: Is a TMS worth it for a mid-sized company?**

Often yes, but the case rests on complexity and risk, not size. A mid-sized company with many bank relationships, cross-border flows and manual payment approvals gets more value than a larger but simpler one. Score your banks, entities/currencies, volume/risk and control needs before deciding.

---

# What Is a Treasury Management System (TMS)?

Source: https://gravam.com/blog/what-is-a-treasury-management-system
Topic: Treasury Management Systems — https://gravam.com/topics/treasury-management-systems
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: A treasury management system (TMS) manages cash, liquidity, payments, risk and bank connectivity — what it does, when you need one, and how it fits.

**A treasury management system (TMS) is a specialized platform that [corporate treasury](https://gravam.com/blog/what-does-a-corporate-treasury-do) uses to manage cash, liquidity, payments, financial risk, debt, investments and bank connectivity across the whole organization.** It replaces the spreadsheets, bank portals and email threads that a growing finance team otherwise stitches together — and, crucially, it gives you one auditable place where the numbers, the controls and the source of each figure all live.

If you're weighing whether your company needs one, the honest answer is: it depends less on your revenue and more on how many banks, entities and currencies you're juggling, and how much a cash-visibility mistake would cost you. This guide covers what a TMS actually does, how it differs from your ERP and spreadsheets, where it sits in your system landscape, and the mistakes that quietly derail these projects.

## What a treasury management system actually does

Vendors describe a TMS as a dozen "modules" — whether those arrive separately or as one suite around a [core treasury system](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) is its own decision — but underneath, it does six jobs:

- **Cash and liquidity management.** Aggregates balances and transactions from every bank into one view, builds the daily cash position, and forecasts cash across chosen horizons. This is the reason most companies buy a TMS at all.
- **Bank connectivity.** Connects to your banks — via SWIFT, host-to-host, EBICS or API — to pull statements (MT940, camt.053, [BAI2](https://gravam.com/blog/bai2-file-format-explained)) and push payment instructions, without someone logging into ten portals.
- **Payments.** Originates, approves and tracks outgoing payments through a controlled workflow, often as a central [payment factory](https://gravam.com/blog/what-is-a-payment-factory), with the statuses coming back from the bank (pain.001 out, pain.002 back).
- **Financial risk management.** Records and values FX, interest-rate and [commodity exposures](https://gravam.com/blog/commodity-price-risk) and the deals used to hedge them; supports hedge accounting and limit monitoring.
- **Debt and investment management.** Tracks loans, facilities, intercompany funding and short-term investments — principal, interest, schedules and covenants.
- **Accounting, compliance and reporting.** Generates the accounting entries back to the ERP/GL, enforces segregation of duties, and produces the reports treasury and the CFO actually read.

> A useful test of a TMS is not "how many features does it have?" but "how cheaply can it answer _where did this number come from?_" Treasury's real bottleneck is provenance, not arithmetic.

## TMS vs ERP treasury vs spreadsheets

Most finance teams are choosing between three ways to run treasury, not deciding whether treasury exists. Here's how they compare on the things that matter — and [which is "best" depends on your category](https://gravam.com/blog/best-treasury-management-system), not a ranking.

|  | Spreadsheets + bank portals | ERP treasury module | Dedicated TMS |
| --- | --- | --- | --- |
| **Cash visibility** | Manual, as of whenever it was last updated | Good within the ERP's world | Real-time, multi-bank, consolidated |
| **Bank connectivity** | Human logging into portals | Often add-on / partner connector | Core strength; many banks, many formats |
| **Cash forecasting** | Possible but fragile | Basic to moderate | Purpose-built, multiple methods |
| **Risk/hedging & dealing** | Not really | Varies (e.g. SAP TRM is strong) | Core strength |
| **Controls & audit trail** | Weak — the classic finding | Strong (inherits ERP controls) | Strong, treasury-specific |
| **Cost & effort** | Cheap, until it breaks | Bundled, if you have the ERP | Highest, but specialized |
| **Best when** | One entity, few banks, simple cash | ERP-centric, moderate treasury needs | Many banks/entities/currencies, real complexity |

The ERP (SAP, Oracle) owns the ledger, AP and AR; it is the system of record for what happened. A TMS specializes in the treasury layer on top — connectivity, positioning, forecasting, payments and risk. The two are not rivals so much as neighbours: in most large landscapes they coexist and integrate, with clear rules about which system owns which data. (SAP is interesting here because its own **TRM and S/4HANA Cash Management** blur the line — [SAP TRM vs a standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms) is a decision worth its own guide.)

## Signs you've outgrown spreadsheets

You rarely wake up one day needing a TMS. You accumulate symptoms. If several of these are true, the business case is probably already there:

- The group cash number is a daily reconstruction project: portals, exports, one workbook that only its owner understands.
- Someone logs into more than a handful of bank portals to build the position.
- A broken spreadsheet link made it into a month-end number before anyone noticed.
- Approvals happen in inboxes, so "who signed off on this payment?" has no clean answer.
- The hedging programme rests on a single analyst's workbook being right.
- Entities, currencies and acquisitions have grown faster than the tooling underneath them.

I keep a fuller version of this diagnosis — a readiness scorecard, and the signs you're _not_ ready yet — in [do you need a TMS, or will your ERP or spreadsheets do](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets).

> Before you shop for a TMS, write down the two or three questions you can't answer today and the decisions they block. Those become your requirements — and your success criteria. A system that answers them is worth buying; one that adds features you'll never open is not.

## Where a TMS sits in your architecture

A TMS is never an island. It sits in the middle of four things, and most of the value — and most of the risk — is in the connections, not the box:

- **Your ERP**, upstream and downstream: AP/AR and GL data flows in; treasury's accounting entries flow back.
- **Your banks**, through a connectivity channel: statements in, payments out.
- **Market data**, for FX and interest rates used in valuation and forecasting.
- **The people and controls** around it: approvers, segregation of duties, and the reports leadership relies on.

> **Figure — Where a treasury management system sits**
>
> The TMS in the middle of four things. The ERP on one side, with data flowing in and accounting entries flowing back. The banks on the other, with statements coming in and payments going out. Market data feeding it from above. People and controls beneath it.
>
> A TMS is never an island — it sits between the ERP, the banks, market data, and the people and controls around it.

Getting the **system-of-record** decisions right — which system owns bank master data, which owns the payment status, which owns the exposure — is the single most consequential design choice, and the one teams most often skip. (I've written a separate [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) for exactly this; it's the difference between a clean landscape and years of reconciliation.)

## Why these programmes fail

Having sat inside a few of these programmes, the failure patterns are remarkably consistent — and none of them are really about the software:

- **It's treated as an IT install.** The people who actually understand the cash flows are consulted, not embedded — and the configuration ends up mirroring the vendor demo instead of the business.
- **Connectivity eats the timeline.** Configuring the software is the quick part; onboarding every bank, agreeing formats and testing each flow end to end is the part that drags — and it sits with parties you don't control.
- **Dirty master data gets migrated "to clean up later."** Later never comes, and every downstream mystery traces back to one of those records.
- **Day-one forecast accuracy gets promised.** Forecast quality follows the source data and the discipline feeding it, and neither exists at go-live.
- **Everyone owns a task; nobody owns the outcome.** "Treasury sees group cash without a spreadsheet" belongs to a committee — which is to say, to no one.

I've unpacked each of these, with what actually prevents them, in [why TMS implementations fail](https://gravam.com/blog/why-tms-implementations-fail).

> A TMS doesn't fix a treasury process. It makes whatever process you already have faster and more visible — including the broken parts. Fix the process question first.

## The treasury-tooling maturity ladder

Most companies don't jump straight to a TMS; they climb a ladder, and the useful question is which rung you're on and what would push you up. Each move is triggered by a pain, not a revenue number.

| Stage | How treasury runs | The trigger to move up |
| --- | --- | --- |
| **Spreadsheets** | Bank portals + workbooks; one entity, a few banks | You can't answer "group cash, right now?"; portal sprawl; a broken link caused a wrong number |
| **ERP treasury** | Treasury run inside the ERP you already own | Multi-bank connectivity and forecasting strain the ERP's treasury layer |
| **Dedicated TMS** | A specialized multi-bank platform for cash, risk, payments | Many banks/entities/currencies; a cash-visibility mistake would genuinely hurt |
| **Optimized TMS** | TMS plus [payment factory](https://gravam.com/blog/what-is-a-payment-factory) / [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank), mature forecasting | You're centralizing payments and chasing straight-through processing |

The ladder is why the answer to "do we need a TMS?" is rarely yes/no — it's "which rung solves the pain you have without buying two rungs of complexity you don't." It is also the oldest lesson in enterprise software, and the one currently being relearned with AI: a system changes nothing until the work around it is redesigned to use it, which is [why so many pilots never become the way the work runs](https://gravam.com/blog/why-most-ai-pilots-never-become-operating-systems).

## So, do you need one?

Reduce it to three questions:

1. **How complex is your cash?** More banks, entities and currencies push you toward a TMS; a single entity with predictable flows does not need one.
2. **How costly is a mistake?** If a missed exposure or a stale position could genuinely hurt, the control and visibility a TMS buys are cheap insurance.
3. **Is the process ready?** If treasury doesn't yet know what "good" looks like, spend that clarity _before_ you spend on software — otherwise you'll automate confusion.

For a structured way to answer this, run the readiness scorecard in [TMS vs ERP vs spreadsheets](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets). If the answers point to "yes," the next decisions are _which_ system and _how_ to implement it without losing control — the difference between a TMS that pays for itself and one that becomes a two-year saga. When you reach the comparing-candidates stage, the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) keeps that decision weighted to your priorities instead of the most polished demo.

## Questions this article answers

**Q: What is a treasury management system in simple terms?**

A treasury management system is the software corporate treasury uses to see and control the company's cash. It pulls in bank balances and statements, forecasts cash, sends and tracks payments, manages FX, debt and investments, and keeps an auditable record of it all — the jobs a finance team used to do in a wall of spreadsheets.

**Q: Do I need a TMS if I already have an ERP?**

Not always. If your treasury needs are moderate, the ERP's own treasury module can be enough; a TMS earns its place when bank connectivity, forecasting and risk outgrow it, and many large companies run both.

**Q: Do small companies need a treasury management system?**

Usually not at first: a single entity with one or two banks and predictable cash runs well on spreadsheets and bank portals. The case grows with banks, entities, currencies and the cost of a cash-visibility mistake, not with revenue.

---

# Payment Hub vs Payment Factory: What's the Difference?

Source: https://gravam.com/blog/payment-hub-vs-payment-factory
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-09-02
Reviewed: 2026-09-02
Summary: A payment factory is an operating model — how the company organizes paying. A payment hub is the technology layer payments travel through. How they differ.

**"Payment hub" and "payment factory" get used as if they were synonyms, and they aren't: a payment factory is an operating model — how the company organizes paying — while a payment hub is the technology layer the payments travel through.** The confusion is understandable, because at scale the two arrive together and vendors borrow each other's vocabulary freely. But if you're deciding what to build or buy, the distinction is the decision: one is an organizational change, the other is an architecture change, and they solve different halves of the same mess.

## The payment hub: one path instead of many

In a group of any size, payments originate everywhere — ERPs, HR systems, treasury, local tools — and each source historically grew its own connection to its own banks in its own formats. A **payment hub** collapses that sprawl into one path: every payment request enters at a single central intake, and the hub validates it, transforms it into the right format, routes it to the right bank over the right [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), aggregates where useful, and monitors everything in one place.

What you buy with that is **control and standardization**: one governed path to audit instead of many fragile ones, one place formats are maintained, one screen where a stuck payment shows up. [SAP Advanced Payment Management](https://gravam.com/blog/sap-advanced-payment-management-apm) is a concrete example of the species — and the hard part of any hub, as that post argues, is not the concept but the migration of every existing flow onto the single path.

## The payment factory: one payer instead of many

A **[payment factory](https://gravam.com/blog/what-is-a-payment-factory)** is a different kind of answer. It centralizes the _organization_ of paying: one team, one standardized process, one calendar — often escalating to paying **on behalf of** group entities from central accounts, which is where it meets the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank). The factory's benefits are process benefits: fewer local payment teams, standardized controls, netted flows, concentrated bank relationships.

> A payment factory is how the company organizes paying. A payment hub is what the payments travel through. One is an org chart decision, the other an architecture decision — and calling them by one name hides that you have to make both.

## How they combine — and fail alone

The two are complements, not competitors:

- **A factory without a hub** is a centralized team on decentralized plumbing — one department now operating a dozen bank portals and format variants that used to be someone else's problem. The org chart changed; the fragility didn't.
- **A hub without a factory** is perfectly legitimate: subsidiaries keep initiating their own payments, but everything flows through one controlled layer. Many groups stop here, deliberately — the control benefits arrive without the political cost of taking payment execution away from entities.
- **Both together** is the full centralization story: on-behalf-of execution by a central team, over a single technical spine.

## Which one is your actual problem?

Ask what hurts:

- **"We have too many bank connections, too many formats, and no single view of outgoing payments."** That's the hub problem. It's an architecture project, and it stands on its own business case.
- **"Every subsidiary pays differently, controls vary by country, and we want on-behalf-of structures."** That's the factory problem. It's an organizational programme — and it will demand a hub underneath it before it scales, so sequence accordingly.
- **"Both."** Then build the hub first or in parallel: a factory migration onto plumbing that doesn't exist yet is how these programmes stall.

Vendors will sell either under either name. The evaluation discipline is the same as for any [treasury system selection](https://gravam.com/blog/how-to-run-a-tms-selection-process): write down which of the two problems you're solving, and score what's demoed against that — not against the label on the slide.

***

_See also [what is a payment factory](https://gravam.com/blog/what-is-a-payment-factory) and [SAP Advanced Payment Management (APM)](https://gravam.com/blog/sap-advanced-payment-management-apm)._

## Questions this article answers

**Q: What is a payment hub?**

A payment hub is a central technology layer for outgoing payments: every payment request from every source system enters at one intake, and the hub validates, transforms, routes, aggregates and monitors it on the way to the banks. Instead of a dozen systems each holding their own bank connections and format logic, payments travel one controlled, standardized path — which is where the control, the single audit trail and the single monitoring pane come from.

**Q: What is the difference between a payment hub and a payment factory?**

A payment hub and a payment factory live on different layers. A payment factory is an operating model — the organizational decision to centralize payment execution in one team and one process, often paying on behalf of group entities. A payment hub is a technology component — the central layer payment traffic physically travels through. The two get conflated because a factory at scale needs a hub underneath it, and hub vendors happily borrow the factory vocabulary. But you can run a hub without a factory (centralized plumbing under decentralized processes), and a factory without a proper hub is a centralized team drowning in decentralized plumbing.

**Q: Do you need a payment factory to justify a payment hub?**

No — a payment hub does not need a payment factory to justify it. If your problem is too many bank connections, too many formats and no single view of outgoing payments, a hub pays for itself on control and standardization alone, with every subsidiary still initiating its own payments. The factory question — centralizing who executes payments, and on whose behalf — is a separate organizational decision that a hub makes easier but doesn't require.

**Q: Is SAP Advanced Payment Management a payment hub?**

Yes — SAP Advanced Payment Management (APM) is SAP's payment hub inside S/4HANA: it receives payment requests centrally from many source systems and orchestrates them toward the banks. It's a concrete example of the hub layer, and pairing it with Bank Communication Management (approvals and bank dialogue) shows the division of labour a hub sits within.

---

# Virtual Accounts and VAM: Structures and Design

Source: https://gravam.com/blog/virtual-account-management-structures
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-09-01
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Virtual accounts (virtual IBANs) are sub-accounts over one real account. How they work, what they're for, and how to design a VAM structure that reconciles.

**Virtual accounts — often virtual IBANs — are sub-accounts layered on top of a single real bank account: each has its own account number for identification, but all the actual cash is held in the one underlying physical account.** They let a company hand out many "account numbers" — one per customer, entity or purpose — while collapsing the number of _real_ accounts it has to open, fund and manage. The payoff is two-fold: incoming payments largely reconcile themselves, because each payer self-identifies by the virtual account they use, and physical [account sprawl](https://gravam.com/blog/bank-account-rationalization) shrinks.

That's the easy half. **Virtual account management (VAM)** is the hard half: which real accounts carry the virtual ones, how deep the hierarchy goes, how virtual balances behave as a subledger, and how the whole thing lands in your statements and reconciliation. That design work is what banks and vendors sell as "VAM" — and this post walks through both halves, concept first.

## How virtual accounts work

The mental model that unlocks virtual accounts: **many account numbers, one pot of cash.** A virtual account looks like an account — it has an IBAN, you can route payments to it — but it doesn't hold money separately. It's an _identifier_ over a real account, where the cash actually sits. One physical account can carry hundreds or thousands of virtual accounts beneath it.

The bank maintains a single real account with an actual balance, and a set of virtual account numbers mapped to it. A payment made to a virtual IBAN lands in the underlying real account, _tagged_ with which virtual account it targeted. The company sees both: the real cash position, and which virtual account each flow belongs to. Nothing is physically segregated — the segregation is _informational_, which is exactly what makes it cheap and flexible.

## VAM the product vs VAM the design

Banks offer VAM as a product: the ability to issue virtual account numbers or virtual IBANs over a real account, track per-virtual-account positions, and report activity by virtual account. What the product does _not_ include is the structure — which entities, purposes and customers get virtual accounts, and how they're arranged. That is treasury's design decision, and it's where implementations succeed or quietly bloat. The bank provides the mechanism; you provide the model.

## The three structures that cover most cases

- **Per-payer collection structures.** A unique virtual IBAN per customer, so every incoming payment self-identifies by the account it hits. This is the receivables-reconciliation pattern, and for many companies it is the entire business case on its own.
- **Segregation structures.** A virtual account per entity, business line, currency-purpose or project over one real account — the identification benefits of many accounts without opening them. This is [account rationalization](https://gravam.com/blog/bank-account-rationalization) done structurally: you don't close the sprawl, you stop creating it.
- **In-house-bank structures.** Virtual accounts representing internal participants over a central real account, so group entities hold positions with the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) rather than at external banks — the plumbing beneath [payments- and collections-on-behalf-of](https://gravam.com/blog/what-is-a-payment-factory).

Most real designs combine two of these — for example, entity-level segregation with per-customer collection accounts nested beneath one entity.

> The classic reconciliation nightmare is a bank credit with no usable reference — who paid this? A unique virtual IBAN per customer answers that automatically: the account it landed in _is_ the identity of the payer.

The collection pattern is usually the single biggest driver: it turns cash application — matching incoming payments to the right customer and invoice — from a large manual effort into a near-automatic one. The segregation pattern pays off differently: fewer physical accounts means lower fees, simpler [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility), less cash stranded in local accounts and a smaller control surface. And in a centralized model, a virtual structure over a handful of real accounts can carry the whole group's collection and payment identities — concentrating the actual cash while preserving the identities the business needs. Virtual accounts are an enabler of centralization, not a rival to pooling or in-house banking.

## The subledger model

The shift that makes VAM design clear: **virtual balances are a subledger, not balances.** The real account has the only actual balance; each virtual account's "balance" is the running sum of transactions tagged to it — informational, maintained by the bank, always reconcilable back to the one real number. Design questions become subledger questions: can a virtual position go negative, how are balances rolled up the hierarchy, and does the arrangement between your entities constitute intercompany lending? That last one is the same position-tracking discipline as [cash concentration](https://gravam.com/blog/cash-concentration-sweeping-and-zba) — sweeping creates intercompany loans physically, virtual structures create the equivalent positions informationally, and both need owners, limits and documentation.

## Designing the hierarchy

> Every level in a virtual account hierarchy has to earn its place in a report someone actually reads. If a level exists only because the bank supports it, it's mapping work with no customer.

Multi-level hierarchies — real account at the top, entities beneath, purposes or customers beneath entities — are where VAM designs go to over-engineer. Banks differ in how many levels they support and how balances roll up, so a portable design stays shallow: two levels usually cover the genuine requirements. Deep trees multiply statement volume, mapping tables and month-end explanations, and the unwind is painful because account numbers, once given to payers, are sticky.

## Getting the data back out

The structure is only as good as its reporting. Cash moves on the real account; the virtual account rides along as the identifying reference. How that reference reaches you differs by bank — per-virtual-account statements, or one real-account statement with per-transaction virtual references, commonly in [camt.053 statements](https://gravam.com/blog/camt-053-structure-and-fields) and [camt.054 notifications](https://gravam.com/blog/camt-054-notification-explained). Two design-phase checks save the project: confirm exactly how each bank reports virtual activity (this varies more than the sales deck admits), and test reconciliation with real files before go-live — a virtual structure that reconciles badly is worse than the physical accounts it replaced, because now the mismatch is invisible.

## When not to use VAM

- **Where regulation wants a real account.** Some jurisdictions and some purposes (tax, payroll, local statutory requirements) expect a resident physical account; a virtual IBAN is not always an accepted substitute. Verify per country before designing it away.
- **Where the bank's VAM is thin.** Capability varies significantly by bank and country; a structure designed around one bank's rich VAM offering may not port to the next bank.
- **Where the problem is small.** A company with a dozen accounts and clean references doesn't need a virtual hierarchy — it needs its references enforced.

## Virtual account design mistakes

- **Hierarchy sprawl** — levels nobody reports on, kept because the bank supports them.
- **Reconciliation designed last** — the structure is agreed with the bank before anyone checks how it lands in statement files.
- **Intercompany positions untracked** — entity-level virtual accounts silently accumulate internal balances no one documents until audit or repatriation forces the question.
- **One-bank thinking** — a design that only one bank can operate, discovered during the next banking RFP.
- **Expecting them to replace _all_ accounts** — some real accounts are genuinely required; virtual accounts reduce the count, they don't eliminate it.

Design the structure from the reports you need, keep it as shallow as those reports allow, and treat virtual balances with the same intercompany discipline as physical sweeps — then VAM delivers what it promises: the identification of many accounts, the administration of few. The companion discipline is managing the real accounts you _do_ keep, which is where [eBAM](https://gravam.com/blog/electronic-bank-account-management-ebam) comes in.

***

_See also [bank account rationalization](https://gravam.com/blog/bank-account-rationalization) and [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank)._

## Questions this article answers

**Q: What are virtual accounts?**

Virtual accounts (often virtual IBANs) are sub-accounts layered on top of a single real bank account. Each virtual account has its own account number or IBAN used for identification and routing, but there is no separate pot of money — all the actual cash sits in the one underlying physical account. They let a company give many customers, entities or purposes their own 'account number' to pay into or from, while collapsing the number of real bank accounts it has to open, fund and manage.

**Q: What is the difference between a virtual account and a real bank account?**

A real bank account holds cash and exists as a distinct account at the bank with its own balance. A virtual account is an identifier layered over a real account — it has its own number for routing and reconciliation, but it doesn't hold cash separately; the money lives in the underlying physical account. So a company can have hundreds of virtual accounts backed by a single real one, getting the identification benefits of many accounts without the cost and administration of opening and maintaining them all.

**Q: What are virtual accounts used for?**

The most common use is receivables reconciliation: give each customer a unique virtual IBAN to pay into, and incoming payments self-identify by which virtual account they hit, so they match automatically instead of being reconciled by hand. Virtual accounts are also used to replace large numbers of physical accounts (each entity or purpose gets a virtual account instead of a real one), and to support on-behalf-of structures and in-house banking, where virtual accounts represent internal participants over a central real account.

**Q: What is virtual account management (VAM)?**

Virtual account management is the discipline — and the bank product category — of designing and operating virtual account structures: deciding which real accounts carry which virtual accounts, how the hierarchy is levelled, how virtual balances are tracked as a subledger over the real balance, and how the structure flows into statements and reconciliation. Banks sell VAM as a product; treasury still owns the design, because the bank provides the mechanism, not the structure.

**Q: What are the main types of virtual account structures?**

Three patterns cover most real implementations: per-payer collection structures (a unique virtual IBAN per customer, for automatic receivables identification), segregation structures (a virtual account per entity, business line or purpose over one real account, replacing physical accounts), and in-house-bank structures (virtual accounts representing internal participants over a central real account, supporting on-behalf-of payments and collections). Most real designs combine two of the three.

**Q: What is a multi-level virtual account hierarchy?**

A structure where virtual accounts are nested: a real account at the top, a virtual account per entity beneath it, and further virtual accounts per purpose or customer beneath each entity. Banks differ in how many levels they support and how balances roll up. The working rule is to keep the hierarchy as shallow as the reporting actually requires — every extra level adds mapping, statement volume and explanation, and deep trees are the most common form of VAM over-engineering.

**Q: How do virtual accounts appear in bank statements and reconciliation?**

The cash movement happens on the real account, and the bank reports activity with the virtual account as the identifying reference — depending on the bank, as statements or notifications per virtual account, or as one statement on the real account carrying virtual account references per transaction. That reference is what your reconciliation keys on, so confirming exactly how each bank reports virtual account activity (and testing it with real files) belongs in the design phase, not after go-live.

---

# Liquidity Escalation Framework

Source: https://gravam.com/blog/liquidity-escalation-framework
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: How to build a liquidity escalation framework — thresholds, tiers, actions and owners — so a liquidity squeeze triggers a plan, not panic.

**The worst liquidity decisions are made in real time, under pressure, with no plan — which is exactly when a company is least able to make good ones.** A liquidity squeeze doesn't wait for a calm moment to consult. When cash tightens, the choices come fast and consequential: draw the line now or wait, defer which payments, tap which source — and improvising them is how a manageable squeeze becomes an expensive one, or a survivable one becomes a crisis. A liquidity escalation framework moves those decisions to where they belong: **decided in advance, while calm.** It turns "this feels tight, what do we do?" into a lookup — the tier we're in, the actions authorised at it, the person who takes them. This is how to build one.

## Decide the response before the stress

The core idea is simple and counter-intuitive only because so few treasuries do it: **pre-decide the graduated response to a liquidity squeeze.** Not a single "break glass" plan, but a set of tiers, each with its own triggers, its own authorised actions, and its own circle of people informed. Liquidity rarely fails all at once; it tightens by degrees, and the response should escalate by degrees to match.

The alternative — deciding under pressure — fails in a specific way: the actions taken are driven by whoever's in the room and how alarmed they are, not by a plan. You draw too late, defer the wrong payments, or escalate to the board so early it becomes noise, or so late it becomes a shock. A framework replaces judgement-under-duress with judgement-made-calm.

## The tiers: a graduated response

Structure the framework as tiers, each a defined state with a trigger to enter and a set of actions. A workable shape:

| Tier | Trigger (example basis) | Actions available | Who acts / is informed |
| --- | --- | --- | --- |
| **Normal** | Liquidity comfortably above floor | Business as usual; monitor | Treasury |
| **Watch** | Buffer approaching floor; forecast tightening | Tighten monitoring; prepare actions; review discretionary spend | Treasury lead |
| **Stressed** | Available liquidity below floor | Draw committed lines; defer discretionary payments; mobilise [trapped cash](https://gravam.com/blog/trapped-cash-and-cash-repatriation) | Group treasurer; CFO informed |
| **Critical** | Committed headroom nearly exhausted; access restricted | Raise against collateral; prioritise essential payments only; contingency funding | CFO decides; board escalated |

The triggers must be **concrete numbers agreed in advance** — "available liquidity below X days of cover," not "when it feels tight." Subjective triggers reintroduce exactly the real-time judgement the framework exists to remove.

> A tier without a numeric trigger is a mood, not a control. The framework's power is that "are we stressed?" has an objective answer — a threshold crossed — so the response starts on time, not when someone finally raises the alarm.

## The actions: know them before you need them

Each tier's actions are the [contingency funding](https://gravam.com/blog/corporate-funding-and-credit-facilities) and cash levers, sequenced. The framework's value is that they're **pre-identified and pre-authorised**, with the real constraints known in advance:

- **Committed vs uncommitted headroom** — what you can actually rely on drawing, versus what might not be there when you need it.
- **Deferrable vs essential payments** — decided in advance, so under stress you're not deciding _which_ payments matter while the clock runs.
- **[Trapped cash and repatriation](https://gravam.com/blog/trapped-cash-and-cash-repatriation)** — cash you technically have but can't move fast; know the real time-to-access before you count on it.
- **Collateral and asset sales** — the slower, higher-tier sources, with their real speed known.

The recurring failure is discovering a source's constraints _during_ the squeeze — the "committed" line with a condition, the trapped cash that takes three weeks, the collateral slower to raise than the brochure implied. The framework forces that discovery to happen while calm.

## Ownership and authority: who can act at each tier

A framework without pre-assigned authority stalls at the moment it's needed. Each tier names **who can take its actions** and **who's informed or escalated to** — so nobody's waiting for an approval that isn't defined while liquidity drains. This ties directly to [risk appetite and limits](https://gravam.com/blog/risk-appetite-and-limits-in-treasury): the liquidity buffer floor _is_ a limit, and its breach _is_ an escalation trigger. The escalation framework is what turns that limit from a number on a policy page into an operating response.

## Why liquidity escalation arrives late

- **No pre-agreed triggers.** Escalation happens when someone gets alarmed, so it's always subjective and usually late.
- **Actions discovered under stress.** The "committed" line with a catch, the trapped cash that won't move — found out at the worst moment.
- **Authority undefined.** Actions available but nobody clearly authorised, so the response waits for an approval that isn't specified.
- **All-or-nothing.** A single break-glass plan instead of graduated tiers, so escalation is either ignored or triggers a disproportionate response.
- **Never rehearsed.** A framework on paper that's never walked through, so its gaps surface in the real event.

## Building escalation tiers in calm conditions

Build the framework in the calm, and make the triggers numeric — the liquidity floor, the days-of-cover threshold — so entering a tier is objective, not a judgement call under pressure. Pre-identify and pre-authorise the actions at each tier, and verify the real constraints of each funding source _before_ you count on it. Assign authority per tier, so the response never waits for an undefined approval. And rehearse it at least once, because a framework's gaps only show when you walk it through. Liquidity crises are survived by companies that decided what to do before they had to — and lost control by the ones that improvised.

***

_See also [liquidity risk management](https://gravam.com/blog/liquidity-risk-management) and [corporate funding and credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities)._

## Questions this article answers

**Q: What is a liquidity escalation framework?**

A liquidity escalation framework is a pre-agreed set of thresholds and the graduated actions that trigger when liquidity crosses each one — so a tightening cash position produces a defined response rather than an improvised scramble. It defines the tiers (normal, watch, stressed, critical), the trigger for entering each, the actions available at that tier (draw a committed line, defer discretionary payments, mobilise trapped cash, raise collateral), who's authorised to take them, and who's informed or escalated to. The point is to decide the responses to a liquidity squeeze while calm, so that under pressure the decision is a lookup, not a debate — because the worst liquidity decisions are the ones made in real time with no plan.

**Q: What triggers a liquidity escalation?**

A defined threshold being crossed — not a feeling. Typical triggers include available liquidity (cash plus committed headroom) falling below a set floor, the buffer dropping below a number of days of cover, a forecast showing a shortfall within the horizon, a committed facility nearing its limit, or a market/counterparty event that suddenly restricts access to funding. Each threshold moves the organisation into a higher tier with a different set of pre-authorised actions and a wider circle of people informed. Defining the triggers as concrete numbers, agreed in advance, is what turns escalation from a subjective 'this feels tight' into an objective, actionable process.

**Q: How is a liquidity escalation framework different from contingency funding?**

Contingency funding is part of the framework, not a substitute for it. The escalation framework is the whole graduated structure — the tiers, triggers, actions and owners — that governs the response as liquidity tightens; contingency funding sources (committed lines, collateral, asset sales, intercompany support) are the actions available at the higher tiers. So contingency funding answers 'where does emergency liquidity come from?', while the escalation framework answers 'at what point, decided by whom, do we reach for it, and what do we do first?' You need both: knowing the sources is useless if there's no agreed trigger and owner for using them.

---

# Cash Forecast Operating Model & Ownership

Source: https://gravam.com/blog/cash-forecast-operating-model-and-ownership
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: A cash forecast is a process, not a spreadsheet. Who owns it, who contributes, at what cadence, and how to run the forecast-to-actual loop people trust.

**A cash forecast that nobody trusts is almost always a forecast that nobody owns — a spreadsheet updated from sources of unknown reliability, by people who don't feel accountable for it.** Treasuries pour effort into forecast _methodology_ — [direct vs indirect](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting), the [13-week horizon](https://gravam.com/blog/13-week-cash-flow-forecast), variance metrics — and comparatively little into the _operating model_ that produces it: who contributes what, when, and who's accountable when it's wrong. Yet that's what decides whether a forecast is a trusted decision input or a number people quietly work around. This is how to run the forecast as a process, not a document.

## The forecast is a process with many owners

The first reframe: **treasury owns the forecast; treasury doesn't own the inputs.** The receivables view comes from credit and collections. The payables from procurement and AP. Capex, payroll, tax, financing — each from its own owner. The revenue picture from the business. Treasury owns the model, the consolidation and the outcome, but the raw material comes from people treasury doesn't manage.

That split is the whole problem and the whole solution. The failure is treasury being held accountable for a forecast built entirely from numbers it can't control and nobody else feels responsible for. The fix is an operating model that makes **each contributor accountable for their own input** — so accuracy is owned where it can actually be improved, not pooled into a treasury total nobody outside treasury cares about.

## The forecast operating model, as a table

An operating model answers four questions for every input: who provides it, at what cadence, in what form, and who's accountable for its accuracy. Written down, it looks like this:

| Element | The decision it fixes |
| --- | --- |
| **Contributors** | Who provides each input (receivables, payables, capex…) |
| **Cadence** | How often each input is refreshed, and by when |
| **Format & horizon** | The categories and time buckets everyone submits against |
| **Consolidation** | Who assembles the whole and owns the model |
| **Use** | Which decisions the forecast drives (and at what cadence) |
| **Feedback loop** | Who compares forecast-to-actual and routes it back |
| **Accountability** | Who owns the accuracy of each input, not just the total |

The row that's almost always missing is the last one. Without named input-level accountability, "the forecast is wrong" has no owner — it's everyone's problem and therefore no one's, and it never gets better.

> Treasury owns the total; the contributors own the parts. A forecast where treasury is accountable for numbers it can't control, and the people who can control them aren't accountable, is broken by design — no methodology fixes that.

## The forecast-to-actual loop: the engine of accuracy

An operating model without a feedback loop is just an org chart. The loop is what makes the forecast improve: each period, compare forecast against actual, **broken down by category and contributor**, and route the variance back to the person accountable for that input.

This is the operating side of [measuring forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy): the metric tells you where the error is; the operating model decides what happens next. Two things make the loop work:

- **Attribution.** The variance has to be traceable to a contributor and a category, or "the forecast was off" can't be acted on. A pooled error number improves nothing.
- **Routing.** The feedback goes to the person who can fix the input, not just into a treasury report. A contributor who never sees their own bias never corrects it.

Persistent bias — a contributor reliably optimistic, a category reliably late — is the easiest error to fix once it's visible and owned. The loop is what makes it both.

## Cadence: match the forecast to the decisions

A forecast's cadence should follow the decisions it drives, not a habit. The [short-horizon 13-week forecast](https://gravam.com/blog/13-week-cash-flow-forecast) that drives funding and liquidity decisions needs a weekly rhythm; a longer strategic view moves more slowly. The operating model sets each contributor's refresh cadence _to the decision cadence_, so the forecast is current when a decision is made — not perpetually a week behind because inputs arrive late.

The anti-pattern is a single monthly forecast cycle serving decisions that happen weekly, so treasury is always managing a stale picture and patching it manually between cycles.

## Why forecast ownership breaks down

- **Treasury owns everything.** Held accountable for a forecast built from inputs it can't control, with no contributor accountability.
- **No named contributors.** Inputs arrive from "the business" — unreliably, in different formats, whenever.
- **No feedback loop.** Variance measured (maybe) but never routed back, so the same errors recur every cycle.
- **Pooled error.** "The forecast was 8% off" with no attribution, so nobody can or does improve their piece.
- **Cadence mismatch.** A monthly cycle feeding weekly decisions, so the forecast is always stale.

## Running the forecast as a named process

Run the forecast as a named process, not a spreadsheet someone owns by default. Make each contributor accountable for their own input's accuracy — that single move does more for forecast quality than any methodology change, because it puts accountability where the error can actually be fixed. Build the forecast-to-actual loop with real attribution and routing, so bias becomes visible to the person who can correct it. And set cadence to decisions, not to the calendar. A trusted forecast isn't a better spreadsheet; it's an operating model where everyone who touches it owns their part of it. If you still need the spreadsheet itself, the free [13-week cash flow model](https://gravam.com/tools/13-week-cash-flow-model) is a working template to start from.

***

_See also [how to measure cash forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy) and [the 13-week cash flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast)._

## Questions this article answers

**Q: Who owns the cash forecast?**

Treasury owns the forecast as a whole — its accuracy, its process and its use — but treasury rarely owns the inputs. The receivables forecast comes from credit/collections, the payables from procurement/AP, the capex and payroll from their owners, the revenue view from the business. So ownership is layered: treasury owns the model and the outcome; each contributor owns their input and its accuracy. The failure mode is treasury 'owning' a forecast built from numbers it can't control and nobody else feels accountable for — which is why the operating model has to make each contributor accountable for their piece, not just treasury accountable for the total.

**Q: What is a cash forecast operating model?**

A cash forecast operating model is the defined process behind the forecast: who contributes which inputs, at what cadence, in what format; who consolidates and owns the whole; how the forecast is used to make decisions; and how forecast-to-actual variance is measured and fed back to improve the inputs. A forecast without an operating model is a spreadsheet someone updates when they remember, from sources of unknown reliability, that nobody quite trusts. With one, it's a repeatable process with named contributors, a real cadence, and a feedback loop that makes it better over time — the difference between a number people act on and one they quietly work around.

**Q: How do you improve cash forecast accuracy over time?**

By running a forecast-to-actual loop as part of the operating model, not as an occasional audit. Each period, compare what was forecast against what actually happened, broken down by category and contributor, so you can see where the error is and whose input it came from. Persistent bias — a contributor always optimistic, a category always late — is the easiest thing to correct once it's visible and owned. The key is that the feedback goes back to the contributor accountable for that input, not just into a treasury report nobody outside treasury reads. Accuracy improves when the person who can fix an input sees their own error and owns it.

---

# Treasury Exception Management: Designing the Operating Queue

Source: https://gravam.com/blog/treasury-exception-management
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Treasury runs on exceptions — unmatched transactions, limit breaches, missing rates. How to design one operating queue that catches, routes and clears them.

**A well-run treasury is quiet on the normal path and organised on the exceptions.** When everything goes to plan — statements match, limits hold, rates arrive, interfaces run, approvals clear — good treasury is almost invisible. The actual work, and the actual risk, lives in the exceptions: the item that didn't reconcile, the limit that breached, the rate that's missing, the feed that's late, the approval that's stuck. Most teams handle these as scattered firefighting — a bit in this tool, a bit in that inbox, a lot in someone's head. The teams that stay in control handle them as one thing: a designed **operating queue**. This is how to build it.

## Exceptions are the job — treat them like it

The instinct is to see exceptions as interruptions to the "real" work. Invert that: **the exceptions _are_ the real work.** The straight-through path is automated precisely so people can spend their attention on what fell off it. That reframing changes the design goal — you're not trying to eliminate exceptions (you can't), you're trying to make sure not one of them is invisible, unowned, or overdue.

An exception nobody sees is the one that becomes an incident. So the first property of a good system isn't speed — it's that **everything surfaces in one place**.

## The recurring exception types

They come from every corner of treasury, but they share a lifecycle. Naming them is the start of designing the queue:

| Exception type | What it is | Typical owner | Why it's urgent |
| --- | --- | --- | --- |
| **Unmatched transaction** | A statement item with no matching entry (in SAP, the [FEBAN post-processing](https://gravam.com/blog/feban-bank-statement-post-processing) worklist) | Cash operations | Hides a real cash difference |
| **Limit breach** | Position or counterparty exposure over its limit | Risk / front office | A control failure, possibly a real risk |
| **Missing / stale rate** | A valuation with no current market rate | Market data owner | Every dependent number is now suspect |
| **Interface delay / failure** | A feed that didn't arrive or arrived incomplete | Systems / integration | Downstream numbers silently wrong |
| **Overdue approval** | A payment or deal stuck awaiting release | Approver / ops | A payment may miss its cut-off |
| **Failed payment** | An instruction rejected or returned by the bank | Payments ops | Money didn't move; someone expects it |

Different owners, different urgencies — but the _same shape_: detect, classify, route, resolve, escalate if it ages. That shared shape is exactly why they belong in one queue rather than six disconnected ones.

## The operating queue: five properties

A queue that actually controls exceptions has five properties. Miss any one and it degrades into the inbox chaos it was meant to replace.

1. **Detection.** Every exception type is _actively surfaced_, not waited-for. A missing interface has to raise itself — silence must be an alert, because the most dangerous exception is the one that produces no error, just a wrong number.
2. **Classification.** Each item is typed and prioritised on arrival — severity (how bad) and urgency (how soon), the same two-axis discipline that governs [defect triage](https://gravam.com/blog/defect-triage-and-exit-criteria). A limit breach and a cosmetic mismatch don't get the same lane.
3. **Ownership.** Every item has _one_ named owner. "The team" owns nothing; a person owns it, or it drifts.
4. **Resolution target.** Each type has a time it should clear by — a target, not a hope. That target is what makes ageing meaningful.
5. **Escalation.** When an item breaches its target, it escalates automatically on a defined path. Escalation isn't failure; it's the queue doing its job.

> The measure of an exception process isn't how few exceptions you have — it's how few are invisible, unowned, or past their target. You can't stop exceptions arriving. You can stop them hiding.

## Ageing and escalation: the health of the queue

The single most useful view of a treasury operation is its **exception ageing**: how many items are open, of what type, and how long they've sat. It's the operational equivalent of a [KPI dashboard](https://gravam.com/blog/treasury-kpis-measuring-treasury-performance) — a real-time read on whether the team is on top of the work or slowly drowning.

Two signals matter most:

- **The oldest items.** As with defects, the risk hides in the _oldest_ open exceptions — usually the hard ones everyone routes around. A queue full of fresh items being cleared is healthy; a queue with a tail of aged items is a problem wearing a calm face.
- **The trend.** Is the queue clearing faster than it fills, or slowly growing? A growing queue is a staffing, automation, or upstream-quality problem announcing itself early.

## Where the operating model comes in

Exception management is also an [operating-model](https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized) question: in a centralised treasury, one queue serves the group; in a hybrid, central and regional teams each own their lanes but against shared standards and a shared view. Either way, the anti-pattern is the same — exceptions siloed by tool or team so no one sees the whole, and the same item bounces between owners because responsibility was never assigned. Decide who owns each exception _type_, not just each exception.

Done well, the queue is also the seed of a dashboard, and eventually a tool: a single, prioritised, owned list with ageing and escalation built in. Many treasuries discover their most valuable internal tool isn't a forecaster or a pricer — it's the thing that makes sure nothing falls through the cracks.

## What good looks like

- **One queue, every exception type** — nothing lives only in a private inbox.
- **Detection is active**, including silence-as-alert for interfaces and feeds.
- **Every item is typed, prioritised, and owned by a person**, with a resolution target.
- **Ageing is visible and escalation is automatic** past target.
- **Ownership is assigned by exception type**, so items don't bounce.

Treasury will always generate exceptions — matching won't be perfect, feeds will slip, limits will get tested, approvals will stall. The question is never whether they happen; it's whether they're worked as a designed, owned, measured queue or survived as daily chaos. Build the operating queue and exceptions become routine, controlled and provable. Leave them scattered and you'll keep discovering the important one the same way every time: late, and as an incident.

***

_See also [the treasury operating model](https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized) and [treasury KPIs](https://gravam.com/blog/treasury-kpis-measuring-treasury-performance)._

## Questions this article answers

**Q: What is treasury exception management?**

Treasury exception management is the disciplined handling of everything that doesn't go to plan — the unmatched transaction, the limit breach, the missing market rate, the delayed interface, the overdue approval. In a well-run treasury, the normal processes are automated and quiet; the real work is the exceptions, and the question is whether they're caught, routed to an owner, and cleared on time, or whether they pile up unseen until one becomes an incident. Exception management turns that scattered firefighting into a single, designed operating queue: every exception detected, classified, owned, and resolved against a target.

**Q: Why does treasury need a single exception queue?**

Because exceptions arrive from everywhere — payments, reconciliation, risk limits, market data, interfaces, approvals — and if each lives in its own tool or inbox, no one sees the whole picture and things fall between the cracks. A single operating queue gives treasury one place where every exception surfaces, so nothing is invisible, ownership is explicit, ageing is measurable, and escalation is automatic when something sits too long. It's the difference between a team that reacts to whatever shouts loudest and one that works a prioritised, owned list — and can prove, to an auditor or a CFO, that exceptions are controlled rather than merely survived.

**Q: What are common treasury exceptions?**

The recurring ones are: unmatched or unreconciled transactions (a statement item with no matching entry), limit breaches (a position or counterparty exposure over its limit), missing or stale market rates (a valuation with no rate to price it), interface delays or failures (a feed that didn't arrive or arrived incomplete), and overdue approvals (a payment or deal stuck awaiting release). Each has a different owner and urgency, but all share the same lifecycle — detect, classify, route, resolve, escalate if overdue — which is exactly why they belong in one designed queue rather than five separate ones.

---

# Intraday Liquidity Management: The Operating Model

Source: https://gravam.com/blog/intraday-liquidity-management
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Cash is a moving position through the day, not a daily number. How to run intraday liquidity: payment queues, cut-offs, intraday credit and alerts.

**A cash position that's healthy at 5pm can fail at 11am.** Most treasury reporting answers one question — how much cash did we have at end of day — and stays silent on the one that actually determines whether payments go out: how much did we have _at each moment_. Intraday liquidity is that missing dimension. It's the difference between a [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) that nets out fine and an operation that never gets caught short within the day. For time-critical payments, netting is a comfort that arrives too late — a receipt at 3pm doesn't fund an obligation due at 11am. This is how to run cash as the moving position it really is.

## The day is a sequence, not a balance

Reframe the mental model. End-of-day cash is a _photo_; intraday liquidity is the _film_. Through the day, obligations fall due at particular times and receipts arrive at particular times, and the two don't line up neatly. The position rises and falls, sometimes dipping below zero against a specific account even though the day closes comfortably.

So the governing question stops being "how much cash do we have?" and becomes "will we have enough, **in the right account, at the moment each obligation is due**?" Everything in intraday liquidity management follows from taking that timing seriously.

## The components of the intraday position

The Basel Committee's framework for monitoring intraday liquidity — designed for banks, but a clean map for anyone making time-critical payments — names the dimensions worth tracking. Adapted to an operating model, they are:

| Component | The question it answers |
| --- | --- |
| **Opening liquidity** | What do we start the day with, per account? |
| **Intraday inflows** | What's arriving, and _when_ — with what certainty? |
| **Intraday outflows** | What must go out, and by _when_? |
| **Time-specific obligations** | Which payments have a hard deadline (not just "today")? |
| **Available intraday credit** | What committed line bridges a timing gap? |
| **Collateral** | What can we raise liquidity against, how fast? |
| **Maximum intraday usage** | What's the largest net drawdown during the day? |

The one most teams under-track is **time-specific obligations** — payments that aren't just "due today" but due _by a specific hour_ (a market settlement, a margin call, a payroll cut-off). Those are where intraday risk concentrates, because they can't wait for the afternoon's receipts.

## Payment queues and cut-offs: where timing becomes real

Two operational realities turn the abstract position into a live constraint:

- **Cut-off times.** Every payment channel and currency has a deadline after which an instruction won't settle same-day. A payment "made" at 4pm that missed a 3pm cut-off didn't happen today. Managing intraday liquidity means managing _against cut-offs_, not against midnight.
- **Payment queues.** When outflows are sequenced (or held pending funds), the _order_ matters. Release the discretionary payment first and you may not have funds for the time-critical one behind it. A deliberate queue — time-specific and high-value obligations prioritised, discretionary payments held until funded — is the core operational control.

> The end-of-day balance says the day was fine. The payment queue and the cut-off clock decide whether it actually was. Manage the queue, not the closing number.

## Bridging the gaps: credit and collateral

When an obligation falls due before its funding arrives, something has to bridge the gap. The failure mode is discovering that gap in real time; the discipline is planning the bridge in advance:

- **Committed intraday credit / overdraft** — a line you can draw within the day and repay as receipts land. It has a cost, and the goal is to use it deliberately for known timing gaps, not accidentally because a queue was mismanaged.
- **Collateral** — assets you can raise liquidity against, with a known speed. Fast in theory is often slow in a stressed morning; know the real time-to-liquidity, not the brochure one.

Both belong to [liquidity risk management](https://gravam.com/blog/liquidity-risk-management): intraday is the shortest-horizon face of the same discipline that runs buffers and facilities for longer horizons. The tighter your intraday visibility, the less standing buffer you carry to cover the unknown — visibility substitutes for cushion.

## Alerts and escalation: the operating loop

Intraday liquidity is a monitored process, not a report you read once. The loop:

1. **Set thresholds** per key account — a level that, if breached, means a time-critical obligation is at risk.
2. **Alert in real time** when a threshold is approached, ideally _before_ the cut-off that would make it unrecoverable.
3. **Escalate on a defined path** — who's called, who can draw the line, who can reprioritise the queue. An alert with no owner is noise.
4. **Review after the day** — did we come close, and why? The near-misses are the signal; a day that "went fine" can still have been one delayed receipt from a problem.

This is where [real-time treasury](https://gravam.com/blog/real-time-treasury) earns its keep: real-time balances and payment status are what make the loop possible. Without live data, "intraday management" is just a faster version of finding out too late.

## What good looks like

- **The position is tracked through the day, per account** — not just closed at end of day.
- **Time-specific obligations are identified and prioritised** in a deliberate payment queue, managed against cut-offs.
- **Timing gaps are bridged on purpose** with pre-arranged intraday credit or collateral, at a known real speed.
- **Thresholds alert in real time with an owned escalation path**, and near-misses are reviewed, not ignored.
- **Intraday visibility reduces standing buffers** — you hold less idle cash because you can see and manage the day.

Most treasuries manage cash as a daily number because that's what the systems report. The ones that don't get caught short manage it as a moving position — sequenced, monitored, bridged. Build the intraday operating model and the 11am surprise stops being a surprise; skip it, and the end-of-day balance will keep telling you everything was fine about days that very nearly weren't.

***

_See also [how to build a daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) and [real-time treasury](https://gravam.com/blog/real-time-treasury)._

## Primary sources

The BCBS monitoring tools are a banking-supervision framework; the measures and concepts are applied here to a corporate/operational intraday liquidity model. Regulatory obligations depend on your entity type and jurisdiction.

- BCBS — Monitoring tools for intraday liquidity management (Basel Committee) — accessed 2026-07-28 — https://www.bis.org/publications/201304-standards-monitoring-tools-intraday-liquidity-management

## Questions this article answers

**Q: What is intraday liquidity management?**

Intraday liquidity management is running your cash as a position that moves through the day, not a single end-of-day balance. It's about having the right funds in the right account at the right moment to meet payment and settlement obligations as they fall due — managing opening liquidity, the timing of inflows and outflows, payment queues and cut-off times, and the intraday credit or collateral that bridges timing gaps. A day that ends with plenty of cash can still fail at 11am if a large payment is due before the receipts that fund it arrive. Intraday liquidity is the discipline of never being caught short within the day, even when the day nets out fine.

**Q: Why does intraday liquidity matter if the day nets out?**

Because obligations have timing, and timing doesn't net. A payment due at a specific hour must be funded by then — it can't borrow from a receipt that arrives that afternoon. The end-of-day balance hides this entirely: it shows the day was fine on net while saying nothing about the moments within it when you were short. Getting intraday wrong means missed or delayed settlements, unplanned intraday overdraft cost, and in stressed conditions a genuine inability to meet an obligation on time. The net position is the scoreboard; intraday liquidity is whether you survived the game.

**Q: What are the sources of intraday liquidity?**

Broadly: your own balances held at the start of the day, incoming payments as they arrive through the day, committed intraday credit or overdraft lines from your banks, and liquidity you can raise against collateral. The art is sequencing them — knowing which obligations must be met before which receipts arrive, and having a deliberate bridge (credit or collateral) for the gaps, rather than discovering a shortfall in real time. The Basel Committee's intraday monitoring framework formalises these dimensions for banks; the same components describe any entity that has to make time-critical payments.

---

# Trapped Cash and Cash Repatriation

Source: https://gravam.com/blog/trapped-cash-and-cash-repatriation
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Trapped cash is money the group owns and can see but can't freely move to where it's needed — here's why it gets stuck and how treasury frees it.

**Trapped cash is money the group owns and can see, but can't freely move to where it's needed.** Your consolidated dashboard shows a healthy total, yet a chunk of that total is stranded inside a subsidiary — usually overseas — pinned there by regulation, tax, capital rules, part-owners or plain contract. The group looks liquid; the parent is short. I've watched a treasurer stare at a nine-figure group cash number during a funding squeeze and slowly realize that the tens of millions sitting in one region might as well have been on the moon.

## Visibility is step one. Mobility is the next problem.

This is the sequel to [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility). Visibility answers _how much cash does the group have and where is it?_ Once you can finally see all of it, the very next question — the one that catches people out — is _how much of it can I actually use?_ Those are different numbers, and the gap between them is trapped cash. Seeing cash and being able to move it are two separate battles, and winning the first does nothing to win the second.

## Gross cash is not available cash

The single most useful distinction here is between **gross cash** and **freely-available cash**. Gross cash is what the group holds in total. Freely-available cash is the subset the parent can concentrate and deploy on demand — no consent needed, no punitive tax, no regulatory wall. Trapped cash is the difference.

The danger is subtle because trapped cash doesn't reduce the group total — it inflates it relative to what's usable. A treasurer who manages to the headline number is managing to a figure that's larger than the money actually within reach. That's how a group that "has plenty of cash" ends up drawing on a revolver to cover the parent while cash sits idle in three subsidiaries it can't touch this quarter.

> The number on the group cash dashboard is not the number you can spend. The gap between them is trapped cash — and discovering that gap during a liquidity squeeze is the most expensive way to learn the difference.

## Why cash gets trapped

It's worth knowing the categories, because each one has a different remedy — and they stack. I'll describe the types, not specific countries, because those rules change constantly and anything I named today would be wrong by the time you read it.

- **Foreign-exchange and capital controls.** Some jurisdictions restrict converting local currency or moving funds across the border. The cash is real, in a real account, and you simply can't get it out at will.
- **Tax cost on repatriation.** Moving cash home — as a dividend, say — can trigger withholding tax or other tax leakage. The cash isn't legally frozen, but the cost of freeing it can be steep enough that you don't.
- **Regulatory capital and reserve requirements.** Regulated entities, and sometimes ordinary local companies, must hold minimum capital or reserves. That floor is cash you can see but are not permitted to sweep away.
- **Minority shareholders.** In a partly-owned entity, you don't own all the cash. Distributions have to be shared, and moving money up may need consent you can't assume.
- **Operational and contractual restrictions.** Loan covenants requiring local balances, local banking rules, collateral and cash-pledge arrangements — mundane, easy to miss, and every bit as effective at pinning cash in place.

Real trapped cash is usually a combination: a partly-owned regulated subsidiary in a jurisdiction with FX controls will hit three of these at once.

## The repatriation toolkit

When cash _can_ be moved but needs a route, treasury has a familiar set of tools — and every one of them has tax and legal consequences that must be planned deliberately, never improvised:

- **Dividends** — the cleanest route in principle: distribute retained earnings up to the parent. Subject to distributable-reserves rules, board and sometimes shareholder approval, and whatever tax the distribution attracts.
- **Intercompany loans** — the subsidiary lends surplus cash up to the group (or a [central treasury vehicle](https://gravam.com/blog/what-is-an-in-house-bank)) and it's repaid later. Flexible and reversible, but must be a genuine loan on proper terms, with interest that satisfies transfer-pricing rules.
- **Royalties** — where the entity uses group intellectual property, a licensing arrangement moves value out as royalty payments. Only valid where the IP and the licence are real.
- **Management/service fees and transfer pricing** — charging the subsidiary for genuine services the group provides, priced at arm's length. The key word is _genuine_ — the service and the price both have to withstand scrutiny.

None of these are treasury's to design alone. They live at the intersection of tax, legal and treasury, and the fastest way to turn a repatriation into a liability is to run one ahead of the advice.

## Manage it, don't just move it

Here's the shift that matters: not all trapped cash should be repatriated. Sometimes the economics of freeing it are worse than the cost of leaving it, and the right move is to _manage_ it in place.

- **Forecast at the entity level, not just the group level.** If you only forecast the consolidated position, trapped cash silently pads your liquidity and hides the parent's real shortfall. Forecast per entity and you see which cash is genuinely available and which is stranded.
- **Deploy trapped cash locally.** Cash you can't move can still work: pay local costs and local debt from it, fund local capex, invest it in permitted local instruments. Idle trapped cash is the worst of both worlds.
- **Factor mobility into the operating model.** How you structure entities, ownership and flows determines how much cash traps in the first place. Your [treasury operating model](https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized) and pooling design should treat mobility as a first-class constraint, not an afterthought.
- **Stop trapping more.** [Physical and notional pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) work only across cash that can legally move together — so structure new flows to keep cash mobile, and don't route fresh money into corners you already know you can't get it out of.

## The docs-versus-reality gap

The org chart and the cash dashboard tell you the group has X. The documentation of your pooling structure implies it all concentrates neatly to the header account. Reality is that a slice of X is behind an FX control, a slice is minority-owned, a slice is a regulatory reserve, and a slice would cost a painful tax bill to move — and none of that shows up until you try to actually pull the cash. The single discipline that saves you is separating total from available _before_ you need the money, so the trapped portion is a known, forecast number rather than a nasty surprise mid-squeeze.

You can see all your cash and still be short. Visibility gets you the map; understanding what's trapped is what tells you which of it you can actually spend.

***

_See also [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility) and [physical vs notional cash pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling)._

## Questions this article answers

**Q: What is trapped cash?**

Trapped cash is cash the group legally owns and can see on its dashboards, but cannot freely move to where the group needs it. It sits in a subsidiary — often overseas — held there by regulation, tax cost, capital requirements, minority shareholders or contractual restrictions. The group total looks healthy, but the parent can't actually draw on that money on demand, so it's real cash the treasurer can't use when it matters.

**Q: Why is cash trapped in some countries?**

Several categories of restriction can trap cash, often in combination. Foreign-exchange or capital controls in some jurisdictions limit converting or moving currency out. Repatriating cash — via dividends, for example — can trigger withholding tax or other tax cost that makes moving it expensive. Local rules may require a subsidiary to hold minimum capital or reserves. Minority shareholders in a partly-owned entity have a claim on distributions. And ordinary operational or contractual terms — loan covenants, local banking rules — can pin cash in place. It's rarely one reason; it's usually a stack of them.

**Q: How do companies repatriate trapped cash?**

Through a handful of routes, each with tax and legal consequences: dividends up to the parent, intercompany loans and their repayment, royalties for licensed IP, and management or service fees and transfer pricing for genuine services rendered. None of these should be improvised — each has to stand up to tax and regulatory scrutiny and be planned with tax and legal advisors. Where cash genuinely can't be moved economically, the better answer is often to stop trying to move it and instead deploy it locally: pay local costs, invest it locally, and forecast at the entity level so it isn't counted as group liquidity it isn't.

---

# Supply Chain Finance and Dynamic Discounting

Source: https://gravam.com/blog/supply-chain-finance-and-dynamic-discounting
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: Supply chain finance (reverse factoring) pays suppliers early via a bank on the buyer's credit; dynamic discounting uses the buyer's cash. When to use each.

**Supply chain finance and dynamic discounting both solve the same tension — the buyer wants to pay later, the supplier wants to be paid sooner — but they solve it with different money.** Supply chain finance, usually reverse factoring, brings in a third-party financier who pays the supplier early on the strength of the buyer's credit. Dynamic discounting skips the financier entirely and uses the buyer's own surplus cash. Knowing which one fits a situation — and being honest about what each one does to the balance sheet — is squarely a treasury job. This builds directly on [working capital and the cash conversion cycle](https://gravam.com/blog/working-capital-and-cash); if that piece is the diagnosis, this one is two of the treatments.

## The tension these tools resolve

The conflict is baked into the [cash conversion cycle](https://gravam.com/blog/working-capital-and-cash). The buyer improves its working capital by stretching DPO — paying suppliers later holds onto cash longer. The supplier improves its own working capital by shrinking DSO — being paid sooner. Those two goals point in opposite directions across the same invoice. Left alone, one side wins and the other pays for it, usually the supplier, and usually the smaller party with the weaker balance sheet and the more expensive borrowing.

What supply chain finance and dynamic discounting do is break the trade-off. They let the supplier get paid early _and_ let the buyer keep — or even extend — its terms, because a third source of money sits in between. The whole design question is where that money comes from.

## Supply chain finance (reverse factoring)

In reverse factoring the buyer sets up the programme. It approves supplier invoices for payment, and a financier — a bank or a platform — pays the supplier early, minus a small discount. The crucial detail is how that discount is priced: off the **buyer's** credit, not the supplier's. A large, well-rated buyer typically borrows far more cheaply than its mid-sized suppliers, so early cash priced on the buyer's rating is cheap money for the supplier — often cheaper than anything the supplier could arrange alone.

The buyer then pays the financier at the invoice's maturity, and that maturity is frequently _extended_ beyond the original terms. So the supplier is paid early, the financier earns its spread, and the buyer holds cash longer. It reads like everyone winning, which is exactly why it needs a sceptical eye.

Note the contrast with traditional factoring: there the _supplier_ sells its receivables to raise cash, on its own credit. Reverse factoring inverts that — the _buyer_ arranges it, on its credit, for the supplier's benefit. Same early payment, different party in the driving seat, and a very different price.

## Dynamic discounting

Dynamic discounting throws out the financier. The buyer pays suppliers early using its **own** surplus cash, and in return takes a discount that _slides_ with timing — the earlier it pays, the larger the discount. Pay an invoice well ahead of its due date and the discount is meaningful; pay closer to the date and it shrinks toward zero.

For a buyer sitting on idle cash, this is a return on that cash, and the effective yield frequently beats what the same balance would earn on deposit — see [debt and investment management](https://gravam.com/blog/debt-and-investment-management-in-treasury) for how this sits alongside the rest of the short-term portfolio. There is no third party, no credit facility, no financier to onboard or fall out with. It is simpler, and the supplier relationship is direct: the buyer's cash, the supplier's early payment, a discount both agreed.

> Reverse factoring is someone else's money bridging the gap; dynamic discounting is your own money earning a return in the gap. That single difference decides almost everything about when to reach for each.

## When to use which

The choice comes down to two questions: does the buyer have surplus cash, and does it want to extend terms?

- **Reach for supply chain finance** when the buyer wants to _lengthen_ payment terms without starving suppliers, and prefers third-party funding to deploying its own cash. It is the tool for improving your own DPO while giving suppliers cheap early liquidity — and for buyers whose cash is better used elsewhere.
- **Reach for dynamic discounting** when the buyer has _surplus cash_ and wants a return on it plus supplier goodwill, without taking on any programme financing. It is the tool for a cash-rich buyer that would rather earn a discount than a deposit rate.

They are not mutually exclusive. Plenty of treasuries run both — dynamic discounting when cash is flush, a reverse factoring programme underneath for scale and for the periods when cash is better deployed elsewhere.

## The caveat treasury has to own

Here is the part the sales deck skips. Reverse factoring has drawn real scrutiny over whether the extended payables it funds are genuinely trade payables or _disguised debt_. When a programme is used mainly to stretch terms, the economic substance can look a lot like borrowing — money owed to a financier — while it sits on the balance sheet as ordinary payables, flattering both leverage and the working-capital story.

Both major accounting standard-setters have responded with **disclosure requirements**, so these programmes surface rather than hide.

**Under IFRS**, the IASB issued [_Supplier Finance Arrangements_](https://www.ifrs.org/news-and-events/news/2023/05/iasb-increases-transparency-of-companies-supplier-finance/) on 25 May 2023, amending IAS 7 _Statement of Cash Flows_ and IFRS 7 _Financial Instruments: Disclosures_. It applies to annual reporting periods beginning on or after 1 January 2024. A company must disclose the terms and conditions of its arrangements; the amount of the liabilities that are part of them, breaking out the amounts for which suppliers have already been paid by the finance providers, and where those liabilities sit on the balance sheet; the ranges of payment due dates; and liquidity risk information. The IASB described the amendments as its response to investors' concerns that some companies' supplier finance arrangements are not sufficiently visible.

**Under US GAAP**, the FASB issued [Accounting Standards Update No. 2022-04](https://storage.fasb.org/ASU%202022-04.pdf), _Liabilities—Supplier Finance Programs (Subtopic 405-50): Disclosure of Supplier Finance Program Obligations_, in September 2022. A buyer must disclose, each year, the key terms of the programme — including payment terms and any assets pledged or guarantees given to the finance provider — the amount of confirmed obligations still outstanding at period end, where those obligations are presented in the balance sheet, and a rollforward of them: opening balance, amounts added, amounts settled, closing balance. The outstanding amount is also disclosed in each interim period. The update is effective for fiscal years beginning after 15 December 2022, except the rollforward, which is effective for fiscal years beginning after 15 December 2023.

Note what neither does. The FASB states that its amendments "do not affect the recognition, measurement, or financial statement presentation" of these obligations; both sets of rules make the programme visible, they do not decide whether it is debt. That classification judgement remains with the company and its auditors, and it is not sourced here. Nor does this page name the corporate failures usually cited in this debate — the standard-setters' own documents are the evidence used.

Operationally the principle is unchanged, and the disclosures now enforce it: treasury must be able to produce the outstanding confirmed amount, the split already paid by the financier, and the payment-term ranges on demand. If a programme materially changes the nature of what you owe, treat that honestly, disclose it, and do not use it to make leverage look better than it is. This connects to how [funding and credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities) are reported — the same instinct to show real obligations as what they are.

## The fine print in supply chain finance

Supply chain finance is marketed as free working capital: suppliers happy, terms extended, no cost to you. The free part has fine print.

- **Supplier concentration on the programme.** The more suppliers depend on it for liquidity, the more a wobble in the programme becomes a supply-chain problem, not just a finance one.
- **The reclassification question.** As above — extended payables funded this way can attract the debt-versus-payables argument, and you want to have answered it before an analyst asks.
- **Dependence on the financier's appetite.** The programme runs on a third party's willingness to keep funding it. Appetite can shrink — in a stress, precisely when suppliers most need the early cash — and you are left having built supplier cash flows on a facility that can be pulled.

Dynamic discounting sidesteps most of this because it is your own cash and no financier, but it has its own limit: it only works while you _have_ surplus cash, and it competes with every other use of that cash.

Both tools are genuinely useful. Used well, they turn the DPO-versus-DSO fight into something both sides win. Used to dress up the balance sheet, reverse factoring in particular becomes exactly the kind of hidden leverage that catches teams out. Structure it transparently, keep the [bank and financier relationships](https://gravam.com/blog/bank-relationship-management) honest, and treat these as what they are — [liquidity](https://gravam.com/topics/cash-and-liquidity-management) tools, not accounting tricks.

***

_See also [working capital and the cash conversion cycle](https://gravam.com/blog/working-capital-and-cash) and [corporate funding and credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities)._

## Primary sources

Disclosure requirements verified against the IASB's announcement of Supplier Finance Arrangements (amendments to IAS 7 and IFRS 7, issued 25 May 2023) and the text of FASB Accounting Standards Update No. 2022-04. Both are disclosure rules. Whether a given programme's liabilities should be presented as trade payables or as borrowings is a separate judgement that this page does not source — take it to your auditors. No specific company case is cited.

- IFRS Foundation — IASB increases transparency of companies' supplier finance (news, 25 May 2023) — accessed 2026-10-04 — https://www.ifrs.org/news-and-events/news/2023/05/iasb-increases-transparency-of-companies-supplier-finance/
- IFRS Foundation — Supplier Finance Arrangements (completed project: amendments to IAS 7 and IFRS 7) — accessed 2026-10-04 — https://www.ifrs.org/projects/completed-projects/2023/supplier-finance-arrangements/
- FASB — Accounting Standards Update No. 2022-04, Liabilities—Supplier Finance Programs (Subtopic 405-50): Disclosure of Supplier Finance Program Obligations (September 2022) — accessed 2026-10-04 — https://storage.fasb.org/ASU%202022-04.pdf

## Questions this article answers

**Q: What is supply chain finance?**

Supply chain finance, in its most common form reverse factoring, is a buyer-arranged programme in which a financier pays a supplier's approved invoices early at a small discount, priced off the buyer's (usually stronger) credit, and the buyer settles with the financier at the invoice's maturity — often on extended terms. The supplier gets cheap early cash; the buyer keeps or lengthens its payment terms. Unlike traditional factoring, which the supplier arranges by selling its own receivables, supply chain finance is set up by the buyer for its supplier base.

**Q: What is the difference between supply chain finance and dynamic discounting?**

Supply chain finance and dynamic discounting both let a supplier be paid early, but the funding source differs. Supply chain finance (reverse factoring) uses a third-party financier who fronts the cash on the buyer's credit; the buyer repays later. Dynamic discounting uses the buyer's own surplus cash to pay early in exchange for a discount that slides with how early payment is made — no financier, no borrowing. Reverse factoring suits a buyer that wants to extend terms without hurting suppliers; dynamic discounting suits a buyer with idle cash looking for a return that beats a deposit plus supplier goodwill.

**Q: Is reverse factoring debt?**

Reverse factoring can be debt, and that is exactly the scrutiny it has drawn. When a buyer uses reverse factoring to stretch payment terms and the arrangement changes the economic substance of what it owes, accounting standard-setters and analysts have questioned whether those extended payables are really disclosed borrowing dressed up as ordinary trade payables. The two main standard-setters have each added disclosure requirements to surface these programmes: the IASB's Supplier Finance Arrangements amendments to IAS 7 and IFRS 7, issued 25 May 2023 and effective for annual periods beginning on or after 1 January 2024, and the FASB's Accounting Standards Update 2022-04, effective for fiscal years beginning after 15 December 2022. Both are disclosure rules — the FASB states that its update does not change recognition, measurement or presentation — so they make a programme visible without deciding whether it is debt. The honest treasury position is to structure the programme transparently and not use it to flatter the balance sheet.

---

# Money Market Funds for Corporate Treasury

Source: https://gravam.com/blog/money-market-funds-for-corporate-treasury
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: Money market funds pool short-dated, high-quality instruments to give treasury same-day liquidity and a yield on cash — inside policy, not chasing return.

**A money market fund pools your cash with everyone else's into a diversified portfolio of short-dated, high-quality instruments, and gives you back same-day or next-day liquidity plus a modest yield.** For corporate treasury it is one of the most common homes for operating and reserve cash — a rated, transparent, professionally managed vehicle that sits neatly inside the security-then-liquidity-then-yield discipline. It earns its place not by paying the most, but by preserving capital and staying liquid while it does. Reach for it the other way round and it will teach you the difference the hard way.

_(This is general education on how corporate treasury uses these funds, not investment advice — the point is the treasury lens, not a recommendation for any specific situation.)_

## How to choose a money market fund for corporate treasury

There is no "best" money market fund for corporate treasury, and this site does not name funds. That is not coyness: the right fund depends on your currency, your jurisdiction, your investment policy and the day's cut-off times, and a list of names would be stale the moment a fund's portfolio or rating changed. What can be stated — and checked — is the set of criteria a treasury uses to choose one:

1. **Fund type and NAV behaviour.** In the EU, is it a public debt CNAV, an LVNAV or a VNAV fund, and is it short-term or standard? In the US, is it a government fund with a stable share price or an institutional prime fund with a floating NAV? The type decides what the fund may hold and whether the price you redeem at can move. The categories are defined in law — see [what the rules say](https://gravam.com/blog/money-market-funds-for-corporate-treasury#what-the-rules-actually-say) below.
2. **Credit quality.** What the fund holds, and whether it carries a money-market fund rating that meets your policy's floor. A rating is a starting point, not a substitute for looking at the holdings.
3. **Maturity limits: WAM and WAL.** Weighted average maturity measures interest-rate sensitivity; weighted average life measures how long the credit is really outstanding. Both the EU regulation and the SEC's rule cap them at 60 and 120 days for the short-term fund types. A standard EU fund is allowed up to 6 and 12 months, which makes it a different instrument.
4. **Liquidity terms.** Same-day or next-day settlement, the dealing cut-off time in your time zone, and the fund's daily and weekly liquid-asset levels against the regulatory minimums. Also read what the fund may do in stress — liquidity fees, and in the EU redemption gates or suspension.
5. **Fund size and your share of it.** A holding that is a large fraction of a fund makes you part of its liquidity problem. A policy can cap the treasury's position as a percentage of the fund's assets; the right percentage is a policy choice, not a regulatory number.
6. **Currency.** The fund should be in the currency the cash is needed in. A fund in another currency adds an FX position to what was meant to be a cash holding.
7. **Policy and counterparty limits.** Is the fund type on the investment policy's permitted list, and does the look-through exposure to the underlying issuers — often the same banks you already hold deposits with — stay inside your [counterparty limits](https://gravam.com/blog/managing-surplus-cash)?

A fund that passes all seven is a candidate. Yield is what you compare _between_ candidates, never the reason one becomes a candidate.

## What a money market fund actually is

Start from the [short-term investment basics](https://gravam.com/blog/managing-surplus-cash): once you have surplus cash and a policy, you need somewhere to put it. A money market fund (MMF) is one option — a collective fund that invests in the money markets, meaning very short-dated, high-quality instruments: government paper like Treasury bills, repurchase agreements (repo), commercial paper (CP), and certificates of deposit (CDs). You buy units in the fund rather than the underlying paper directly, and in return you get diversification, professional management, and typically same-day or next-day access to your money.

The appeal for treasury is that it does three jobs at once. It puts idle cash to work at a yield. It keeps that cash liquid. And it spreads the underlying credit across many issuers instead of parking it all with a single bank. For a treasurer whose real job is preserving operating cash rather than growing it, that combination is exactly the right shape.

## The main types

Not all MMFs sit in the same place on the risk spectrum, and the distinction matters more than the marketing sometimes suggests.

- **Government / treasury funds** hold government paper and government-backed repo. This is the lower-risk end: the underlying credit is about as good as short-term paper gets, and the yield reflects that. When capital preservation is the whole point, this is usually where it starts.
- **Prime funds** can also hold high-grade corporate instruments — CP and CDs from banks and companies. That broader universe typically pays a little more, but "a little more yield" is never free: it comes from taking a little more credit and liquidity sensitivity. In the US there are also **municipal** funds that hold short-dated municipal paper, relevant mainly for their tax treatment.

Cutting across those categories is the **NAV** distinction. Some funds aim to hold a stable, constant net asset value (CNAV) — a unit is worth what you paid, and you think of it like cash. Others carry a variable NAV (VNAV) that moves, however slightly, with the value of the underlying holdings. The stable-NAV label is convenient, but it is worth remembering it is an accounting and structural feature, not a guarantee that value can never move.

## What the rules actually say

"Government versus prime" and "CNAV versus VNAV" are market shorthand. The legal categories are narrower, and they differ between the EU and the US.

**In the EU**, the rulebook is [Regulation (EU) 2017/1131](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R1131) on money market funds, dated 14 June 2017 and applying from 21 July 2018 (Article 47). Article 3 allows exactly three types:

- **Public debt CNAV MMF** — seeks an unchanging NAV and must invest at least 99.5% of its assets in the public debt instruments listed in Article 17(7), reverse repo secured with government debt, and cash.
- **LVNAV MMF** (low-volatility NAV) — may deal at a constant NAV only while that constant NAV stays within 20 basis points of the mark-to-market NAV. Beyond that, the next redemption or subscription is at the mark-to-market NAV (Article 33).
- **VNAV MMF** — deals at a variable NAV.

Separately, a fund is either **short-term** or **standard**. A short-term MMF must keep WAM at no more than 60 days and WAL at no more than 120 days (Article 24). A standard MMF may run WAM up to 6 months and WAL up to 12 months (Article 25), and a standard MMF cannot be a public debt CNAV or an LVNAV fund — so every constant-NAV fund in the EU is a short-term fund.

The same articles set liquidity floors: LVNAV and public debt CNAV funds must hold at least 10% of assets in daily maturing assets and 30% in weekly maturing assets; VNAV funds, 7.5% and 15%. Diversification is written in too: as a general rule no more than 5% of assets in money market instruments from one issuer and no more than 10% in deposits with one bank, with derogations set out in Article 17.

Fees and gates apply to public debt CNAV and LVNAV funds (Article 34). If weekly maturing assets fall below 30% _and_ net redemptions on one day exceed 10% of assets, the fund's board must assess the situation and may apply liquidity fees, gate redemptions to 10% of units a day for up to 15 working days, suspend redemptions for up to 15 working days — or take no immediate action. If weekly maturing assets fall below 10%, the board must apply liquidity fees or a suspension. And Article 35 prohibits external support: a sponsor may not step in to prop up the NAV.

**In the US**, money market funds are governed by the SEC's rule 2a-7. Two things matter for a corporate investor:

- **Who floats.** Government and retail funds may sell and redeem at a stable share price, typically $1.00. Institutional prime and institutional tax-exempt funds must use a floating NAV, rounded to the fourth decimal place — a requirement that dates from the SEC's 2014 reforms. A corporate treasury is an institutional investor, so its stable-price option in the US is a government fund.
- **The 2023 amendments.** The SEC adopted [further reforms](https://www.sec.gov/files/rules/final/2023/33-11211.pdf) on 12 July 2023, with the rule amendments effective 2 October 2023. They removed a fund's ability to suspend redemptions through a gate and cut the link between liquidity thresholds and liquidity fees. They raised the minimum daily and weekly liquid assets to 25% and 50% (from 10% and 30%). And they require institutional prime and institutional tax-exempt funds to charge a liquidity fee when daily net redemptions exceed 5% of net assets, unless the fund's liquidity costs are de minimis; that requirement had a compliance date twelve months after the effective date. Any non-government fund may also impose a discretionary fee, capped at 2% of the value redeemed, if its board decides that is in the fund's best interest. WAM and WAL stay capped at 60 and 120 days.

So the two regimes now point in different directions on one tool: the EU regulation as published still provides for gates and suspension on constant-NAV funds, while the SEC has removed gates from rule 2a-7. That is the kind of detail a policy written for "money market funds" in general will miss.

What is not verified here: amendments to the EU regulation after its original publication, the UK's own regime, and the rating agencies' criteria for money-market fund ratings. Read the current consolidated text and the fund's prospectus before relying on any threshold above.

## Why treasury reaches for them

Set MMFs against the alternative — leaving large balances sitting in bank deposits — and the case is straightforward:

- **Diversification away from bank concentration.** A big operating balance in one bank is a single point of failure. An MMF spreads the same cash across many high-grade issuers, which is the same instinct behind [counterparty and concentration limits](https://gravam.com/blog/managing-surplus-cash) applied through a single instrument.
- **Same-day or next-day liquidity.** Used well, the cash is still there when the business needs it — which is the entire second priority of corporate cash investment.
- **Professional management and transparency.** Someone whose full-time job is the money markets manages the portfolio, and a rated fund publishes what it holds. You are not stock-picking short-term paper yourself.
- **A rated vehicle.** MMFs are typically highly rated (top money-market ratings such as the AAA-equivalent scales the agencies use), which gives policy a clean, checkable line to write against.

> A money market fund lets you optimise two of yield, safety and liquidity — never all three. Decide which two the cash needs before you decide which fund it goes into.

That triangle is the honest frame. Every MMF is a specific answer to it, and the answer that pays the most is, by construction, giving something up on one of the other two.

## The treasury lens: it lives inside the policy

None of this is a licence to hunt for the best-yielding fund. MMF use belongs _inside_ the [investment policy](https://gravam.com/blog/managing-surplus-cash), not alongside it. The policy should name which funds are permitted, set a rating floor, and cap concentration — both per fund and, looking through the fund, per underlying issuer — so that "diversification" doesn't quietly recreate a concentration you can't see. This is the same governance that runs through [debt and investment management](https://gravam.com/blog/debt-and-investment-management-in-treasury): the instrument changes, the discipline doesn't.

The reason the order is fixed is the reason it is always fixed for operating cash. You are investing money the business needs to run — payroll, suppliers, debt service. So the point of putting it in an MMF is capital preservation and liquidity **first**, and yield **last**, as the bonus you take only after the first two are satisfied. A fund that pays more but can't be redeemed on the day you need it has failed at the only two things that actually mattered.

## The risk reality

Here is the part the fact sheet underplays: "cash-like" is not "cash." A money market fund is an investment. It is a very conservative, highly rated, short-dated investment — but it is not a guaranteed deposit, and it can face stress. Funds have, in the past, come under real pressure when the short-term markets they invest in seized up. The 2008 experience is the reference point, and the regulatory reforms that followed — the SEC's reforms in the US, the Money Market Fund Regulation in the EU — exist precisely because that risk turned out to be real when it had been treated as theoretical. March 2020 made the point again: the SEC's 2023 release cites the outflows of that month as the reason it rewrote the fee-and-gate framework. The thresholds are set out [above](https://gravam.com/blog/money-market-funds-for-corporate-treasury#what-the-rules-actually-say); the point that matters for a treasurer is simpler: the rules keep being revised, which tells you the risk was never zero.

Which leads to the one habit worth building: **read what the fund actually holds.** Government or prime? What's the maturity profile? Who are the underlying issuers, and does the fund's concentration blow through the limits your own policy sets? A fund is not a black box you rate once and forget; it's a portfolio you can look through, and looking through it is the difference between managing the risk and hoping it isn't there. This is where MMFs connect to broader [liquidity risk management](https://gravam.com/blog/liquidity-risk-management): the fund is only as liquid as the paper inside it on the day everyone wants out at once.

## The yield trap in money market funds

On paper, MMFs are the easy button — cash-like, highly rated, liquid, done. In reality, the trap is dependably the same one. A treasurer under pressure to make the cash earn more reaches for the highest-yielding fund on the list, ticks the "AAA-rated" box, and moves on. Then a stress event arrives and the yield reveals its source: it was compensation for credit and liquidity risk that never showed up in calm markets and was never priced when the fund was chosen.

The lesson isn't to avoid MMFs — they're a genuinely good tool, and I've relied on them for a long time. The lesson is to remember what job they're doing. Preservation and liquidity are the mandate; yield is what you're allowed to keep once the mandate is met. Track it like the rest of treasury: the [KPIs that measure treasury performance](https://gravam.com/blog/treasury-kpis-measuring-treasury-performance) should reward safe, liquid, well-diversified cash, not the last few basis points squeezed out of it. Choose the fund that does the job, know what it holds, keep it inside the policy — and an MMF becomes exactly what it should be: a quiet, dependable home for cash, not a bet you didn't know you were making.

***

_See also [managing surplus cash](https://gravam.com/blog/managing-surplus-cash) and [liquidity risk management](https://gravam.com/blog/liquidity-risk-management)._

## Primary sources

EU rules read from Regulation (EU) 2017/1131 as published in the Official Journal (Articles 2, 3, 10, 17, 24, 25, 33, 34, 35 and 47); later amendments and the consolidated text were not re-read, and the UK's post-Brexit regime is not covered. US rules read from the SEC's July 2023 adopting release (33-11211) and its press release. Rating-agency criteria and any individual fund's dealing cut-off times are not verified here — check the prospectus.

- EUR-Lex — Regulation (EU) 2017/1131 of the European Parliament and of the Council of 14 June 2017 on money market funds — accessed 2026-10-04 — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R1131
- SEC — Money Market Fund Reforms; Form PF Reporting Requirements for Large Liquidity Fund Advisers (Release No. 33-11211, final rule) — accessed 2026-10-04 — https://www.sec.gov/files/rules/final/2023/33-11211.pdf
- SEC — Press release 2023-129: SEC Adopts Money Market Fund Reforms and Amendments to Form PF Reporting Requirements for Large Liquidity Fund Advisers (12 July 2023) — accessed 2026-10-04 — https://www.sec.gov/newsroom/press-releases/2023-129

## Questions this article answers

**Q: What are the best money market funds for corporate treasury?**

There is no single best money market fund for corporate treasury, and naming one would be a product recommendation that goes stale as soon as a portfolio or rating changes. Treasuries choose by criteria instead: the fund type and how its NAV behaves (in the EU, public debt CNAV, LVNAV or VNAV under Regulation (EU) 2017/1131; in the US, a stable-price government fund or a floating-NAV institutional prime fund under SEC rule 2a-7), the credit quality of the holdings and the fund's rating, its weighted average maturity and weighted average life (capped at 60 and 120 days for EU short-term funds and US funds), its liquidity terms and dealing cut-off, the fund's size relative to your holding, its currency, and whether it fits the investment policy's counterparty and concentration limits.

**Q: What is a money market fund?**

A money market fund is a pooled investment fund that holds a diversified portfolio of short-dated, high-quality money-market instruments — typically government paper such as Treasury bills, repurchase agreements, commercial paper and certificates of deposit. It aims to preserve capital and offer same-day or next-day liquidity while paying a yield on cash, which makes it a common home for corporate operating and reserve balances. It is not a bank deposit and is not guaranteed.

**Q: What is the difference between a government and a prime money market fund?**

A government (or treasury) money market fund holds government paper and government-backed repurchase agreements, which sits at the lower-risk end of the spectrum. A prime fund can also hold high-grade corporate instruments such as commercial paper and certificates of deposit, which typically offers a little more yield in exchange for a little more credit and liquidity sensitivity. The choice is a trade-off along the yield-versus-safety-versus-liquidity triangle, and which is appropriate depends on the treasury's investment policy.

**Q: Are money market funds safe for corporate cash?**

Money market funds are designed to be low-risk and are typically highly rated, but 'cash-like' is not the same as cash — they are investments, not guaranteed deposits, and they can face stress. The rules written after 2008 — the EU's Regulation (EU) 2017/1131 on money market funds and the SEC's reforms to rule 2a-7, most recently amended in July 2023 — exist precisely because that risk is real if it is underestimated. Used inside a proper investment policy — permitted funds, rating floors, concentration limits — and with attention to what a fund actually holds, they are a well-established tool for preserving and mobilising corporate cash.

---

# Cash Concentration: Sweeping and Zero-Balancing Accounts

Source: https://gravam.com/blog/cash-concentration-sweeping-and-zba
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: How cash concentration physically sweeps balances into one header account via ZBA — and the intercompany loan positions those sweeps quietly create.

**Cash concentration physically moves balances out of many accounts and into one, so cash that would sit idle across subsidiaries is pooled into a single working balance.** This is the physical side of pooling: unlike a [notional pool, where the money never moves](https://gravam.com/blog/physical-vs-notional-cash-pooling), concentration actually transfers funds — and that single fact is what makes it powerful and what makes it complicated. The sweeping mechanics are routine bank plumbing. The intercompany loan positions those sweeps create are where the real work lives, and where I've watched more than one team get caught out.

## What cash concentration actually does

Left alone, a group's cash fragments. Every operating entity keeps its own bank account, and each one carries a balance — a bit here, a buffer there — that individually looks trivial and collectively adds up to a lot of money doing nothing. Concentration fixes that by physically sweeping those balances into a central **header account** (also called a concentration or master account), so the group holds one real, consolidated balance it can put to work: fund entities that are short, invest genuine surplus (in [money market funds](https://gravam.com/blog/money-market-funds-for-corporate-treasury), say), or offset external borrowing instead of paying to borrow while sitting on idle cash elsewhere.

The word that matters is _physically_. The money leaves the subsidiary's account and lands in the header account — that is the whole point, and, as I'll get to, the whole catch.

## Zero-balancing accounts (ZBA)

The workhorse mechanism is the **zero-balancing account**. Each participating account is swept to zero at the end of every day: if it's in surplus, the surplus goes up to the header; if it's in deficit, the header funds it back down. The account both starts and finishes at zero, and by the next morning there is exactly one balance to look at — the header's — instead of dozens.

That's the appeal. When I'm building a [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) on top of a clean ZBA structure, most of the work is already done: the operating accounts zero out, and the position collapses to what's in the header and what's coming in. The concentration structure and the position reinforce each other — the sweep gives you one number to manage, and managing one number is dramatically easier than reconciling forty.

## Target and threshold balancing

Zero isn't always the right target. Some local accounts genuinely need a working float — to clear a payroll run, to cover local direct debits, to keep an entity operating without pinging the header for every euro. For those, you sweep to something other than zero:

- **Target balancing** sweeps the account to a defined target balance rather than to zero, leaving a set amount behind as a working float and moving only what's above or below the target.
- **Threshold balancing** only acts once a trigger is crossed — sweeping the excess above a threshold, and otherwise leaving the account alone — so you're not generating a movement every single day for trivial amounts.

The choice is operational, not ideological. Zero balancing maximises concentration; target and threshold balancing trade a little concentration for local autonomy where an account needs it. Most real structures mix them: zero-balance the accounts that are pure collection points, target-balance the ones that have to keep the lights on.

## The mechanics, precisely: hierarchy, value dating and the entry

Three details decide whether a concentration structure is clean or a reconciliation trap:

- **Sweep hierarchy.** Real pools are multi-level: leaf operating accounts sweep to a regional or per-currency header, and those headers sweep to a single group **master**. The _order_ matters — leaves before headers — so cash cascades up in one pass rather than an account being funded moments before it's swept. Get the hierarchy or sequence wrong and you generate pointless movements (and pointless intercompany entries).
- **Value dating.** A sweep's _value date_ — when the cash is actually available and earns or costs interest — isn't always the booking date. Same-day value keeps the position and interest clean; back- or forward-valued sweeps mean the balance you _see_ and the balance that _earns interest_ diverge, a classic source of an interest figure that won't tie out.
- **Overdraft / deficit funding.** Zero-balancing a deficit means the header funds it — but if the header is itself short, you're into [intraday](https://gravam.com/blog/intraday-liquidity-management) or committed overdraft on the master. Decide that the group's genuine borrowing sits on **one committed line at the master**, not scattered as uncommitted local overdrafts you can't see.

And the entry every sweep books — the part someone has to own:

```text
Subsidiary surplus sweeps UP to the header:
  DR  Header cash account          (cash arrives centrally)
  CR  Intercompany payable to sub  (the group now owes the subsidiary)

Header funds a subsidiary DEFICIT:
  DR  Intercompany receivable from sub
  CR  Header cash account
```

The cash legs are automatic — the bank posts them. The **intercompany legs are what someone has to book, price and reconcile**, and skipping them is exactly the trap the next section is about.

## The intercompany consequence people miss

Here's the part that gets underestimated, every time. **Every sweep between two legal entities is an intercompany loan.** When a subsidiary's surplus sweeps up to a header account owned by another entity, the subsidiary hasn't given that cash away — it has _lent_ it. When the header funds a subsidiary's deficit, the subsidiary has _borrowed_. Run a ZBA structure for a month and you've quietly generated a web of intercompany receivables and payables between the header entity and every participant.

> The sweep is a button the bank presses at end of day. The intercompany loan it creates is a position your finance, tax and legal teams live with for years.

Those positions are not a formality. They need **interest** at an arm's-length rate, they need **documentation** — a real intercompany loan or cash-pool agreement, not a handshake — and they are squarely a **transfer-pricing and tax** matter, since withholding tax, thin-capitalisation limits and interest deductibility all vary by country. This is exactly what auditors and tax authorities look at, because it's where groups get sloppy: the treasury team sets up an elegant sweep, and nobody owns the intercompany accounting until someone asks why there's no interest booked against the drifting balances.

The mechanics are easy. The accounting and legal are where it gets real. If you take one thing from this: design the intercompany framework — pricing, agreements, interest, reporting — _before_ you turn the sweeps on, not after the first audit question.

## Cross-border and multi-currency sweeping

Domestic, single-currency ZBA is routine — banks do it in their sleep, and I'd hesitate to call it a project. Cross-border and multi-currency concentration is a different animal. The moment sweeps cross a currency, you're into **FX** on every movement. The moment they cross a border, you're into **local regulation, capital controls and repatriation rules** that can restrict or tax the flow, or block it outright in some jurisdictions. A structure that's trivial within one country becomes a genuine project — with legal, tax and banking work per jurisdiction — the moment it goes cross-border. Plan it as one.

## Where concentration sits versus an in-house bank

Concentration is the plumbing: it physically moves the cash into one place. It is not, by itself, the governance around that cash. Once the intercompany loans start piling up, many groups formalise the arrangement into [an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) — an internal entity that acts as banker to the group, running the intercompany accounts, current accounts, interest and internal funding on a proper footing. Think of it this way: concentration moves the money; the in-house bank formalises the banking around the money it moved. Concentration usually comes first, and the in-house bank is what you build when the intercompany side outgrows a spreadsheet.

## What teams underestimate

I'll say it plainly, because it's the through-line of everything above: the sweep structure is the easy part. Getting a bank to zero-balance a set of accounts is a configuration exercise. What teams underestimate is everything the sweeps _generate_ — the intercompany loan positions, the interest that has to be calculated and booked, the agreements that have to exist, and the tax and transfer-pricing treatment that has to hold up. That's the part auditors and tax authorities examine, and it's the part that turns a clean liquidity tool into a multi-year headache when it's skipped.

Get the intercompany framework right up front — and get [visibility across all the accounts feeding it](https://gravam.com/blog/how-to-achieve-global-cash-visibility), so you can actually see what's being swept — and concentration becomes exactly what it should be: a quiet mechanism that stops your cash sitting idle and puts one clean balance in front of you every morning.

***

_See also [trapped cash and cash repatriation](https://gravam.com/blog/trapped-cash-and-cash-repatriation) for the balances a sweep can't reach, and [the treasury operating model](https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized) for the choice that decides how far concentration goes._

## Questions this article answers

**Q: What is cash concentration?**

Cash concentration is the physical movement of balances out of many operating accounts into a single header (or concentration) account, so idle cash scattered across subsidiaries is pooled into one real balance the group can fund, invest or offset borrowing with. Because the money actually moves — unlike notional pooling, where it doesn't — every transfer between legal entities creates an intercompany position that has to be tracked and priced.

**Q: What is a zero-balancing account (ZBA)?**

A zero-balancing account is a participating account that is swept to zero every day: any surplus is moved up to the header account and any deficit is funded back down from it, so the local account starts and ends at zero. The result is one real balance to manage at the header, instead of dozens of idle balances sitting across operating accounts. Domestic, single-currency ZBA is routine bank plumbing; cross-border ZBA is a bigger undertaking.

**Q: What is the difference between target balancing and zero balancing?**

Zero balancing sweeps a participating account all the way to zero each day, leaving nothing behind. Target balancing sweeps to a defined target balance instead — for example leaving a set working float in the local account — and threshold balancing only sweeps amounts above a trigger, leaving the account otherwise untouched. Zero balancing maximises concentration; target and threshold balancing leave a working balance where a local account genuinely needs one.

---

# Bank Guarantees and Letters of Credit

Source: https://gravam.com/blog/bank-guarantees-and-letters-of-credit
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Bank guarantees and letters of credit are a bank's promise to pay if a counterparty fails or documents are presented — and both consume credit lines.

**A bank guarantee and a letter of credit are both a bank stepping in with its own promise to pay — and both quietly consume the same credit lines you rely on for [funding](https://gravam.com/blog/corporate-funding-and-credit-facilities).** A letter of credit pays a seller when compliant documents are presented; a guarantee pays a beneficiary only if the party it backs fails to perform. Different triggers, same underlying fact: your bank is lending you its creditworthiness, it charges for it, and it books the exposure against your facilities. Miss that second half and the guarantee book becomes where facility capacity silently leaks.

## The problem they solve

Two parties who don't know each other have to transact — often across borders, different legal systems, no shared history. The seller doesn't want to ship before it's confident of payment; the buyer doesn't want to pay before it's confident of delivery. Each side's assurance is only as good as the other's balance sheet and honesty, neither of which is visible from the far side of a border.

A bank bridges that gap. Both parties may not trust each other, but they can both trust a reputable bank. So one side's bank inserts its own promise into the deal, and the trust problem becomes a banking problem — which is exactly the kind of problem banks are set up to price and carry. That's the whole idea behind both instruments; they just insert the promise at different points.

## Letter of credit: documents, not goods

A letter of credit — a documentary credit — is a payment instrument. The buyer's bank undertakes to pay the seller _when the seller presents documents that comply with the terms set out in the credit_: the invoice, the transport document, the certificates, whatever the credit specifies. Get the documents right and payment is due; the bank checks the paperwork, not the shipment.

That's the principle people trip over. **The bank deals in documents, not in goods.** It is not inspecting the container or verifying that what shipped matches what was ordered — it's examining whether the presentation matches the credit. Compliant documents mean the bank pays, even if a dispute over the goods is brewing; non-compliant documents mean the bank can refuse, even if the goods are perfect. It's abstract on purpose: it lets a bank stand behind a trade it has no way to physically verify. Letters of credit are heavily used in international trade for exactly this reason — they turn "do I trust this counterparty across an ocean?" into "can they produce the right documents?"

## Bank guarantee and standby LC: the safety net

A bank guarantee runs the other way. Here the bank pays the beneficiary _only if the party it's backing fails_ — a demand or a declaration of default triggers it. It's not the intended payment route; it's the backstop that everyone hopes stays untouched. A performance guarantee assures a buyer the supplier will deliver as contracted. An advance-payment guarantee protects a buyer who paid up front, so the money comes back if nothing is delivered. A bid bond assures a tender's issuer the bidder will honour its bid. In every case the guarantee pays out only when the primary obligation isn't met.

A standby letter of credit does the same job dressed in documentary-credit clothing: it looks like an LC and is presented against documents, but its purpose is a guarantee's — it pays only if the underlying party defaults. If a documentary LC is the road payment is expected to travel, a standby or a guarantee is the airbag: valuable precisely because it usually never deploys.

There are internationally recognised rule frameworks governing both families — established practice rules for documentary credits, and separate ones for demand guarantees — that standardise how these instruments are read and honoured across jurisdictions. You don't need the article numbers to work with treasury; you need to know the rules exist, that which set applies is a choice made when the instrument is drafted, and that the wording is where the risk lives.

## The treasury angle people forget

Here's the part that gets lost between the trade desk and the treasury team: **every guarantee and every LC consumes your bank credit lines.** When a bank issues one, it's taking on a contingent liability on your behalf — a promise it may have to fund — and it books that against your [facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities), the same facilities you're counting as liquidity headroom. It charges fees for the privilege, running for as long as the instrument stays open.

> A guarantee you issued and forgot is a live claim on your credit lines. It doesn't show up as drawn debt, so nobody misses the cash — but the capacity is gone, quietly, until someone cancels it.

So a portfolio of open guarantees is not free. It ties up facility capacity that could have funded a drawdown, a working-capital swing, an acquisition. I have walked into treasuries that could not explain why their available lines were thinner than their debt suggested — and the answer was always the same: a guarantee book nobody had reconciled in years. This is why the [bank relationship](https://gravam.com/blog/bank-relationship-management) conversation has to include contingent lines, not just cash facilities. Guarantees are consumption of the same scarce resource that funds [working capital](https://gravam.com/blog/working-capital-and-cash).

## Governance, and the trap

The trap is that guarantees outlive the contracts they backed. A performance guarantee for a project completed two years ago should have been released the day the project signed off — but releases require the beneficiary to act, or someone on your side to chase it, and in practice nobody does. So it keeps consuming lines and accruing fees, year after year, backing an obligation that no longer exists.

The other edge is the wording. An on-demand guarantee, by design, pays when the beneficiary demands it — and it can be called on a technicality, or when a project sours and a counterparty reaches for whatever cash it can. The line between "pays on genuine default" and "pays on any demand" is written into the text, which is why the drafting is a treasury matter and not a formality to rubber-stamp.

Docs-vs-reality: the manuals describe these as clean, self-liquidating instruments. In practice the guarantee book is where capacity leaks — old guarantees nobody cancelled, and a "standby" that gets called the moment a project goes wrong. Treat it as a live portfolio: every open instrument owned, dated, tied to a live obligation, with expiry discipline enforced. Track it the way you'd track drawn debt, because in the ways that matter — [liquidity risk](https://gravam.com/blog/liquidity-risk-management) and facility capacity — it behaves like drawn debt. Issue and forget is how a treasury ends up funding trust it stopped needing years ago.

***

_See also [corporate funding and credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities) and [liquidity risk management](https://gravam.com/blog/liquidity-risk-management)._

## Questions this article answers

**Q: What is a bank guarantee?**

A bank guarantee is a promise by a bank to pay a beneficiary if the party it's backing fails to perform or pay under a contract. It's a safety net: it pays out only when the primary party defaults, so it lets a counterparty deal with someone they don't fully trust, backed by a bank that they do. Common forms include performance guarantees, advance-payment guarantees and bid bonds. A standby letter of credit serves the same purpose in a documentary-credit form.

**Q: What is the difference between a letter of credit and a bank guarantee?**

A letter of credit is a payment mechanism: the bank pays the seller when the seller presents documents that comply with the credit's terms — it's the intended route by which the seller gets paid. A bank guarantee is a safety net: the bank pays only if the primary party fails to perform or pay. Put simply, a documentary letter of credit is expected to be used in the normal course of a trade, while a guarantee is expected never to be called if everyone does what they promised.

**Q: Do guarantees use up a company's credit line?**

Yes. Every guarantee and letter of credit a bank issues on your behalf is a contingent liability the bank carries, so it consumes your bank credit lines and carries fees for as long as it's open. A portfolio of open guarantees ties up facility capacity that could otherwise fund something else, which is why treasury has to track and actively manage the guarantee book — not issue and forget.

---

# Debt and Investment Management in Treasury

Source: https://gravam.com/blog/debt-and-investment-management-in-treasury
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Debt and investment management records and tracks a company's instruments through their life — interest, schedules, rollovers and covenants.

**Debt and investment management is the treasury discipline of recording, tracking and managing a company's debt and investment instruments through their life — loans, facilities, intercompany funding, deposits and [short-term investments](https://gravam.com/blog/money-market-funds-for-corporate-treasury), with all their principal, interest, schedules, rollovers and covenants.** It's important to be precise about what this is: it's _not_ deciding whether to [raise funding](https://gravam.com/blog/corporate-funding-and-credit-facilities) or where to [invest surplus cash](https://gravam.com/blog/managing-surplus-cash) — those are strategy. Debt and investment management is _running the book_ once those decisions are made, so that nothing is missed, mispriced or breached. It's one of the [six core jobs of a TMS](https://gravam.com/blog/what-is-a-treasury-management-system), and the one where quiet operational slips turn into loud financial ones.

## What it is

Once a company borrows, lends internally, or invests, each of those becomes an _instrument_ with a life: a principal, an interest arrangement, a schedule of payments, a maturity, and often conditions attached. Debt and investment management is the discipline of tracking every one of those accurately from inception to close — so the right interest is paid, the right cash moves on the right day, maturities are handled, and conditions are met.

## What it covers

- **Loans and [credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities)** — external borrowing, drawn and undrawn.
- **Intercompany funding** — loans between group entities, often via the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank).
- **Deposits and short-term investments** — where [surplus cash](https://gravam.com/blog/managing-surplus-cash) is placed.
- Each with its principal, interest terms, schedule and maturity.

## The instrument lifecycle

Every instrument runs a lifecycle the discipline has to manage:

1. **Capture** — record the deal accurately (terms, rate, schedule, counterparty).
2. **Service** — calculate and settle interest and principal on schedule.
3. **Roll or mature** — handle rollovers, extensions and maturities _before_ they arrive, not after.
4. **Close** — settle and retire the instrument cleanly.

Miss a step — a rollover not actioned, an interest calc wrong — and you get a failed payment, a funding gap, or a dispute.

## Covenant monitoring

> A covenant breach can make debt repayable on demand even when every payment is current. It's the risk that doesn't show up in the cash flow — until it shows up as the whole loan falling due.

Debt often carries **covenants** — conditions the borrower must meet, frequently financial ratios (leverage, interest cover) or reporting obligations. Breaching one can be severe: it may trigger default or make the debt repayable on demand, regardless of whether payments are current. So covenants must be **tracked and tested proactively** — projected forward, watched as headroom narrows, and never discovered breached after the fact. Covenant monitoring is core to debt management precisely because the downside is so asymmetric.

## Intercompany loans

In a centralized group, much of the "debt" is _internal_ — [intercompany loans](https://gravam.com/blog/what-is-an-in-house-bank) run through the in-house bank. These need the same rigour as external debt: recorded, interest-bearing at proper rates, scheduled and tracked. Untracked intercompany loans are a common mess — interest not charged correctly, balances that don't reconcile between entities, tax and transfer-pricing exposure. The internal book deserves as much discipline as the external one.

## It feeds cash and accounting

Every instrument generates **cash flows** — interest and principal — that flow into the [cash position and forecast](https://gravam.com/blog/13-week-cash-flow-forecast); and **accounting entries** that flow to the ledger. So debt and investment management isn't an island: it's a source of much of what the [forecast](https://gravam.com/blog/13-week-cash-flow-forecast) and the [accounting](https://gravam.com/blog/hedge-accounting-explained) depend on. Get an instrument's schedule wrong and the forecast is wrong too.

## Why a system matters

This is detail-heavy, date-sensitive work where errors are expensive — which is exactly why it's a core TMS job rather than a spreadsheet one. A [system](https://gravam.com/blog/what-is-a-treasury-management-system) captures each instrument, calculates interest and schedules automatically, alerts on maturities and covenant tests, enforces [controls](https://gravam.com/blog/segregation-of-duties-in-treasury-systems), and keeps one accurate portfolio view (in SAP TRM, [Portfolio Analyzer](https://gravam.com/blog/sap-portfolio-analyzer) adds returns against benchmarks on top of it). A spreadsheet has none of that — no alerts, no source of truth — so the missed rollover and the unnoticed covenant slip through.

## Missed maturities, covenants and other gaps

- **Missed rollovers and maturities.** No alerting, so a maturity arrives unhandled — a failed payment or an accidental funding gap.
- **Covenant breaches unnoticed.** Covenants not tracked forward, so a breach is discovered after it's happened.
- **Manual interest errors.** Interest calculated by hand, wrong, on instruments large enough for it to matter.
- **Untracked intercompany loans.** The internal book left to drift, with wrong interest and unreconciled balances.
- **No portfolio view.** No single accurate picture of all debt and investments, so exposure and maturities can't be seen whole.

Capture every instrument accurately, service it on schedule, monitor covenants proactively, hold the intercompany book to the same standard, and keep one portfolio view — and debt and investment management becomes the reliable running of the book that funding and investment _strategy_ both depend on. It's unglamorous, detail-bound, and exactly the kind of work that's cheap to do in a system and expensive to get wrong in a spreadsheet.

***

_See also [corporate funding and credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities) and [managing surplus cash](https://gravam.com/blog/managing-surplus-cash)._

## Questions this article answers

**Q: What is debt and investment management in treasury?**

Debt and investment management is the treasury discipline of recording, tracking and managing the company's debt and investment instruments through their whole life — loans, credit facilities, intercompany funding, deposits and short-term investments. It covers capturing each deal, managing its interest and repayment schedule, handling rollovers and maturities, monitoring loan covenants, and keeping a single accurate view of the whole portfolio. It's distinct from deciding to fund or invest; it's the operational discipline of running the book correctly once those decisions are made.

**Q: What are loan covenants and why do they matter?**

Loan covenants are conditions attached to debt that the borrower must comply with — often financial ratios (like leverage or interest cover) or reporting obligations. They matter because breaching a covenant can have serious consequences, potentially making the debt repayable on demand or triggering default, even if payments are current. So covenants must be tracked proactively and tested ahead of time, not discovered to be breached after the fact. Covenant monitoring is a core part of debt management precisely because the downside of missing one is so severe.

**Q: Why manage debt and investments in a system rather than spreadsheets?**

Because the details are numerous, date-sensitive and costly to get wrong: a missed rollover, an unnoticed approaching covenant breach, a mis-calculated interest payment, or an intercompany loan no one tracked all create real financial and control problems. A spreadsheet has no alerts, no controls and no single source of truth, so these slip through. A treasury system captures each instrument, calculates interest and schedules automatically, flags maturities and covenant tests, and keeps one accurate portfolio view — which is exactly why debt and investment management is one of the core jobs of a TMS.

---

# Bank Relationship Management for Corporate Treasury

Source: https://gravam.com/blog/bank-relationship-management
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: How a company deliberately manages which banks it uses, for what, and the value exchanged both ways — because the bank relationship is two-way, not one-sided.

**Bank relationship management is how a company deliberately manages its relationships with its banks — which banks it uses, for what, how much business each one gets, and the value exchanged in both directions.** The core idea most companies underweight: the relationship is **two-way**. Banks provide credit, cash management, payments and [services](https://gravam.com/blog/bank-guarantees-and-letters-of-credit); the company provides fees, deposits and ancillary business in return. A treasury that treats its banks purely as vendors — taking credit while giving little else — discovers the hard way that credit and good service flow to the companies that give the bank a fair share of business back. Managing that reciprocity deliberately, rather than by accident, is what keeps banking partners reliable and pricing fair.

## What it is

Every company depends on banks for things it can't do without — credit, moving money, holding cash, FX, and more. Bank relationship management is the deliberate stewardship of those dependencies: choosing the right banks, giving each a sensible role, allocating business thoughtfully, and maintaining the relationships over time. Done well it's invisible; done badly it surfaces as a credit line not renewed, or service that quietly deteriorates.

## The two-way value exchange

> Banks remember who gave them business when they wanted it. A company that takes a bank's credit but routes its fees and deposits elsewhere is quietly telling the bank where it stands — usually right before it needs the credit renewed.

The relationship runs both ways:

- **The bank provides** — credit (often the anchor, at thin margins), cash management, payments, FX, and other services.
- **The company provides** — fees, deposits, FX and [other revenue-generating business](https://gravam.com/blog/supply-chain-finance-and-dynamic-discounting): the bank's **share of wallet**.

Credit is frequently offered _in expectation_ of getting the ancillary, profitable business too. A company that takes the credit but gives the profitable business to others is spending relationship capital it will want back later.

## Choosing the bank group

How many banks? Enough for **diversification, credit capacity and coverage** — but few enough that each relationship is **meaningful and manageable**. Too few concentrates [counterparty risk](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) and caps capacity; too many fragments the business so thinly that no bank sees enough value to prioritize you, while [account sprawl](https://gravam.com/blog/bank-account-rationalization) and administration balloon. The right number is deliberate, not accidental — a managed group sized to the business.

## Allocating business

The heart of relationship management is _allocating business to match the relationships_. Banks that provide credit reasonably expect a share of the ancillary business; rewarding your genuine relationship banks with fees and flow keeps them engaged and willing when you need capacity or a favour. Allocating business by inertia — or purely to whoever's cheapest today — erodes the relationships you'll depend on in a crunch.

## The tools

Relationship management is supported by concrete tools: [bank fee analysis](https://gravam.com/blog/bank-fee-analysis) (understanding what each bank costs and earns), periodic relationship reviews (is the exchange fair both ways?), [eBAM](https://gravam.com/blog/electronic-bank-account-management-ebam) and account governance (keeping the estate clean), and occasional RFPs to test the market. The data these produce is what turns relationship management from impression into evidence.

## The tension with counterparty risk

There's a real tension worth naming: relationships pull toward _concentrating_ business with a few well-treated banks, while [counterparty risk](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) pulls toward _diversifying_ so no single bank's failure is catastrophic. Good relationship management holds both — deep enough relationships to be valued, spread enough that the group survives any one bank. It's a balance, not a contradiction.

## How bank relationships erode

- **Too many or too few banks.** Fragmented so thinly that no relationship matters, or concentrated so tightly that risk and capacity are strained.
- **No reciprocity.** Taking credit while giving business elsewhere — and then being surprised when the credit gets harder to renew.
- **Reactive, unmanaged relationships.** Never deliberately managing the group, so it drifts and relationships weaken by neglect.
- **Ignoring the data.** Not using [fee](https://gravam.com/blog/bank-fee-analysis) and business-allocation data to understand and steer the relationships.

Choose a deliberate bank group, allocate business to match the credit and value each bank provides, use the data to keep the exchange fair, and hold the balance against [counterparty](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) concentration — and bank relationships become a reliable asset rather than something that fails you exactly when you need it. Banks are among a company's most important suppliers; managing them deliberately is treasury's job, and a quietly consequential one.

***

_See also [bank fee analysis](https://gravam.com/blog/bank-fee-analysis) and [bank account rationalization](https://gravam.com/blog/bank-account-rationalization)._

## Questions this article answers

**Q: What is bank relationship management?**

Bank relationship management is how a company deliberately manages its relationships with its banks — which banks it uses, for which products and regions, how much business each one gets, and the value exchanged in both directions. Banks provide credit, cash management, payments and other services; the company provides fees, deposits and ancillary business. Managing this deliberately rather than by accident ensures the company has reliable banking partners, fair pricing, and access to credit and services when it needs them.

**Q: Why is the bank relationship two-way?**

Because banks and companies each provide value to the other, and each expects a return. Banks extend credit (often at thin margins) and provide cash-management and other services; in return they expect a fair share of the company's overall business — fees, deposits, FX, and other revenue-generating activity, often called 'share of wallet.' A company that takes credit from a bank but gives it little other business shouldn't be surprised when that credit becomes harder to renew. Managing the relationship means being deliberate about that reciprocity.

**Q: How many banks should a company have?**

Enough to provide diversification, sufficient credit capacity and the geographic and product coverage the business needs — but few enough that each relationship is meaningful and manageable. Too few banks concentrates risk and capacity; too many fragments the business so thinly that no bank sees enough value to prioritize the relationship, and administration and account sprawl balloon. The right number depends on the company's size, geography and needs, but the principle is a deliberate, managed group rather than an accidental collection.

---

# Working Capital and Cash: The Cash Conversion Cycle

Source: https://gravam.com/blog/working-capital-and-cash
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Working capital — cash tied up in receivables and inventory, less payables — is a big driver of a company's cash. The cash conversion cycle (DSO, DIO, DPO).

**Working capital — the cash tied up in receivables and inventory, less payables — is one of the biggest drivers of a company's cash, and managing it can free or trap large amounts.** Every pound sitting in an unpaid customer invoice or a warehouse of inventory is cash the business has locked up; every pound of [supplier credit](https://gravam.com/blog/supply-chain-finance-and-dynamic-discounting) is cash it's holding onto. Treasury cares because working capital swings _directly_ drive the [cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) and [forecast](https://gravam.com/blog/13-week-cash-flow-forecast) — and because freeing working capital is a source of _internal funding that costs no interest_. A company can generate serious cash just by managing working capital better, before it borrows a penny.

## What it is, in cash terms

Forget the balance-sheet definition for a moment and think in cash: working capital is the cash _stuck in the machinery_ of running the business. Money customers owe you (not yet cash), money invested in inventory (not yet sold), minus money you owe suppliers (cash you're still holding). When that stuck amount grows, it _absorbs_ cash; when it shrinks, it _releases_ cash.

## The cash conversion cycle

The standard measure is the **cash conversion cycle (CCC)** — how long cash is tied up before it comes back:

> **CCC = DSO + DIO − DPO**
> (Days Sales Outstanding + Days Inventory Outstanding − Days Payables Outstanding)

- **DSO** — how long customers take to pay you.
- **DIO** — how long inventory sits before it's sold.
- **DPO** — how long you take to pay suppliers.

A _shorter_ cycle ties cash up for less time — so less cash is locked in working capital. Shorten it and you release cash; let it drift longer and you absorb it.

## The three levers

Each component is a lever on cash:

| Lever | To free cash… | Owned by |
| --- | --- | --- |
| **Receivables (DSO)** | Collect faster | Sales / credit control |
| **Inventory (DIO)** | Hold less | Operations / supply chain |
| **Payables (DPO)** | Pay slower | Procurement |

Note the last column: the levers mostly sit _outside_ treasury. Which is exactly why treasury has to _engage_ on working capital rather than just observe it.

## Why treasury cares

> Working capital is the cheapest funding a company has — cash it already owns, locked in its own operations. Freeing it costs no interest and needs no bank. Ignoring it means borrowing money you were sitting on all along.

Two reasons treasury can't ignore working capital. First, it's a huge, _interest-free_ source of [funding](https://gravam.com/blog/corporate-funding-and-credit-facilities): the cash released by cutting the conversion cycle is cash you don't have to raise. Second, working capital movements _drive the cash position and forecast_ — a big receivables build or an inventory season swings cash hard, and treasury has to anticipate those swings to manage liquidity.

## The tension in DPO

One honest caution: stretching **payables (DPO)** frees your cash, but it does so by holding onto _suppliers'_ cash — pay too slowly and you damage supplier relationships and their liquidity, sometimes at real cost to your own supply chain. Working-capital optimization has an ethical and commercial limit; the goal is _efficient_ working capital, not squeezing suppliers to paper over your own cash management. (This tension is part of why **supply chain finance** exists — arrangements that let suppliers get paid early while the buyer keeps longer terms, easing both sides.)

## Working capital mistakes that trap cash

- **Ignoring working capital as a cash source.** Borrowing externally while large cash sits locked in receivables and inventory.
- **Gaming DPO at suppliers' expense.** Freeing cash by paying suppliers punishingly late, damaging the supply chain.
- **Not forecasting working-capital swings.** Missing the big seasonal or growth-driven cash movements working capital causes, so liquidity is managed blind.
- **Treasury staying passive.** Treating working capital as "someone else's function" when its cash impact is treasury's problem.

Understand the cash conversion cycle, engage on the three levers even though they sit in other functions, respect the supplier tension in DPO, and forecast the swings — and working capital becomes what it should be: the first, cheapest source of cash a company reaches for. It's the [liquidity](https://gravam.com/blog/liquidity-risk-management) hiding inside the business's own operations.

***

_See also [corporate funding and credit facilities](https://gravam.com/blog/corporate-funding-and-credit-facilities) and [liquidity risk management](https://gravam.com/blog/liquidity-risk-management)._

## Questions this article answers

**Q: What is working capital in cash terms?**

Working capital is the cash tied up in running the business day to day — chiefly money owed by customers (receivables) and money invested in inventory, less money owed to suppliers (payables). In cash terms it matters because changes in working capital directly move the cash position: when receivables or inventory grow, cash is absorbed; when payables grow or receivables shrink, cash is released. Managing working capital well can free up large amounts of cash without any external funding.

**Q: What is the cash conversion cycle?**

The cash conversion cycle (CCC) is the time it takes for cash to flow through the business and come back — roughly, days sales outstanding (how long customers take to pay) plus days inventory outstanding (how long inventory is held) minus days payables outstanding (how long you take to pay suppliers). A shorter cycle means cash is tied up for less time, so less cash is locked in working capital. Shortening the cash conversion cycle releases cash; lengthening it absorbs cash.

**Q: Why does treasury care about working capital?**

Because working capital is one of the biggest drivers of a company's cash, and freeing it is a source of internal funding that costs nothing in interest. A business can generate significant cash simply by collecting receivables faster, holding less inventory, or paying suppliers on better terms — cash it would otherwise have to borrow. Working capital swings also directly drive the cash position and forecast, so treasury needs to understand and anticipate them, even though the levers are often owned by other functions.

---

# Corporate Funding and Credit Facilities

Source: https://gravam.com/blog/corporate-funding-and-credit-facilities
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Corporate funding secures cash beyond operations — facilities, commercial paper, short-term debt — and the committed-vs-uncommitted distinction.

**Corporate funding is how a company secures the cash it needs beyond what operations generate — through credit facilities, commercial paper and short-term debt.** It's the _other side_ of [liquidity management](https://gravam.com/blog/liquidity-risk-management): forecasting tells you _when_ you'll be short, and funding is how you make sure the cash is actually there to cover it. The single most important idea runs through all of it — the difference between **committed** funding you can rely on and **uncommitted** funding that can vanish when you need it most. Get that distinction right and build reliable headroom, and a cash gap is a non-event; get it wrong and the same gap becomes a crisis.

## What it is, and why it matters

No company funds itself purely from operating cash flow at every moment — timing gaps, growth, seasonality and shocks all create needs for external funding. Treasury's job is to have that funding _in place and reliable_ before it's needed. Because when a [liquidity](https://gravam.com/blog/liquidity-risk-management) gap appears, the funding either exists and it's routine, or it doesn't and it's an emergency. Funding is what turns a forecast shortfall into a shrug.

## Short-term funding tools

The common instruments for short-term liquidity:

- **Revolving credit facility (RCF)** — a committed bank facility you can draw, repay and redraw as needed. The workhorse of corporate liquidity.
- **Commercial paper** — short-term unsecured debt issued to investors; often the cheapest short-term funding, but market-dependent.
- **Overdrafts and bank lines** — flexible short-term bank borrowing, often uncommitted; the same lines also back [guarantees and letters of credit](https://gravam.com/blog/bank-guarantees-and-letters-of-credit).
- **Term loans** — for longer or larger needs.

## The distinction that matters: committed vs uncommitted

> An uncommitted facility is a promise that lasts exactly as long as the bank feels like keeping it. In a crisis — the one time you need it — that's precisely when it isn't there. Only committed, undrawn facilities are real liquidity.

A **committed** facility obliges the bank to lend (subject to conditions) for the agreed term; you pay a commitment fee for that reliability. An **uncommitted** one is cheaper but discretionary — the bank can decline or pull it. For liquidity purposes, only committed undrawn facilities count as dependable [headroom](https://gravam.com/blog/liquidity-risk-management). Building a liquidity buffer on uncommitted lines is building it on sand.

## The funding mix and maturity

Good funding is _structured_, not accidental. Two principles:

- **Match maturities sensibly.** Don't fund long-term needs entirely with short-term debt that has to be constantly rolled — that's refinancing risk, and every rollover is something [debt and investment management](https://gravam.com/blog/debt-and-investment-management-in-treasury) has to track. Broadly align funding tenor to the need.
- **Layer it.** Cheap market funding (commercial paper) for routine needs, with committed bank facilities as the _backstop_ behind it — so if the market closes, the facility covers you.

## Diversify the sources

Depending on a single lender, market or instrument is itself a risk: if that source closes, you're stranded. Diversified funding — multiple banks, multiple instruments, staggered maturities — means no single source's withdrawal is fatal. It's the funding-side echo of [counterparty](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) diversification: don't let any one relationship be a single point of failure.

## Headroom is the point

The goal of all this is **headroom** — committed, available funding above the expected need, so surprises are absorbed rather than escalated. Headroom is measured as committed undrawn facilities plus usable cash, against the obligations and stresses ahead. A company with ample committed headroom can weather a late receipt or a market shock; one running with none turns every surprise into a scramble. This is exactly the buffer [liquidity risk management](https://gravam.com/blog/liquidity-risk-management) depends on.

## How funding plans fail under stress

- **Relying on uncommitted funding.** Counting discretionary lines as liquidity, then finding them gone in a stress.
- **Refinancing walls.** A cluster of maturities all falling due at once, into a possibly-worse market — a self-inflicted cliff.
- **Funding concentration.** All funding from one bank or market, so its withdrawal is catastrophic.
- **No backstop behind market funding.** Relying on commercial paper with no committed facility behind it, so a market freeze leaves no cover.
- **No headroom.** Running with funding sized exactly to the expected need, leaving nothing for the surprise.

Secure committed facilities for reliable headroom, layer cheaper market funding on top with the facilities as backstop, diversify sources, and stagger maturities — and funding becomes the quiet backstop that makes liquidity gaps routine. It's the supply side of the cash equation: [forecasting](https://gravam.com/blog/13-week-cash-flow-forecast) shows the need, and funding is how you're always ready to meet it.

***

_See also [liquidity risk management](https://gravam.com/blog/liquidity-risk-management) and [the 13-week cash flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast)._

## Questions this article answers

**Q: What is corporate funding?**

Corporate funding is how a company secures the cash it needs beyond what its operations generate — through bank credit facilities, short-term instruments like commercial paper, overdrafts, and longer-term debt. For treasury's day-to-day liquidity, the key tools are committed credit facilities (such as a revolving credit facility), commercial paper programmes, and bank lines. Funding is the other side of liquidity management: forecasting tells you when you'll be short, and funding is how you make sure the cash is there to cover it.

**Q: What is the difference between committed and uncommitted facilities?**

A committed facility is one the bank is contractually obliged to make available (subject to conditions) for the agreed period, so you can rely on drawing it — you typically pay a commitment fee for that certainty. An uncommitted facility is one the bank can decline to provide or withdraw at its discretion, so it's cheaper but can disappear exactly when you need it most. The distinction is critical for liquidity: only committed, undrawn facilities count as genuine liquidity headroom you can depend on.

**Q: What is commercial paper?**

Commercial paper is short-term, unsecured debt that large, creditworthy companies issue to investors to fund short-term needs, typically maturing within a few months. It's usually a cheaper source of short-term funding than drawing a bank facility, but it's market-dependent — in stressed markets the ability to issue can dry up, which is why companies that rely on commercial paper normally hold committed bank facilities as a backstop behind it.

---

# Treasury Operating Model: Centralized vs Decentralized

Source: https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: Centralized, decentralized or hybrid — how treasury is organized across a group, the trade-offs, and why the trend runs toward centralization.

**A treasury operating model is how the function is organized across a group — centralized (one central treasury runs everything), decentralized (each entity runs its own), or hybrid (central policy with regional execution).** The choice is one of the most consequential a treasury makes, because it drives control, efficiency, cost, and how well the group's cash and risk are managed as a whole. The clear industry trend is toward **centralization**, usually in a hybrid form — because concentrating treasury delivers visibility, control and scale that a scattered model simply can't, and because it's what makes the powerful [centralization structures](https://gravam.com/blog/what-is-an-in-house-bank) possible at all.

## The three models

- **Centralized** — a single central treasury manages the group's cash, funding and risk.
- **Decentralized** — each entity or region runs its own treasury independently.
- **Hybrid** — a central treasury sets policy and runs key activities, while regional treasury centres handle others.

Real organizations sit on a spectrum between these, and "hybrid" is where most large groups actually land.

## Centralized: control and scale

A central treasury runs treasury activity for the whole group. The benefits are substantial: **group-wide visibility** of cash, **strong and consistent control**, **economies of scale** (one team, one set of systems, better bank terms from concentrated volume), and the ability to **optimize across the whole group** rather than entity by entity. The trade-off is _distance_ — a central team is further from local operations, relationships and knowledge, which has to be managed deliberately.

## Decentralized: local but fragmented

Each entity manages its own treasury. This is responsive to local needs and relationships, but the costs are heavy: cash is **fragmented** across entities (idle here, borrowed there), there are **no economies of scale**, **control is weak and inconsistent**, and **group-wide visibility and risk management** are very hard. What feels like local empowerment usually adds up to a group that can't see or use its own cash.

> Decentralized treasury optimizes each entity and pessimizes the group: every unit looks fine locally while, across the whole, cash sits idle in one place and is expensively borrowed in another.

## Hybrid: the common answer

Most large groups converge on a hybrid: a **central treasury** owns policy, risk and the big decisions, while **regional treasury centres** (often aligned to time zones or business regions) handle execution closer to local operations. This keeps central control and visibility while retaining enough local presence to stay responsive — capturing most of centralization's benefits without all of its distance.

|  | Centralized | Decentralized | Hybrid |
| --- | --- | --- | --- |
| **Cash visibility** | Group-wide | Fragmented | Group-wide, central |
| **Control** | Strong, consistent | Weak, inconsistent | Central policy, consistent |
| **Economies of scale** | Yes — one team, systems, better terms | None | Mostly retained |
| **Local responsiveness** | Distant from operations | High | Regional centres stay close |
| **Enables pooling / in-house bank** | Yes | No | Yes |
| **Best fit** | Groups seeking control & scale | Rarely chosen deliberately | Where most large groups land |

## Why centralization is the trend

The direction of travel is toward more central models, because the benefits compound: better visibility feeds better decisions; scale cuts cost; consistent control reduces risk — gains you can track through [treasury KPIs](https://gravam.com/blog/treasury-kpis-measuring-treasury-performance). Crucially, centralization is what _enables_ the structures that deliver the biggest cash and efficiency gains — [cash pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling), [in-house banking](https://gravam.com/blog/what-is-an-in-house-bank), [payment factories](https://gravam.com/blog/what-is-a-payment-factory) and [netting](https://gravam.com/blog/intercompany-netting) all need a central function to run them. You can't pool cash you've organizationally scattered.

## Who owns what: the decision-rights split

"Hybrid" only works if the central-vs-regional split is written down, not assumed — otherwise activities fall between the two or get done twice. This is the operating-model canvas at the heart of it: name, per activity, who _decides_ and who _executes_.

| Activity | Central treasury owns | Regional / local does |
| --- | --- | --- |
| **Policy & risk appetite** | Sets the policy, limits and appetite | Applies it; flags exceptions |
| **Funding & debt** | Group funding, facilities, debt mix | Surfaces local funding needs |
| **FX & hedging** | Strategy and the dealing itself | Provides the exposures to hedge |
| **Cash positioning & pooling** | Owns the group position and pools | Feeds local balances and forecasts |
| **Payments (factory / POBO)** | Runs the factory, controls, formats | Submits payment requests |
| **Bank relationships** | Strategic/global banks, RFPs | Manages local banks _within_ policy |
| **Systems (TMS)** | Owns the platform and configuration | Uses it; owns local data quality |

The pattern: **central owns the decision, local owns the input and the local execution**. Where a row's ownership is genuinely unclear, that's where a hybrid model leaks — decide it explicitly, and revisit it as the group centralizes further.

## The enablers

A centralized model isn't just an org chart change — it needs the machinery to support it: the [systems](https://gravam.com/blog/what-is-a-treasury-management-system) and [connectivity](https://gravam.com/blog/how-to-achieve-global-cash-visibility) to see and move group cash, and the [centralization structures](https://gravam.com/blog/what-is-an-in-house-bank) to concentrate it. The operating model is the _organizational_ choice; pooling, in-house banking and payment factories are the _financial_ structures that make it real. They go together — centralizing the org without the structures (or vice versa) captures only half the value.

## Centralization pitfalls in treasury operating models

- **Centralizing without buy-in.** Imposing a central model on resistant local units without managing the [organizational change](https://gravam.com/blog/change-management-for-finance-system-rollouts), so it's undermined in practice.
- **Decentralized by default.** Never choosing a model, so treasury stays fragmented by inertia while cash sits idle across the group.
- **Hybrid with unclear boundaries.** Central and regional roles undefined, so things fall between them or get done twice.
- **Underestimating the change.** Treating centralization as a structural tweak rather than a significant operating-model and cultural shift.

Choose the operating model deliberately — and for most groups that means centralizing, at least in hybrid form — then back it with the systems and structures that make central treasury actually work. Get the model right and everything downstream, from [visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility) to [pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling), gets easier; leave it to inertia and the group quietly pays for cash it already has. And whatever the model, the day-to-day work is the exceptions — designing the [treasury exception management](https://gravam.com/blog/treasury-exception-management) queue is how a team stays on top of them instead of firefighting.

***

_See also [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) and [physical vs notional pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling)._

## Questions this article answers

**Q: What is a treasury operating model?**

A treasury operating model is how the treasury function is organized across a group — who does treasury work, where, and with what authority. The three broad models are centralized (a single central treasury runs treasury activity for the whole group), decentralized (each entity or region runs its own treasury), and hybrid (a central treasury sets policy and does some activities while regional centres handle others). The choice shapes control, efficiency, cost and how well cash and risk are managed across the group.

**Q: What is the difference between centralized and decentralized treasury?**

In a centralized treasury, one central function manages the group's cash, funding and risk, giving strong control, visibility and economies of scale, but sitting further from local knowledge. In a decentralized treasury, each entity or region manages its own, which is responsive to local needs but fragments cash and control, prevents economies of scale, and makes group-wide visibility and risk management hard. Most large groups trend toward centralization, often in a hybrid form, because the control and efficiency benefits are substantial.

**Q: Why do companies centralize treasury?**

Because centralization delivers better visibility of the group's cash, stronger and more consistent control, economies of scale (one team, one set of systems, better bank terms), and the ability to optimize cash and risk across the whole group rather than entity by entity. Centralization is also what enables structures like cash pooling, in-house banking and payment factories, which concentrate cash and payments and only work with a central function to run them. The main trade-off is distance from local operations, usually managed with a hybrid model.

---

# Treasury KPIs: How to Measure and Monitor Performance

Source: https://gravam.com/blog/treasury-kpis-measuring-treasury-performance
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: Treasury KPIs measure liquidity, efficiency, risk and cost. How to define them, and how treasury KPI monitoring works: source, cadence, threshold, owner.

**Treasury KPIs are the measures a treasury uses to track how well it's doing its job — across liquidity, efficiency, risk and cost. Treasury KPI monitoring is the routine around them: each measure has a data source, a cadence, a threshold and an owner who acts when it moves.** Good ones make treasury performance _visible_, and what's visible can be managed and improved; the trap, as with all metrics, is measuring what's _easy_ rather than what _matters_. A treasury with no KPIs is flying on feel; one with fifty is drowning in a dashboard nobody acts on. The skill is a handful of meaningful, actionable measures tied to what the function is actually trying to achieve. (This spans the whole treasury remit — [cash](https://gravam.com/topics/cash-and-liquidity-management), [risk](https://gravam.com/topics/treasury-risk-management) and [systems](https://gravam.com/topics/treasury-systems-architecture) — so the examples below cross those areas.)

## Why measure

You can't manage what you can't see. KPIs turn "treasury feels like it's doing okay" into something objective — a number that shows whether the cash forecast is actually improving, whether payments are getting more automated, whether risk is within bounds. They create accountability, surface drift before it becomes a problem, and give treasury a credible way to report its performance upward. Without them, good and bad treasuries look the same until something breaks.

## The categories, with examples

Treasury performance splits into four areas, each with its own measures:

### Liquidity and cash

- **Cash forecast accuracy** — how close forecasts are to actuals. The core measure of whether you can [trust the forecast](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy).
- **Days cash on hand** — how long the company could operate on available cash.
- **Idle cash** — balances sitting in accounts earning nothing, a sign of poor [visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility) or mobilization.

### Efficiency

- **Straight-through-processing rate** — the share of transactions flowing [without manual intervention](https://gravam.com/blog/straight-through-processing-in-treasury). A direct measure of process health and risk.
- **Cost per payment / manual effort** — how much human effort the operation consumes.

### Risk

- **Hedge coverage ratio** — how much of an exposure is [hedged](https://gravam.com/blog/what-is-treasury-risk-management), against the policy target.
- **Counterparty concentration** — how much is exposed to any single [bank or institution](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury).
- **Limit breaches** — how often policy limits are exceeded.

### Cost

- **Bank fees** — total banking cost, and whether [fee analysis](https://gravam.com/blog/bank-fee-analysis) is recovering overcharges.
- **Cost of funds** — the effective cost of the company's borrowing.

## Leading vs lagging

Some KPIs are **lagging** — they tell you what already happened (last quarter's forecast accuracy). Others are **leading** — they hint at what's coming (a rising share of manual transactions predicts future errors). A good set has both: lagging measures for accountability, leading ones for early warning. Relying only on lagging KPIs means you always learn about problems after they've cost you.

## The measures, defined

Most arguments about treasury KPIs are really arguments about definitions — two people report the same measure from different denominators and then disagree about the business. So here is the arithmetic, the cadence and the owner for the common ones, in one place.

| KPI | How it is calculated | Typical frequency | Who owns it | Leading or lagging |
| --- | --- | --- | --- | --- |
| **[Cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility)** | Balances treasury can see without manual collection ÷ total group balances. Count it by value or by number of accounts — both are used, so state which | Daily | Cash manager / treasury operations | Leading |
| **[Cash forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy)** | Forecast against actual for a fixed horizon: absolute error ÷ actual. Absolute error sizes the miss and signed variance shows bias, so most sets report both rather than choosing | Monthly, per horizon | Forecast owner (usually a treasury analyst) | Lagging |
| **[Straight-through-processing rate](https://gravam.com/blog/straight-through-processing-in-treasury)** | Transactions completing with no manual intervention ÷ all transactions in the period. The number turns on what counts as a touch — re-keying only, or any manual approval — so fix that first | Monthly | Treasury operations | Leading |
| **[Bank fees](https://gravam.com/blog/bank-fee-analysis)** | Total charges billed across all banks in the period, compared line by line against the agreed price schedule | Billed monthly, reviewed quarterly | Treasury operations / cash manager | Lagging |
| **DSO, DPO and the [cash conversion cycle](https://gravam.com/blog/working-capital-and-cash)** | CCC = DSO + DIO − DPO. DSO = receivables ÷ credit sales × days in period; DPO = payables ÷ cost of goods sold × days in period — some houses use purchases instead of COGS, so pick one and keep it | Monthly | Credit control, operations and procurement own the levers; treasury reports the cycle | Lagging |
| **Hedge ratio against [policy](https://gravam.com/blog/treasury-risk-management-policy)** | Notional hedged ÷ exposure in scope, read against the target or band the policy sets. Whether "in scope" means forecast or booked exposure is a policy question, not a spreadsheet one | Monthly, or whenever exposures are captured | Risk manager | Leading |
| **[Counterparty concentration](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury)** | Exposure to one institution ÷ total exposure, read against the per-counterparty limit. Cash, deposits and derivative mark-to-market can be aggregated or tracked separately; the policy decides | Monthly; daily where balances move | Risk manager / treasurer | Leading |
| **Days to close** | Days from period end to treasury's numbers being signed off. Working days or calendar days, to first draft or to final sign-off — four combinations, so name the one you mean | Monthly | Treasury accounting | Lagging |

Two things that table deliberately does not do. It doesn't say what a good number looks like — the comparison that matters is your own baseline and its trend, not somebody else's, which is why "no baseline or target" is on the failure list below. And it doesn't repeat every measure named above: days cash on hand, idle cash, cost of funds and limit breaches are defined the same way, by writing down the numerator, the denominator, the period and the owner before anyone reports a number.

## Treasury KPI monitoring: source, cadence, threshold, owner

Defining a KPI is half the work. Monitoring it is the other half, and it is a separate design: where the number comes from, how often someone looks, what value makes them act, and through which channel they find out. A KPI that is calculated correctly and looked at only when the board pack is due is being reported, not monitored.

Five decisions per KPI:

- **Data source.** The system the number is drawn from, named. If it takes a person and a spreadsheet to assemble, that is the first thing to fix — a hand-built KPI gets produced late and is the first to be dropped in a busy week. This is a [reporting architecture](https://gravam.com/blog/treasury-reporting-and-analytics-architecture) question before it is a dashboard question.
- **Cadence.** Match it to how fast the measure can change, not to the reporting calendar. A balance or a limit can move within a day; forecast accuracy cannot be known until the period has closed.
- **Threshold.** The value at which someone must act. For risk measures it comes from [the limits the policy sets](https://gravam.com/blog/risk-appetite-and-limits-in-treasury); for operational ones it comes from the KPI's own baseline and trend. No threshold, no monitoring.
- **Owner.** One named role that receives the breach and is expected to respond — for the measures in the table above, the owner named there; for the rest, name one before the threshold is set.
- **Channel: dashboard, alert or report.** Covered below.

### What each KPI is monitored from

| KPI | Data source | Monitoring cadence | What triggers action | Channel |
| --- | --- | --- | --- | --- |
| **Cash visibility** | Bank statement feeds against the account inventory | Daily | An account with no statement received | Alert |
| **Days cash on hand** | The [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) and the operating cost base from the ERP | Weekly, daily under stress | Falling below the floor the liquidity policy sets | Dashboard |
| **Idle cash** | Daily position, per account | Daily | A balance above the account's target left unswept | Dashboard |
| **Cash forecast accuracy** | Forecast snapshots against actuals from statements | Monthly, per horizon | Error outside the agreed band, or a persistent bias one way | Report |
| **Straight-through-processing rate** | Payment and reconciliation logs in the TMS or ERP | Monthly; exceptions daily | The rate dropping against its baseline; a growing repair queue | Report, with a daily queue |
| **Cost per payment / manual effort** | Bank billing plus payment volumes; time spent, where it is recorded | Quarterly | A rising trend | Report |
| **Hedge ratio** | Exposures and hedge deals in the TMS | Monthly, and at each exposure update | Coverage outside the policy band | Dashboard and report |
| **Counterparty concentration** | Balances, deposits and derivative valuations by counterparty | Daily where balances move | Exposure approaching or over a counterparty limit | Alert |
| **Limit breaches** | The limit checks themselves | Continuous | Any breach | Alert |
| **Bank fees** | Bank billing statements against the agreed price schedule | Quarterly | A charge that does not match the schedule | Report |
| **Cost of funds** | Debt and facility records in the TMS, interest paid from the ERP | Monthly or quarterly | Drift against budget or against the previous period | Report |
| **DSO, DPO, cash conversion cycle** | ERP receivables, payables and inventory | Monthly | The cycle lengthening against baseline | Report |
| **Days to close** | The close calendar and sign-off dates | Monthly | A close that runs past the agreed day | Report |

The cadences and triggers here are common practice, not a standard, and the table deliberately contains no target values: the threshold is yours to set, from policy where there is one and from your own baseline where there isn't.

### Dashboard, alert or report

The three channels do different jobs, and most monitoring problems are a KPI sitting in the wrong one.

- **An alert** is for a measure where a single event needs a same-day response: a missing statement, a limit breach, a counterparty over its limit. It should reach the owner without the owner going to look. Alerts on the data feeds themselves — [interface monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation) — belong here too, because every KPI above is only as current as the feed underneath it.
- **A dashboard** is for a level someone checks routinely and acts on within days: liquidity headroom, idle balances, hedge coverage. It shows the current value against the threshold.
- **A report** is for measures that only mean something over a period and are discussed rather than reacted to: forecast accuracy, STP rate, fees, working capital, close. It shows the trend and carries commentary.

Putting a monthly measure on a live dashboard adds a tile nobody can act on; putting a limit breach in a monthly report means learning about it weeks late. And before any of it is trusted, the inputs have to be: a KPI built on incomplete or inconsistent data is a precise-looking wrong number, which makes [data quality](https://gravam.com/blog/treasury-data-quality-and-governance) a precondition of monitoring rather than a separate project.

## Choosing good KPIs

> The test for a KPI: if it moved the wrong way, would someone _do_ something? If yes, it's a real KPI. If it would just be noted and filed, it's a vanity metric taking up space. Measure the few things that would actually change a decision.

Good KPIs are **few** (a focused set beats a sprawling dashboard), **meaningful** (they reflect something that genuinely matters), **actionable** (someone can act on them), and **tied to objectives** (they measure progress toward [what a corporate treasury does](https://gravam.com/blog/what-does-a-corporate-treasury-do), not activity for its own sake). Each should have an owner and prompt a decision when it moves.

## Treasury KPIs that measure activity, not outcomes

- **Vanity metrics.** Measuring what's easy (number of payments processed) rather than what matters (were they right, cheap, on time?).
- **Too many KPIs.** A huge dashboard that's reported but never acted on, so the signal drowns in noise.
- **No action.** KPIs that move the wrong way and prompt nothing — measurement as ritual.
- **No baseline or target.** Numbers with nothing to compare against, so you can't tell good from bad.
- **Measuring activity, not outcome.** Tracking how busy treasury is instead of how well it's achieving its goals.

Pick a small set of KPIs across liquidity, efficiency, risk and cost; make sure each is meaningful, actionable and owned; and use them to prompt decisions, not just fill a report — and treasury performance becomes visible, accountable and improvable. The point was never the dashboard; it's that what gets measured, and _acted on_, gets better.

***

_See also [measuring cash forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy), [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury), and [SAP Portfolio Analyzer](https://gravam.com/blog/sap-portfolio-analyzer) for return and benchmark measurement on the investment book._

## Questions this article answers

**Q: What are treasury KPIs?**

Treasury KPIs are the key performance indicators a treasury function uses to measure how well it's doing its job — across liquidity (like cash forecast accuracy and days cash on hand), efficiency (like straight-through-processing rate and cost per payment), risk (like hedge coverage and counterparty concentration), and cost (like bank fees and cost of funds). Good KPIs make treasury performance visible so it can be managed and improved, and give the function objective measures to report and be accountable against.

**Q: What are good examples of treasury KPIs?**

Common ones include: cash forecast accuracy (how close forecasts are to actuals); days cash on hand (how long the company could operate on available cash); idle cash (balances earning nothing); straight-through-processing rate (share of transactions flowing without manual intervention); hedge coverage ratio (how much exposure is hedged); counterparty concentration (how much is exposed to any one bank); and total bank fees. The right set depends on the treasury's objectives — a handful of meaningful, actionable measures beats a large dashboard nobody acts on.

**Q: What is treasury KPI monitoring?**

Treasury KPI monitoring is the routine of checking a defined set of treasury measures against thresholds, on a fixed cadence, with a named person responsible for acting when one moves. It has five parts: a data source for each KPI (bank statements, the TMS, the ERP, the forecast, bank billing), a cadence that matches how fast the measure can change (daily for cash and limits, monthly for accuracy, cost and working capital), a threshold taken from policy or from the KPI's own baseline, an owner, and a channel — a dashboard or alert for measures that need a same-day reaction, a periodic report for the ones that are reviewed and discussed. Reporting a KPI is not monitoring it; monitoring means a breach triggers an action.

**Q: How do you choose the right treasury KPIs?**

Pick a small number of measures that are meaningful (they reflect something that genuinely matters), actionable (someone can do something about them), and tied to the treasury's actual objectives. Avoid vanity metrics that are easy to measure but don't reflect real performance, and resist measuring everything — a focused set that drives action beats a sprawling dashboard that just gets reported. Each KPI should have an owner and prompt a decision when it moves the wrong way.

---

# Electronic Bank Account Management (eBAM)

Source: https://gravam.com/blog/electronic-bank-account-management-ebam
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Electronic bank account management (eBAM) handles opening, closing, mandates and signatories digitally, not on paper. Why account admin is broken.

**eBAM — electronic Bank Account Management — is the electronic, standardized management of a company's bank accounts: opening and closing them, and maintaining mandates and signatories, exchanged digitally with banks instead of via paper forms and wet-ink signatures.** It exists to fix something genuinely broken: bank account administration is otherwise slow, manual, paper-driven, and the reason signatory and account data quietly drifts out of date — people leave, mandates go stale, and no one holds a clean picture of every account and who can act on it. eBAM brings control, speed and an audit trail to the one area of cash management that's usually stuck in the fax era.

## What it is

Every company has to _administer_ its bank accounts, not just use them: open new ones, close old ones, and — constantly — change who is authorized to sign, approve or transact on each. Traditionally that's paper forms, wet signatures and manual to-and-fro with each bank. eBAM digitizes and _standardizes_ that whole process, so account administration becomes an electronic, controlled, auditable workflow.

## The problem it solves

> Ask a large company for a current, complete list of every bank account and exactly who's authorized on each — and watch the silence. That gap, where signatory data has quietly gone stale, is the risk eBAM exists to close.

Bank account admin is where good treasuries have a blind spot. It's paper-based and slow, so it's neglected; and because it's neglected, **signatory and mandate records drift**. Someone leaves the company but stays authorized on an account. A mandate is never updated. No one has a single accurate view of every account and its authorized users. In a function obsessed with control, this is a surprisingly common and serious gap — and it's precisely a _control_ risk, since account authority is authority over money.

## What it covers

- **Account opening and closing** — requesting and confirming new accounts, and retiring old ones.
- **Mandate and signatory maintenance** — keeping the record of who can do what on each account current.
- **Supporting documentation** — the KYC, authorization and related documents banks require.

## The standard

eBAM runs on **ISO 20022**, specifically the **acmt (account management)** message family — standardized messages for account opening, closing and mandate maintenance, exchanged between company and bank. A common standard is the whole point: it's what lets account administration be automated and consistent _across many banks_, rather than every bank having its own proprietary forms. (It's the same [ISO 20022](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) family that standardizes payments and statements, applied to account management.)

## The benefits

- **Control** — a governed, workflow-driven process instead of ad hoc paper.
- **Audit trail** — a record of who requested and approved every account and mandate change.
- **Speed** — electronic requests instead of forms and postal delays.
- **Accurate records** — a current, single view of every account and its authorized users.

## eBAM is account _governance_

eBAM is the tooling that makes real [bank account governance](https://gravam.com/blog/bank-account-rationalization) possible. Rationalization gives you a clean account structure; eBAM is how you _keep_ it clean — controlling account opening and closing (so [sprawl](https://gravam.com/blog/bank-account-rationalization) doesn't creep back) and keeping the [account inventory](https://gravam.com/blog/how-to-achieve-global-cash-visibility) and signatory records accurate over time (in S/4HANA, that internal book of record is [SAP Bank Account Management](https://gravam.com/blog/sap-bank-account-management-s4hana)). Rationalize once with a manual effort; govern continuously with eBAM.

## Why adoption has been hard

Honesty matters here: eBAM has been slower to spread than its logic suggests, and the reason is **bank support**. The full benefit needs your banks to support the acmt messages end to end, and coverage has historically been patchy and inconsistent across banks and countries. So many companies run a partial or hybrid model — electronic where they can, paper where they must. It's improving, but check your banks' actual eBAM capability before assuming a fully-electronic process.

## Why eBAM rollouts end up half on paper

- **Partial bank support.** Assuming full eBAM when key banks don't support the messages, leaving a hybrid paper/electronic mess.
- **Treating it as an IT project.** eBAM is a _governance_ improvement enabled by technology — run it for control and accurate data, not just automation.
- **No clean starting inventory.** Digitizing on top of an inaccurate account and signatory list just makes the wrong data faster; start from a clean [inventory](https://gravam.com/blog/how-to-achieve-global-cash-visibility).
- **Neglecting it entirely.** Leaving account admin as paper, and accepting the stale-signatory control risk that comes with it.

Bring bank account administration into a controlled, standardized, auditable process, and you close one of treasury's quieter control gaps — the stale mandate, the departed employee still authorized, the account nobody remembers. eBAM is unglamorous, but it's how a treasury actually _governs_ the accounts through which all its money moves. Together with [rationalization](https://gravam.com/blog/bank-account-rationalization) and [virtual accounts](https://gravam.com/blog/virtual-account-management-structures), it's the modern discipline of keeping the bank-account estate lean, current and controlled.

***

_See also [bank account rationalization](https://gravam.com/blog/bank-account-rationalization) and [what are virtual accounts](https://gravam.com/blog/virtual-account-management-structures)._

## Primary sources

- SWIFT / CGI-MP — Common Global Implementation working groups (eBAM) — accessed 2026-07-28 — https://www.swift.com/standards/market-practice/common-global-implementation/cgi-mp-working-groups
- ISO 20022 — Message definitions (acmt / account management) — accessed 2026-07-28 — https://www.iso20022.org/iso-20022-message-definitions

## Questions this article answers

**Q: What is eBAM?**

eBAM (electronic Bank Account Management) is the electronic, standardized management of a company's bank accounts — opening and closing accounts, and maintaining mandates, signatories and related documentation — exchanged digitally between the company and its banks, instead of via paper forms and wet-ink signatures. It aims to make bank account administration faster, controlled and auditable, and to keep the company's record of who can do what on which account accurate and up to date.

**Q: What problem does eBAM solve?**

Bank account administration is traditionally paper-based, slow and error-prone: opening or closing an account, or changing who is authorized to sign on it, involves forms, wet signatures and manual back-and-forth with each bank. As a result, signatory and mandate records drift out of date — people leave the company but remain authorized, and no one has a clean, current picture of every account and its authorized users. eBAM digitizes and standardizes this, giving control, speed and an audit trail, and keeping account and signatory data accurate.

**Q: What standard does eBAM use?**

eBAM is built on ISO 20022, specifically the acmt (account management) message family — for example account opening and closing requests and mandate maintenance messages exchanged between a company and its banks. Using a common standard is what allows account management to be automated and consistent across multiple banks, rather than each bank having its own proprietary forms and process. In practice, adoption depends on banks supporting the messages, which has been the main barrier to eBAM's spread.

---

# Liquidity Risk Management for Corporate Treasury

Source: https://gravam.com/blog/liquidity-risk-management
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: Liquidity risk management: not having cash when needed is the one risk that fails companies, even profitable ones. Forecasts, buffers, lines, stress tests.

**Liquidity risk is the risk of not having cash available when it's needed to meet obligations as they fall due — and it's the one financial risk that actually causes companies to fail.** A business can be profitable on paper and still collapse if it can't pay its suppliers, staff or lenders on the day the money is due, because insolvency is a _cash-timing_ event, not a profitability one. Managing liquidity risk means forecasting future cash needs, holding adequate buffers and committed facilities, diversifying funding, and stress-testing against the bad days. It's the most existential of the [financial risks treasury manages](https://gravam.com/blog/what-is-treasury-risk-management) — the one where getting it wrong doesn't just hurt, it ends the company.

## What it is

Liquidity risk is, simply, the danger of running out of usable cash at the wrong moment. Not over a year — on a _specific date_, when payroll runs, a supplier must be paid, or a loan repayment falls due. It's the gap between the cash you have available and the obligations you must meet, at every point in time.

## Why it's the most existential risk

> Profit is an opinion measured over a period; cash is a fact measured on a date. Companies don't fail because they're unprofitable — they fail because on some specific morning, the money that had to be there wasn't.

This is what makes liquidity risk uniquely dangerous. A currency loss or a rate rise _hurts_; an inability to meet an obligation _ends the business_. A profitable, growing company whose [cash is tied up](https://gravam.com/blog/working-capital-and-cash), whose big receipt is late, or whose funding was pulled can be insolvent despite a healthy P&L. Liquidity risk is where financial risk becomes existential.

## The two forms

- **Funding liquidity risk** — being unable to meet obligations as they fall due. The one that matters most for corporates.
- **Market liquidity risk** — being unable to sell an asset quickly without a significant loss (so it can't be relied on as a cash source).

For most companies, managing liquidity risk means managing _funding_ liquidity: always having enough usable cash and committed credit to meet what's coming.

## How to manage it

- **Forecast the needs.** You can only ensure cash is there if you know when and how much you'll need — which is exactly what the [cash forecast](https://gravam.com/blog/13-week-cash-flow-forecast) is for. Liquidity management rests on it.
- **Hold liquidity buffers.** A cushion of readily available liquidity — cash plus **committed undrawn credit facilities** — so there's headroom above the expected need.
- **Diversify funding.** Don't depend on a single lender, market or facility; concentration of funding is itself a liquidity risk.
- **Stress-test.** Plan for the bad scenarios — a major receipt delayed, a facility withdrawn, a market shock — and check you'd still have headroom.

## Buffers and facilities

Available liquidity isn't just cash in the bank — it's cash _plus_ the credit you can actually draw on demand. The critical word is **committed**: an undrawn _committed_ facility is liquidity you can rely on; an _uncommitted_ one can be pulled exactly when you need it most, which is no protection at all. Liquidity headroom is the sum of usable cash and genuinely committed facilities, measured against the obligations ahead.

## Forecasting is the foundation

Everything rests on knowing the future cash profile. A reliable [13-week (and longer) forecast](https://gravam.com/blog/13-week-cash-flow-forecast) is what turns liquidity management from hope into control — it shows exactly which future week the cash might fall short, in time to arrange funding. The free [13-week cash flow model](https://gravam.com/tools/13-week-cash-flow-model) is a working template for that view. Without a forecast, liquidity risk management is guesswork; with one, it's a plan. It's also why [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility) and [cash mobilisation](https://gravam.com/blog/what-is-an-in-house-bank) matter: cash you can't see or move isn't liquidity you can use.

## Stress testing and contingency

Normal-case liquidity isn't enough — the risk lives in the _bad_ case. [Stress-test against concrete scenarios](https://gravam.com/blog/stress-testing-and-scenario-analysis-treasury): a large customer pays a month late, a bank pulls a facility, a market freezes. If any plausible scenario leaves you without headroom, that's a gap to close _now_ — with more buffer, more committed facilities, or a contingency plan — not a surprise to discover on the day.

## The metrics to watch — and when to escalate

Liquidity risk is managed by watching a handful of numbers and knowing the level at which each one triggers action. Set the trigger _before_ you're near it; the point of the table is that nobody has to improvise on a bad morning.

| Metric | What it measures | Escalation trigger |
| --- | --- | --- |
| **Liquidity headroom** | Usable cash + committed facilities − obligations ahead | Headroom falls below the policy floor |
| **Survival horizon** | Days the group can operate with no new funding | Drops below the board-agreed minimum |
| **Committed facility headroom** | Undrawn _committed_ credit you can actually rely on | Uncommitted share rising, or a renewal inside the notice window |
| **Funding concentration** | Share of funding from any single lender or market | Any one source above the concentration limit |
| **Forecast accuracy** | Actual-vs-forecast variance on the near horizon | Variance breaches the tolerance that makes the buffer unreliable |

The discipline is the trigger column. A metric with no pre-agreed trigger is a chart nobody acts on until it's already a crisis.

## How companies run short of cash

- **Confusing profit with cash.** Assuming a profitable business is a safe one, and missing the cash-timing trap.
- **No buffer.** Running with no headroom, so any surprise becomes a crisis.
- **Relying on uncommitted facilities.** Counting on credit that can be withdrawn precisely when it's needed.
- **Funding concentration.** Depending on one lender or market, so its loss is catastrophic.
- **No stress testing.** Planning only for the normal case, so the bad case is a surprise.
- **Ignoring timing.** Looking at cash in aggregate rather than at the specific dates obligations fall due.

Forecast the needs, hold real buffers and committed facilities, diversify funding, and stress-test the bad days — and liquidity risk becomes a managed headroom rather than the quiet cliff a profitable-looking company can walk off. Of all the [risks treasury manages](https://gravam.com/blog/what-is-treasury-risk-management), this is the one where the discipline isn't optional: it's the difference between a hard quarter and no more quarters. And when the buffer is actually breached, a pre-agreed [liquidity escalation framework](https://gravam.com/blog/liquidity-escalation-framework) turns the squeeze into a graduated plan rather than a real-time scramble.

***

_See also [the 13-week cash flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast) and [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management)._

## Questions this article answers

**Q: What is liquidity risk?**

Liquidity risk is the risk of not having cash available when it's needed to meet obligations as they fall due. It's the most existential financial risk because it's the one that actually causes companies to fail — a business can be profitable on paper and still collapse if it can't pay its bills, staff or lenders on time. There are two forms: funding liquidity risk (being unable to meet obligations) and market liquidity risk (being unable to sell an asset without a big loss); for most corporates, funding liquidity is the one that matters most.

**Q: How do companies manage liquidity risk?**

By forecasting future cash needs, holding adequate liquidity buffers (cash plus committed undrawn credit facilities), diversifying funding sources so they don't all depend on one lender or market, and stress-testing against scenarios like a major receipt arriving late or a facility being withdrawn. The foundation is a reliable cash forecast: you can only ensure liquidity is available if you know when and how much cash you'll need. Managing liquidity risk is fundamentally about always having headroom between available liquidity and obligations.

**Q: Why can a profitable company still fail from liquidity risk?**

Because profit and cash are different things on different timings. Profit is an accounting measure over a period; liquidity is having actual cash in the bank at the moment an obligation falls due. A company can be growing and profitable but still be unable to pay a supplier, meet payroll or repay a loan on a specific date if its cash is tied up, its receipts are delayed, or its funding is withdrawn. Insolvency is a cash-timing event, not a profitability one, which is why liquidity risk is the most dangerous risk of all.

---

# Managing Surplus Cash: Short-Term Investment Basics

Source: https://gravam.com/blog/managing-surplus-cash
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: Putting surplus cash to work safely, governed by a policy that ranks security, then liquidity, then yield. The cardinal rule of corporate cash investment.

**Managing surplus cash means putting cash the business doesn't need immediately to work safely — governed by an investment policy that prioritizes, in strict order, _security_, then _liquidity_, then _yield_.** The single most important thing to understand about corporate cash investment is that it is _not_ about maximizing return. This is the company's operating cash, not its risk capital — so the job is to preserve it and keep it accessible, taking whatever yield is available _within_ those constraints, never by loosening them. A treasury that reaches for return with operating cash is taking a risk it can't afford, however small the extra yield looks.

_(This is a description of the treasury discipline, not investment advice — the aim here is how corporates think about the problem, not a recommendation for any specific situation.)_

## Short-duration solutions for surplus cash

"Short-duration solutions" is the market's name for a small, standard set of instruments. None is best in general; each trades tenor, access and risk differently, and the investment policy decides which are allowed.

| Instrument | Typical tenor | Liquidity | Main risk |
| --- | --- | --- | --- |
| **Bank deposits** (call and time deposits) | Overnight to several months, as agreed with the bank | Call: on demand. Time deposit: fixed until maturity | Exposure to one bank |
| **[Money market funds](https://gravam.com/blog/money-market-funds-for-corporate-treasury)** | No fixed term; you hold units in a short-dated portfolio | Usually same-day or next-day dealing; fees can apply in stress | Not a deposit and not guaranteed; fund liquidity under stress |
| **Treasury bills and other short government paper** | Fixed at issue; US bills run from 4 to 52 weeks | Can be sold before maturity, at the market price | Price moves if sold early; sovereign credit |
| **Commercial paper** | Fixed at issue; in the US up to 270 days, averaging about 30 | Commonly held to maturity | Credit of a single corporate or bank issuer |
| **Repo** (lending cash against securities) | Overnight to a few months, as agreed | Fixed until the agreed repurchase date | Counterparty default, mitigated by the collateral's quality |
| **Short-duration bond funds and separately managed accounts** | No fixed term; portfolio maturities longer than a money fund's | Depends on the vehicle and on what it holds | Interest-rate and credit-spread losses; price is not stable |

Three notes on reading it:

- **The maturity limits on money market funds are law, not convention.** A short-term MMF under [Regulation (EU) 2017/1131](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R1131) must keep a weighted average maturity of no more than 60 days and a weighted average life of no more than 120 days, and may only buy money market instruments with a legal or residual maturity of 397 days or less. The SEC's rule 2a-7 applies the same 60- and 120-day caps to US money market funds. The other rows have no equivalent single rule; their tenors are what the market and your policy make them.
- **The bill and commercial paper figures are US figures.** [TreasuryDirect](https://www.treasurydirect.gov/marketable-securities/treasury-bills/) lists bill terms of 4, 6, 8, 13, 17, 26 and 52 weeks; the [Federal Reserve](https://www.federalreserve.gov/releases/cp/about.htm) describes commercial paper maturities as ranging up to 270 days but averaging about 30. Other markets issue on their own calendars, which are not verified here.
- **"Short-duration bond fund" is a marketing category, not a regulatory one.** Unlike a money market fund, nothing fixes what it must hold, so no maturity figure is given. It belongs to the strategic tier at most, never to operating cash.

Which of these you may use, and how much with any one name, is the job of the policy below — not of the yield on the day.

## What it is

A business rarely holds exactly the cash it needs, moment to moment. Beyond the operating buffer sits **surplus cash** — money not required right now. Managing it means the deliberate decision of where that cash sits so it isn't idle _and_ isn't at risk: the alternative to a policy is either dead money earning nothing or, worse, cash quietly exposed to loss.

## The priority order: security, liquidity, yield

The governing principle, in order:

1. **Security (capital preservation).** Don't lose the money. Full stop.
2. **Liquidity.** Be able to get at it when the business needs it.
3. **Yield.** Take the return available _after_ satisfying the first two.

> Corporate cash investment isn't ranked by return. It's ranked security first, liquidity second, yield last — and the discipline is never letting the order flip, no matter how good the yield looks.

## Why security comes first

The asymmetry is the whole point. A slightly lower yield costs a little; a loss of operating cash can threaten the business itself. Payroll, suppliers and debt service don't wait, and they can't be paid with an investment that's underwater or locked up. So the downside of reaching for yield is categorically worse than the upside — which is exactly why security, not return, leads.

## Cash segmentation

Not all surplus cash is the same, and treating it as one pool wastes opportunity or takes needless risk. A common approach is to **segment** by how soon it's needed:

| Tier | Horizon | Treatment |
| --- | --- | --- |
| **Operating** | Days–weeks | Maximum liquidity; instant access |
| **Reserve** | Weeks–months | Still safe and liquid, slightly longer |
| **Strategic** | Months+ | Known not-needed-soon; can accept modestly longer maturities |

Segmentation lets you keep near-term cash fully liquid while letting genuinely longer-horizon cash earn a little more — _without_ compromising the money you might need next week. It rests entirely on a good [cash forecast](https://gravam.com/blog/13-week-cash-flow-forecast): you can only tier cash by when it's needed if you actually know when it's needed.

## The investment policy

The discipline is encoded in an **investment policy** — the document that turns the principles into hard rules: [which instrument types are permitted](https://gravam.com/blog/money-market-funds-for-corporate-treasury), minimum credit quality, maximum maturities, concentration and counterparty limits, and who approves what. Its purpose is to make the safe choice the _only allowed_ choice, so decisions stay within bounds regardless of who's making them or how tempting a number looks. No surplus cash should be invested without one.

## Concentration and counterparty limits

Even safe instruments become risky if all the cash sits in one place. **Counterparty limits** cap how much is exposed to any single bank or issuer, so the failure of one doesn't take the whole balance with it. This is the same instinct behind [bank account structure](https://gravam.com/blog/bank-account-rationalization) and [visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility): know where the cash is, and don't let too much of it concentrate anywhere.

## Surplus cash investment mistakes

- **Reaching for yield.** Inverting the priority order and chasing return with cash that can't afford risk — the cardinal sin.
- **No policy.** Investing surplus cash on judgement alone, so the rules change with whoever's deciding.
- **Concentration.** Too much cash with one counterparty, turning a safe instrument into a single point of failure.
- **Illiquidity.** Locking cash into longer maturities that a real forecast would have flagged as needed sooner.
- **Idle cash.** The opposite failure — leaving large balances doing nothing because no one manages them at all.

Keep security first, liquidity second and yield last; segment cash by when it's genuinely needed; encode the rules in a policy; and cap concentration — and managing surplus cash becomes what it should be: putting idle money to work _safely_, never gambling with money the business can't afford to lose. It's the least glamorous corner of treasury, and one where the discipline matters more than the cleverness.

***

_See also [the 13-week cash flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast) and [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility)._

## Primary sources

The instrument comparison is deliberately generic. The specific figures in it are sourced: money market fund maturity limits from Regulation (EU) 2017/1131 and the SEC's 2023 adopting release, US Treasury bill terms from TreasuryDirect, and US commercial paper maturities from the Federal Reserve. Deposit-protection schemes, non-US government bill programmes and tax treatment are not covered — check them for your jurisdiction.

- EUR-Lex — Regulation (EU) 2017/1131 of the European Parliament and of the Council of 14 June 2017 on money market funds — accessed 2026-10-04 — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32017R1131
- SEC — Money Market Fund Reforms; Form PF Reporting Requirements for Large Liquidity Fund Advisers (Release No. 33-11211, final rule) — accessed 2026-10-04 — https://www.sec.gov/files/rules/final/2023/33-11211.pdf
- TreasuryDirect — Treasury Bills — accessed 2026-10-04 — https://www.treasurydirect.gov/marketable-securities/treasury-bills/
- Federal Reserve Board — Commercial Paper Rates and Outstanding Summary: About — accessed 2026-10-04 — https://www.federalreserve.gov/releases/cp/about.htm

## Questions this article answers

**Q: What are short-duration solutions for surplus cash?**

Short-duration solutions for surplus cash are the standard short-dated instruments a corporate treasury may use under its investment policy: bank call and time deposits, money market funds, Treasury bills and other short government paper, commercial paper, repo, and — for cash with a longer horizon — short-duration bond funds or separately managed accounts. They differ in tenor, access and main risk. A time deposit is fixed until maturity and concentrates exposure on one bank; a money market fund usually deals same-day or next-day but is not a deposit and is not guaranteed; bills and commercial paper have a fixed maturity (US Treasury bills are issued for 4 to 52 weeks, US commercial paper for up to 270 days); bond funds carry price risk. Regulated short-term money market funds must keep a weighted average maturity of no more than 60 days.

**Q: What does managing surplus cash mean?**

Managing surplus cash means deciding what to do with cash the business doesn't need for immediate operations — putting it to work safely rather than leaving it idle — within the bounds of an investment policy. For a corporate, it is not about maximizing return; it's about preserving the capital and keeping it accessible, with yield a distant third priority. This is a treasury discipline, not investment advice: the goal is safety and liquidity, because this is the company's operating cash, not its risk capital.

**Q: What is the priority order for investing corporate cash?**

Security, then liquidity, then yield — in that order, sometimes remembered as 'SLY.' Security (capital preservation) comes first because losing operating cash is catastrophic in a way that a slightly lower return never is. Liquidity comes second: the cash must be available when the business needs it. Yield comes last: you take the return available within the security and liquidity constraints, rather than reaching for return by loosening them. A corporate treasury that inverts this order is taking risks with money it can't afford to lose.

**Q: What is a cash investment policy?**

A cash investment policy is the governing document that defines how a company may invest its surplus cash — which instrument types are permitted, credit-quality minimums, maturity limits, concentration and counterparty limits, and who can approve what. Its purpose is to encode the security-liquidity-yield priorities into hard rules, so investment decisions stay within safe bounds regardless of who makes them or how tempting a higher return looks. No surplus cash should be invested without one.

---

# Bank Fee Analysis: How to Stop Overpaying Your Banks

Source: https://gravam.com/blog/bank-fee-analysis
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Bank fee analysis reconciles bank charges against agreed pricing. How camt.086, TWIST BSB and AFP service codes make fees comparable, field by field.

**Bank fee analysis is the practice of systematically reviewing what your banks charge — reconciling actual fees against agreed pricing, catching errors and overcharges, and benchmarking your costs.** It matters because bank charges are opaque, voluminous and _frequently wrong_: a large company can be billed for thousands of individual services a month, in inconsistent language, against pricing buried in contracts nobody's reopened in years. Left unchecked, the overcharges simply accumulate. Analyzed methodically, bank fees give back real money — and the data to manage your banking relationships from evidence instead of guesswork.

## Why bank fees are hard

The difficulty is structural, not accidental:

- **Opacity.** Charges are described in each bank's own terms, often cryptically.
- **Volume.** Thousands of line items across many [accounts](https://gravam.com/blog/bank-account-rationalization) and banks, every month.
- **Inconsistency.** The same service is named and coded differently by different banks.
- **Stale pricing.** The agreed rates live in contracts that may be years old and rarely consulted.

Put together, these make manual reconciliation practically impossible — which is precisely why errors survive. What can't be checked, isn't.

## The standards that make it possible

The key to tractable analysis is a _common language_ for charges, and there are three electronic formats that carry one, plus one code set that makes them comparable:

| Standard | What it is | Where you meet it |
| --- | --- | --- |
| **ANSI X12 822** (Account Analysis) | The US EDI transaction set for account analysis statements: service charges, balances, volumes, earnings credit | US banks, for decades; the US AFP Service Code is a mandatory field in it |
| **TWIST BSB** (Bank Services Billing) | The XML billing statement defined by the TWIST standards group, the design the ISO message was built from | Earlier global billing implementations |
| **camt.086** BankServicesBillingStatement | The ISO 20022 message; per AFP and trade coverage, the functional equivalent of TWIST BSB version 3.1, changed only to conform to ISO 20022 conventions | The format to ask for today, alongside your other [camt messages](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) |
| **AFP Service Codes** | The code set that maps each bank's own service names to a common identifier: six-character domestic (US) codes and eight-character global codes | Inside all three formats, and in bank RFP pricing grids |

The AFP codes go back to 1986, when they were created for the US 822 account analysis statement; the Global AFP Service Codes extended the idea for camt.086 and TWIST BSB files, and AFP has updated them in collaboration with the CGI-MP market-practice group that also shapes corporate [pain.001 implementations](https://gravam.com/blog/pain-001-structure-and-fields). The first two characters of a domestic code identify the service family.

> The common service code is what turns "every bank calls it something different" into "every charge maps to a comparable category." Without it you're comparing PDFs by hand; with it you can reconcile thousands of charges against agreed pricing automatically. Ask every bank for camt.086 with AFP codes populated, not just "electronic billing".

## Inside a camt.086: the fields that matter

ISO's message definition is explicit about what camt.086 is and isn't. It is a periodic, usually month-end, recounting of **every service-chargeable event** in the reporting cycle, with detailed tax and currency-translation information; account balances are strongly recommended but not required. It is **not designed to be an invoice**: it supplies the detail behind invoices or account debits, and becomes an invoice only by agreement between bank and customer. The structure is a report header and one or more billing statements, each for one account (or a parent account summarising children).

At statement level, per the camt.086.001.03 definition:

| Element | What it carries | Why fee analysis cares |
| --- | --- | --- |
| `StmtId`, `FrToDt`, `CreDtTm` | Statement identification and the billing period | The period key for matching to pricing and to the account's debits |
| `Sts` | `ORGN` original, `RPLC` replaces the original, `TEST` | A replacement must supersede, not add to, the original, or you double-count a month |
| `AcctChrtcs` / `CompstnMtd` | Account level and parent account; how charges are settled: `NOCP` not paid, `DBTD` debited, `INVD` invoiced, `DDBT` delayed debit | Tells you whether to reconcile against statement debits or against accounts-payable invoices |
| `RateData` | Non-tax per-annum rates and factors used in the statement | Earnings credit and similar rates, where the bank offsets fees against balances |
| `Bal` | Average balances held in the period | The input to balance-compensation checks |
| `Compstn` | Compensation values and service and tax totals | The statement's own totals, to foot your line-level recalculation against |
| `Svc` | One entry per service line | The analysis itself, below |
| `TaxRgn` | Tax by region, including the region's calculation method | VAT and similar taxes on bank charges, which finance may be able to recover |
| `BalAdjstmnt`, `SvcAdjstmnt` | Corrections to prior periods, incl. earnings adjustments, price and volume changes, original and new charge amounts | Retroactive corrections, which are both evidence of past errors and a way to confirm the bank fixed one |

Inside each `Svc` line:

| Element | Meaning |
| --- | --- |
| `BkSvc/Id` and `Desc` | The bank's own internal service code and description, different from the common code |
| `BkSvc/CmonCd` (`Issr`, `Id`) | The common code, with its issuer ("such as AFP", in ISO's words), so the service can be identified across banks |
| `BkSvc/BkTxCd` | Optionally, the ISO bank transaction code of the underlying transaction |
| `Vol` | The count of items charged |
| `Pric/UnitPric`, `Pric/Mtd` | Unit price, and how the charge was calculated (unit priced, flat, base, list, discount, minimum charge, tiers and others); if the method is absent, the charge is volume × unit price |
| `PmtMtd` | What happened to the charge: `BCMP` balance compensable, `FLAT` hard charge due, `PVCH` previously charged, `INVS` invoiced separately, `WVED` waived (original amount shown), `FREE` |
| `OrgnlChrgPric` | The original price, for example before a waiver |
| `BalReqrdAcctAmt` | For balance-compensable services, the average collected balance needed to offset the charge |
| `TaxDsgnt`, `TaxClctn` | Taxable status and the tax computed for the line |

## How the analysis uses them

> A camt.086 doesn't make the bank's bill right. It makes the bill recomputable, and a bill you can recompute is a bill you can dispute.

With those fields, most of the checks become arithmetic rather than detective work:

1. **Map every line to a common code.** Lines with only a bank-internal `Id` go to an exceptions list; the mapping from bank code to AFP code is the reference data your whole analysis depends on, so keep it versioned.
2. **Recompute every line.** Volume × unit price (or the stated method) against the charged amount catches calculation errors; unit price against your agreed price schedule for that common code catches off-contract pricing.
3. **Separate what is due from what is informational.** `PVCH` and `INVS` lines were charged elsewhere and must not be counted again; `WVED` lines show the value of waivers, which is worth tracking before a waiver quietly expires.
4. **Reconcile to money that moved.** Use the compensation method to tie totals to account debits (`DBTD`) or to supplier invoices (`INVD`), and apply `RPLC` statements as replacements.
5. **Check balance compensation where it applies.** For `BCMP` services, balances, rates and the balance required show whether the earnings credit covered the fees, a question that matters mostly in the US.
6. **Watch the adjustments.** A stream of `SvcAdjstmnt` entries on the same service is a process problem at the bank, and evidence for the renegotiation.

If you run SAP S/4HANA, bank fee import and monitoring is part of the full scope of [SAP Cash Management](https://gravam.com/blog/sap-cash-management-s4hana), which is where camt.086 data can land next to the bank accounts it belongs to.

## What the analysis finds

Done properly, fee analysis surfaces:

- **Billing errors.** Charges that are simply wrong — the bank's mistake, recoverable.
- **Off-contract pricing.** Being charged more than the rate you negotiated.
- **Redundant services.** Paying for things you no longer use or need.
- **Benchmarking gaps.** Costs out of line with the market or with your other banks.

## How to analyze fees

1. **Collect** the billing statements — electronically and in a standard format wherever possible.
2. **Normalize** the charges into comparable categories using standard service codes.
3. **Reconcile** actual charges against your _agreed_ pricing — which means having the agreed pricing captured and current in the first place.
4. **Investigate variances** — every gap is a billing error, an off-contract charge, or a service to question.
5. **Do it regularly**, not once — fees drift back, and small recurring overcharges compound.

## Where it connects

Fee analysis isn't isolated. Fewer accounts from [rationalization](https://gravam.com/blog/bank-account-rationalization) means fewer fees to begin with. And the fee data itself is powerful input to [**bank relationship management**](https://gravam.com/blog/bank-relationship-management) — deciding which banks get which business, and negotiating from evidence rather than impression. Combined with [cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility), it turns the banking relationship from a black box into something you actively manage.

## Why bank fee overcharges go unnoticed

- **Never checking.** Assuming the bank's charges are correct — they often aren't, and no one ever looks.
- **No standard format.** Trying to reconcile inconsistent PDFs by hand, so it never really happens.
- **No pricing baseline.** Having no captured record of what you agreed to pay, so there's nothing to reconcile _against_.
- **Ignoring small recurring charges.** Dismissing each as trivial while, monthly across every account, they add up to real money.
- **One-and-done.** Analyzing once, recovering some money, then letting it lapse until the charges drift back.

Get billing in a standard format, normalize with service codes, reconcile against agreed pricing, investigate every variance, and repeat it on a cycle — and bank fee analysis turns an opaque, quietly-overcharged cost into recovered money and negotiating leverage. It's unglamorous, entirely data-driven, and one of the more reliable ways treasury pays for itself.

***

_See also [bank account rationalization](https://gravam.com/blog/bank-account-rationalization) and [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility)._

## Primary sources

camt.086 elements and code values per ISO 20022 BankServicesBillingStatementV03 (camt.086.001.03, Bank Services Billing Maintenance 2018–2019); later message versions exist, so check the version and the AFP code edition your banks send. AFP Service Codes and ANSI X12 822 described at the level AFP publishes. Claims checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- ISO 20022 — Message Definition Report Part 2, Bank Services Billing, Maintenance 2018–2019 (camt.086.001.03 BankServicesBillingStatementV03), approved by the Payments SEG 21 January 2019 — copy distributed in the moov-io/iso20022 repository — accessed 2026-09-25 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/bank_services_billing_3/ISO20022_MDRPart2_BankServicesBilling_2018_2019_v1.pdf
- AFP — AFP Service Codes (standard for balances and charges on account analysis statements since 1986; domestic and global code sets) — accessed 2026-09-25 — https://www.financialprofessionals.org/training-resources/resources/afp-service-codes
- AFP — Global AFP Service Codes Committee Review (codes for TWIST BSB and camt.086; update with CGI-MP) — accessed 2026-09-25 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/global-afp-service-codes-committee-review
- AFP — The ISO BSB Electronic Billing Statement: Status, Acceptance, AFP Code Usage — accessed 2026-09-25 — https://www.financialprofessionals.org/docs/default-source/default-document-library/sp/81.pdf?sfvrsn=3c8d476b_2
- CTMfile — ISO 20022 camt.086 Message (BSB / Bank Services Billing) officially released — accessed 2026-09-25 — https://ctmfile.com/story/iso-20022-camt.086-message-bsb-bank-services-billing-officially-released
- Stedi — X12 822 Account Analysis transaction set — accessed 2026-09-25 — https://www.stedi.com/edi/x12/transaction-set/822

## Questions this article answers

**Q: What is bank fee analysis?**

Bank fee analysis is the practice of systematically reviewing what your banks charge you — reconciling the actual fees charged against the pricing you agreed, identifying billing errors and overcharges, spotting redundant or unexpected services, and benchmarking your costs. Because bank charges are opaque, high in volume and frequently wrong, analyzing them methodically recovers real money and gives you the data to negotiate and manage banking relationships.

**Q: Why are bank fees so hard to check?**

Bank fees are hard to check because they're opaque and voluminous: a large company can be charged for thousands of individual services across many accounts and banks each month, described in inconsistent, bank-specific language, with pricing spread across contracts that may be years old. Without a standard way to normalize and compare the charges, reconciling what you were actually billed against what you agreed to pay is nearly impossible to do by hand — which is exactly why overcharges persist unnoticed.

**Q: What is camt.086?**

camt.086 is the ISO 20022 BankServicesBillingStatement: a periodic, usually month-end, electronic statement from a bank listing every service-chargeable event on an account, with volumes, prices, how each charge was settled, taxes by region, average balances and corrections to earlier periods. It is the ISO counterpart of the TWIST Bank Services Billing format and usually carries AFP service codes so charges can be compared across banks. It supports invoices or account debits but is not itself an invoice unless bank and customer agree that it is.

**Q: How do you analyze bank fees?**

Collect the banks' billing statements (ideally in a standard electronic format such as camt.086, using standardized service codes like the AFP Service Codes), normalize the charges into comparable categories, reconcile the actual charges against your agreed pricing, and investigate every variance. This surfaces billing errors, off-contract pricing and redundant services. Doing it on a standard, automated basis — rather than eyeballing PDFs occasionally — is what turns it from a chore into recovered money and negotiating leverage.

---

# What Is a Payment Factory? Centralized Payments and POBO

Source: https://gravam.com/blog/what-is-a-payment-factory
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-09-02
Summary: A payment factory centralizes payments for many entities through one channel, often with payments-on-behalf-of (POBO). Why, how, and the intercompany catch.

**A payment factory is a centralized function — and system setup — that processes payments for many entities of a group through a single, standardized channel**, instead of each subsidiary paying from its own accounts through its own banks in its own formats. Payments are submitted to the factory, which validates, approves, formats and sends them through a consolidated bank connection. The payoff is real and broad: lower cost, standardized controls, higher [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury), better visibility, and far [fewer bank accounts and connections](https://gravam.com/blog/bank-account-rationalization). It's one of the highest-impact centralizations a treasury can make — and one of the ones with the most intercompany complexity to plan for.

## What it is

Without a payment factory, payments are _fragmented_: each entity runs its own payment processes, through its own banks, in its own formats, with its own controls. A payment factory replaces that with a single, standardized pipe. Entities submit payment requests; the factory applies consistent validation, approval and formatting; and payments go out through a consolidated, well-controlled [bank channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics). One process, one standard, one control model — for the whole group.

## Payments-on-behalf-of (POBO)

The payment factory's most powerful (and most complex) form is **POBO** — payments-on-behalf-of. Here a _central entity pays on behalf of the subsidiaries_, from its own accounts, rather than each subsidiary paying from theirs. The subsidiary still bears the cost, so an **intercompany payable** is booked, but the external cash leaves one central account.

> POBO's prize is account reduction: instead of every subsidiary needing external accounts in every currency and country it pays into, the centre's accounts do the paying. That can collapse hundreds of external accounts — but every payment now creates an intercompany entry that has to be tracked and settled. Plan the accounting before the cash.

## The "on behalf of" models

POBO is one of a family of "on behalf of" models, and the same idea runs in the other direction for collections. Each one collapses external accounts — and each one creates an intercompany entry that has to be settled.

| Model | What it centralizes | Intercompany entry created | The prize |
| --- | --- | --- | --- |
| **POBO** — payments on behalf of | Outgoing payments, from central accounts | An intercompany _payable_ | Collapse subsidiaries' external payment accounts |
| **COBO** — collections on behalf of | Incoming receipts, into central accounts | An intercompany _receivable_ | Collapse external collection accounts |

(You'll also see **ROBO**, receipts-on-behalf-of — the same idea as COBO under a different label.) The rule is the same for all of them: **the account footprint shrinks, but every flow now books an intercompany entry** — so the accounting and settlement have to be designed before the cash moves. These are the mechanics an [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) runs on.

## Why centralize payments

- **Cost.** One standardized process and consolidated banking beats dozens of local ones on fees and effort.
- **Control.** Uniform [approval and segregation-of-duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) across the group, instead of as many control models as there are entities.
- **STP.** Standardized formats and one channel mean [higher straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury) and less manual re-keying.
- **Fewer accounts.** Especially with POBO, a large reduction in external bank accounts — feeding directly into [rationalization](https://gravam.com/blog/bank-account-rationalization) and [visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility).
- **Visibility.** Payments flowing through one place are payments you can see and analyse.

## How it works

1. **Subsidiaries submit** payment requests to the factory (from their ERP or a portal).
2. **The factory validates** — checks data, applies rules, screens as required.
3. **Approval and control** are applied centrally and consistently.
4. **Formatting** into the [right message](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) for each bank.
5. **Single channel out** — payments go via the consolidated bank connectivity.
6. **Status and reconciliation** flow back and are matched.

## Payment factory vs shared service centre

These are related but different. A **shared service centre** is _organizational_ — a central team running a process (e.g. AP) for many entities. A **payment factory** is the _execution mechanism_ — the technology-enabled centralization of the payment step itself. A shared service centre often _uses_ a payment factory to actually make its payments. One is about who does the work; the other about how payments are technically routed and controlled.

## Where it sits with pooling and the in-house bank

A payment factory rarely stands alone. It's part of the same centralization arc as [cash pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) and the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank): pooling concentrates the cash, the in-house bank runs internal banking relationships, and the payment factory (often with POBO) centralizes the external payments. Together they turn a fragmented, entity-by-entity treasury into a centralized one — which is exactly why they're usually planned as one programme, not three.

## Payment factory pitfalls, from POBO to change

- **Underestimating intercompany accounting.** POBO generates intercompany payables on every payment; if the accounting and settlement aren't designed up front, you trade external mess for internal mess.
- **Over-centralizing.** Forcing every payment type and every country through the factory when local regulation, tax or payment methods genuinely require a local approach. Centralize what benefits; respect what can't.
- **Weak change management.** Subsidiaries lose local control and can resist; a payment factory is as much an operating-model change as a technical one.
- **Ignoring regulatory limits.** Some countries restrict POBO or cross-border payment centralization — check before you design.

Centralize payment execution through one standardized, well-controlled channel, use POBO where it earns its intercompany complexity, and plan it alongside pooling and the in-house bank — and a payment factory turns scattered, inconsistent, expensive payments into a single controlled flow. It's centralization with one of the best returns in treasury, provided the intercompany plumbing is designed as carefully as the cash.

***

_See also [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank), [payment hub vs payment factory](https://gravam.com/blog/payment-hub-vs-payment-factory) — the terms are not synonyms — and [intercompany netting](https://gravam.com/blog/intercompany-netting)._

## Questions this article answers

**Q: What is a payment factory?**

A payment factory is a centralized function and system setup that processes payments for many entities of a group through a single, standardized channel — instead of each subsidiary paying from its own accounts through its own banks in its own way. Payments are submitted to the factory, which validates, approves, formats and sends them through a consolidated bank connection. It standardizes payment controls and formats, improves straight-through processing, cuts costs and reduces the number of bank accounts and connections.

**Q: What is payments-on-behalf-of (POBO)?**

Payments-on-behalf-of (POBO) is a model, often part of a payment factory, where a central entity makes payments on behalf of the group's subsidiaries from its own accounts, rather than each subsidiary paying from theirs. The subsidiary still owes the cost, so an intercompany payable is recorded, but the actual cash leaves a central account. POBO reduces the number of external bank accounts dramatically, but it introduces intercompany accounting that has to be handled carefully.

**Q: What is the difference between a payment factory and a shared service centre?**

A shared service centre is an organizational concept — a central team that performs a process (like accounts payable) for many entities. A payment factory is the specific centralization of the payment execution step, usually enabled by treasury technology and standardized bank connectivity. A shared service centre often uses a payment factory to actually make the payments. One is about who does the work; the other is about how payments are technically executed and routed.

---

# Intercompany Netting: How It Works

Source: https://gravam.com/blog/intercompany-netting
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: Intercompany netting offsets what group entities owe each other so only net positions settle, cutting payments, FX and fees. Bilateral vs multilateral netting.

**Intercompany netting is a process that offsets the amounts group entities owe each other so only the net positions are settled — instead of every intercompany invoice being paid in full and separately.** A netting centre gathers all intercompany payables and receivables, works out who owes whom _on net_, and settles just those net amounts. The effect is dramatic: a web of dozens or hundreds of gross cross-border settlements collapses into one net figure per entity, cutting payment volumes, FX conversions, bank fees and float all at once. It's one of the cleanest efficiency wins in group treasury — and it lives or dies on the quality of the intercompany data behind it.

## What netting is

Groups are full of internal trade: entities buy from and sell to each other constantly, generating a dense web of intercompany payables and receivables. Settled _gross_, every one of those is a separate payment — often cross-border, often in different currencies, each with a conversion and a fee. Netting recognises that many of these offset, and settles only the difference.

## Why net

- **Fewer payments.** Many gross settlements become one net position per entity.
- **Less FX.** Offsetting exposures before converting means fewer, smaller currency conversions and less spread paid.
- **Lower fees.** Every payment avoided is a transaction fee avoided.
- **Less float and risk.** Less money in transit means less float cost and less settlement risk.

> Settling intercompany gross is paying a bank fee and an FX spread to move money the group already owes itself. Netting settles only what's genuinely left over after the group's internal claims cancel out.

## Bilateral vs multilateral

Two forms, very different in power:

|  | Bilateral | Multilateral |
| --- | --- | --- |
| **Offsets** | Between two entities | Across all entities at once |
| **A owes B 100, B owes A 60** | Settle net 40 | Same, but combined with every other pair |
| **Result** | One net figure per pair | One net position per entity vs the centre |
| **Best for** | Simple, few entities | A group with a dense many-to-many web |

**Multilateral** netting — run through a central netting centre — is where the real value is: instead of resolving each pair, every entity ends up with a single net position against the centre. A tangle of many-to-many flows becomes one number each.

## How a netting cycle works

Netting runs on a **cycle**, usually monthly:

1. **Collect** all intercompany invoices — payables and receivables — from every entity, by an agreed cut-off.
2. **Match and agree.** Reconcile the two sides of each intercompany balance and resolve disputes _before_ the run.
3. **Calculate net positions** — each entity's single net payable or receivable against the centre, converting to the netting currency at agreed rates.
4. **Settle the net** — each entity pays in or receives its net amount only.
5. **Repeat next cycle**, on a predictable calendar everyone plans around.

## Where it sits with the in-house bank and payment factory

Netting is part of the same [centralization](https://gravam.com/blog/what-is-an-in-house-bank) family as the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) and the [payment factory](https://gravam.com/blog/what-is-a-payment-factory). In fact a netting centre is often _run by_ the in-house bank, and the net settlements may flow through the payment infrastructure. Pooling concentrates external cash; netting concentrates _internal_ obligations; the payment factory centralizes external payments — different problems, one centralization programme.

## What breaks a netting cycle

- **Poor intercompany data.** The whole thing depends on both sides agreeing what they owe. Mismatched or unreconciled intercompany balances break the netting run — data quality is the number-one failure point.
- **Disputes handled in-cycle.** Trying to resolve disagreements during the settlement window instead of before the cut-off, jamming the cycle.
- **FX rate disagreements.** No agreed source or timing for the rates used to convert, so entities argue over their net figure. Fix the [rate policy](https://gravam.com/blog/market-data-in-treasury-systems) up front.
- **Regulatory blind spots.** Some countries restrict or prohibit netting for certain flows or currencies. Confirm what's permitted per jurisdiction before including it.
- **Undisciplined timing.** A cycle that slips or varies, so entities can't plan their cash around it.

Collect and _agree_ the intercompany balances, run a disciplined multilateral cycle on agreed rates, settle only the net, and respect local restrictions — and intercompany netting turns a costly web of internal gross payments into one clean net settlement per entity. It's the group refusing to pay banks to move money it already owes itself.

***

_See also [what is a payment factory](https://gravam.com/blog/what-is-a-payment-factory) and [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank)._

## Questions this article answers

**Q: What is intercompany netting?**

Intercompany netting is a process that offsets the amounts group entities owe each other so that only the net positions are settled, rather than every intercompany invoice being paid in full and separately. A netting centre collects all intercompany payables and receivables, calculates who owes whom on a net basis, and settles only those net amounts. It dramatically reduces the number and value of cross-border payments, the volume of currency conversions, and the associated bank fees and float costs.

**Q: What is the difference between bilateral and multilateral netting?**

Bilateral netting offsets amounts between two entities only — if A owes B 100 and B owes A 60, they settle a single net 40. Multilateral netting offsets across all entities at once through a central netting centre: each entity ends up with one net position against the centre rather than many bilateral settlements. Multilateral netting is far more powerful for a group because it collapses a web of many-to-many intercompany flows into one net figure per entity.

**Q: What are the benefits of a netting centre?**

A netting centre reduces the number of intercompany payments (from many gross settlements to one net position per entity), cuts foreign-exchange conversions and their spreads, lowers bank transaction fees, and reduces the float and settlement risk of money in transit. It also centralizes and standardizes intercompany settlement, improving control and visibility. The trade-off is that it depends on clean, agreed intercompany data and disciplined cycle timing to work.

---

# Bank Account Rationalization: How to Cut Account Sprawl

Source: https://gravam.com/blog/bank-account-rationalization
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-09-01
Summary: Bank account rationalization cuts the number of bank accounts to the minimum a company needs. Why sprawl is expensive, and how to run and govern it.

**Bank account rationalization is the disciplined process of reducing the number of bank accounts and [banking relationships](https://gravam.com/blog/bank-relationship-management) a company holds to the minimum it actually needs.** Over years, groups accumulate accounts — through acquisitions, local openings, and legacy arrangements no one remembers the reason for — until treasury is managing a sprawling web nobody designed. That sprawl is quietly expensive: hidden fees, trapped cash, weakened visibility, and a larger surface for error and fraud. Rationalization cuts the accounts that don't earn their place, leaving a structure that's cheaper, clearer and safer to run.

## What it is

Rationalization is not a one-off cleanup so much as a discipline: know every account you have, understand why each exists, and keep only those with a genuine purpose. The output is a deliberately _smaller, designed_ account structure — plus the governance to stop it re-growing.

## Why account sprawl happens

No one sets out to run two hundred accounts. It accumulates:

- **Acquisitions** arrive with their own banks and accounts, rarely fully integrated.
- **Local convenience** — an entity opens an account without telling the centre.
- **Legacy** — an account opened for a requirement that ended years ago, never closed.
- **No governance** — nothing controls opening, so the count only ever rises.

Each account was reasonable in isolation. The _aggregate_ is the problem — an accidental structure, not a chosen one.

## The cost of too many accounts

Sprawl is expensive in five ways at once:

- **Fees.** Every account carries maintenance and service charges — a lot of small numbers adding up.
- **Trapped cash.** Balances scattered across many accounts are cash you can't easily see or use; small idle balances everywhere become a large idle balance in total.
- **Weakened visibility.** Every account is another [statement feed](https://gravam.com/blog/how-to-achieve-global-cash-visibility) to gather, standardise and reconcile — and every one that isn't set up is a hole in the group cash number.
- **Control and fraud surface.** More accounts mean more mandates, more signatories, more [bank details to maintain](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) — a bigger surface for error and fraud.
- **Administrative drag.** Maintaining signatories, mandates and reviews across hundreds of accounts is pure, value-less effort.

> A hundred small idle balances aren't a hundred small problems. They're one large one — [trapped cash](https://gravam.com/blog/trapped-cash-and-cash-repatriation), invisible cash, and a control surface — wearing a hundred disguises.

## How to run a rationalization

1. **Inventory every account.** You cannot rationalize what you can't see. Build the complete list — entity, bank, currency, purpose. (This is the same [account inventory](https://gravam.com/blog/how-to-achieve-global-cash-visibility) that global cash visibility depends on.)
2. **Assess each account's purpose.** For every one, ask: what genuine need does this serve, and could another account serve it? Flag the ones with no real reason to exist.
3. **Close or consolidate.** Retire redundant accounts and consolidate activity into fewer, purposeful ones — carefully, respecting any legal, tax or regulatory requirement that a specific account genuinely meets.
4. **Govern going forward.** Put controls on account _opening and closing_ so the sprawl can't quietly rebuild.

## The link to visibility and pooling

Rationalization isn't only defensive. A smaller, deliberate account structure is the _foundation_ for the rest of cash management: it's far easier to achieve [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility) across ten purposeful accounts than two hundred accidental ones, and [pooling or concentration](https://gravam.com/blog/physical-vs-notional-cash-pooling) works best on a clean structure. Rationalize first, and every downstream optimisation gets easier.

## Governance stops the creep

The reason rationalization so often has to be _repeated_ is that the first cleanup fixed the symptom without fixing the cause. If nothing governs account opening, sprawl simply regrows. Effective governance means account opening (and closing) is a _controlled, centralised decision_ — treasury knows about and approves every new account — so the structure stays deliberate instead of drifting back into accident.

## Common account rationalization mistakes

- **Closing accounts still in use.** Retiring an account without confirming nothing still flows through it — a self-inflicted disruption. Verify before you close.
- **No governance.** Cleaning up once but leaving opening uncontrolled, so it re-sprawls within a few years.
- **Ignoring genuine local needs.** Closing an account a real regulatory, tax or operational requirement depends on. Rationalize the accidental, keep the necessary.
- **No inventory.** Trying to rationalize without first knowing every account that exists — so the unknown ones survive untouched.

Inventory everything, keep only accounts with a genuine purpose, close the rest carefully, and govern opening so it stays that way — and bank account rationalization turns an accidental, expensive web into a clean structure that's cheaper to run, easier to see, and safer to control. It's unglamorous work with outsized payoff, and it makes everything else in cash management work better.

***

_See also [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility), [physical vs notional pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) and [virtual account management structures](https://gravam.com/blog/virtual-account-management-structures) — the structural way to stop sprawl before it starts._

## Questions this article answers

**Q: What is bank account rationalization?**

Bank account rationalization is the disciplined process of reducing the number of bank accounts and banking relationships a company holds to the minimum it genuinely needs. Over time, groups accumulate accounts through acquisitions, local openings and legacy arrangements, many of which no longer serve a purpose. Rationalization inventories every account, assesses whether each earns its place, and closes or consolidates the ones that don't — simplifying the structure treasury has to manage, fund and control.

**Q: Why do companies have too many bank accounts?**

Account sprawl accumulates quietly: acquisitions bring their own banks and accounts, local entities open accounts for convenience without telling the centre, historical requirements that no longer apply leave accounts behind, and without governance over account opening, the number only ever grows. Each account seemed reasonable when opened, but the aggregate becomes an expensive, hard-to-see, hard-to-control web that no one deliberately designed.

**Q: What are the benefits of reducing bank accounts?**

Fewer accounts mean lower banking fees, less cash trapped in scattered balances, better cash visibility (fewer feeds to gather and reconcile), a smaller control and fraud surface, and less administrative effort maintaining mandates and signatories. A rationalized structure is also the foundation for effective cash concentration and pooling — it's much easier to sweep and see cash across ten purposeful accounts than across two hundred accidental ones.

---

# The 13-Week Cash Flow Forecast: A Practical Guide

Source: https://gravam.com/blog/13-week-cash-flow-forecast
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-30
Reviewed: 2026-07-30
Summary: A rolling, week-by-week projection of cash in and out over the next quarter, on a direct receipts-and-disbursements basis. Why 13 weeks, and how to build one.

**A 13-week cash flow forecast is a rolling, week-by-week projection of cash in and out over the next quarter, built on a direct receipts-and-disbursements basis.** It's the standard tool for short-term liquidity management — the one treasurers reach for whenever cash is tight, leverage is high, or a business is in or near restructuring — because it answers the only question that matters in those moments: _will we have enough cash, and if not, exactly which week does it break?_ Thirteen weeks is far enough ahead to act and near enough to forecast with confidence. Built well, it's the difference between seeing a cash crunch coming and being surprised by one.

## What it is

Thirteen weekly buckets. For each week: expected cash **receipts** minus expected cash **disbursements**, applied to the opening cash balance, giving a closing balance that becomes next week's opening. Do that across 13 weeks and you have a running picture of the cash line — and, crucially, of any week where it dips below zero or below your minimum. It's a [cash forecast](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting), not a position — about the future, anchored on today's [actual cash](https://gravam.com/blog/how-to-build-a-daily-cash-position).

> Want to build one now? Use the free [**13-week cash flow model**](https://gravam.com/tools/13-week-cash-flow-model): enter your opening balance and each week's receipts and payments, and it computes the net flow and running closing balance — flagging the week you'd go short. Export to CSV; nothing you enter leaves your browser.

## Why 13 weeks

Thirteen weeks is one quarter, and that's not arbitrary:

- **Long enough to act.** It surfaces the pressures genuinely coming — a tax or debt payment, payroll runs, a seasonal receivables dip — with enough lead time to arrange funding or defer outflows.
- **Short enough to trust.** A weekly, cash-specific forecast stays reasonably accurate over a quarter. Push it much further and receipts-and-disbursements detail dissolves into guesswork.

It's the sweet spot between visibility and reliability.

## Why the direct method

A 13-week forecast is almost always [direct](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) — built bottom-up from expected receipts and payments, not derived from projected accruals. That's deliberate: short-term liquidity is about _actual cash timing_, and the direct method captures exactly when money moves. An [indirect](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) forecast from the P&L tells you about profit; the 13-week forecast has to tell you about the bank balance in week 7, which is a different, harder, cash-timing question.

> A profitable company can still fail the 13-week test. Profit is an annual, accrual story; the 13-week forecast is a weekly, cash-timing one — and cash timing is what actually runs out.

## Why it matters — and when it's used

Every treasury benefits from one, but it becomes _essential_ when headroom is thin: high leverage, covenant pressure, a turnaround, or an outright restructuring. In those situations the 13-week forecast is often the single most-watched document in the company — lenders require it, the board lives by it, and decisions about payments, drawdowns and priorities are made against it week by week.

## Rolling and variance — where the value compounds

Two disciplines separate a useful 13-week forecast from a dead spreadsheet — and both are questions of the [forecast's operating model and ownership](https://gravam.com/blog/cash-forecast-operating-model-and-ownership), not of spreadsheet design:

- **Roll it forward.** Each week, drop the week that just happened and add a new week 13. It's a _rolling_ forecast, always looking a full quarter ahead — not a static one that shrinks to nothing.
- **Analyse variance.** Each week, compare what actually happened to what you forecast, line by line. The gaps tell you where your assumptions are wrong and make next week's forecast better — the same [forecast-accuracy discipline](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy) that turns forecasting from ritual into a tool that earns trust.

## How to build one

1. **Start from actual opening cash** — the current [position](https://gravam.com/blog/how-to-build-a-daily-cash-position), not a plan figure.
2. **Lay out 13 weekly columns.**
3. **Forecast receipts** — collections from customers (timed on realistic payment behaviour), plus other inflows.
4. **Forecast disbursements** — payroll, suppliers, tax, debt service, capex, timed to when cash actually leaves.
5. **Compute weekly net and running balance**, flagging any week below your minimum.
6. **Each week: record actuals, analyse variance, roll forward.**

## A worked miniature

The mechanics are easiest to see filled in. Here is a five-week slice of the model (€000) for a company that pays payroll fortnightly and has a quarterly VAT payment landing in week 3:

| €000 | W1 | W2 | W3 | W4 | W5 |
| --- | --- | --- | --- | --- | --- |
| **Opening balance** | 620 | 485 | 690 | 60 | 450 |
| Customer collections | 540 | 720 | 505 | 760 | 655 |
| Other inflows | 15 | — | — | 40 | — |
| **Total receipts** | 555 | 720 | 505 | 800 | 655 |
| Payroll | 310 | — | 310 | — | 310 |
| Suppliers | 380 | 430 | 395 | 410 | 385 |
| VAT / tax | — | — | 430 | — | — |
| Debt service | — | 85 | — | — | — |
| **Total payments** | 690 | 515 | 1,135 | 410 | 695 |
| **Net flow** | −135 | +205 | −630 | +390 | −40 |
| **Closing balance** | 485 | 690 | 60 | 450 | 410 |

Each week's net flow is receipts minus payments; each closing balance is the opening balance plus the net flow, and it becomes the next week's opening. The read that matters: week 3 closes at €60k — against, say, a €250k operating minimum — not because the business is weak (collections are steady all five weeks) but because fortnightly payroll and the quarterly VAT payment land in the same week. Seen in week 1, that's a timing problem with two weeks to solve it: pull collections forward, agree with a supplier or two to shift a payment into week 4, or pre-arrange a revolver drawdown. Seen on the morning of week 3, it's a crisis. That gap is the entire point of the tool.

To do this live with your own numbers — 13 weeks, computed net flow and running balance, short-week flagging — use the free [13-week cash flow model](https://gravam.com/tools/13-week-cash-flow-model).

## Where 13-week forecasts break down

- **Too much detail.** Trying to forecast every line to the penny — it's a decision tool, not the ledger. Focus on the material flows.
- **Not rolling it.** Building it once and letting it wither, so it stops looking a full quarter ahead.
- **No variance analysis.** Never checking forecast against actual, so the assumptions never improve and trust erodes.
- **Accrual thinking.** Forecasting profit timing instead of _cash_ timing, so the bank-balance line is wrong.
- **Stale opening balance.** Starting from an old or planned figure rather than today's real cash.

Build it on the direct method, anchor it on real opening cash, keep it rolling, and analyse variance every week — and the 13-week forecast becomes the early-warning system for liquidity that no profitable-looking P&L can give you. Everything above is about the model; almost none of it is about the weekly work of filling it in, which is where the hours actually go. That is the part I [pull apart as a worked example](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) of redesigning finance work around AI. It's where short-term cash management gets real.

***

_See also [the liquidity escalation framework](https://gravam.com/blog/liquidity-escalation-framework) for what to do when the forecast shows a breach, and [working capital and cash](https://gravam.com/blog/working-capital-and-cash) for the levers that move the weekly flows, and [SAP S/4HANA cash forecasting](https://gravam.com/blog/sap-s4hana-cash-forecasting) for how the same forecast is built inside SAP._

## Questions this article answers

**Q: What is a 13-week cash flow forecast?**

A 13-week cash flow forecast is a rolling, week-by-week projection of a company's cash receipts and disbursements over the next quarter (13 weeks), built on a direct basis — actual expected cash in and out, not accruals. It's the standard tool for short-term liquidity management because it shows precisely when cash could run short, week by week, far enough ahead to do something about it. It's especially common in tight-liquidity, high-leverage or restructuring situations.

**Q: Why is it 13 weeks specifically?**

Thirteen weeks is one quarter — long enough to see the liquidity pressures that are actually coming (a tax payment, a debt repayment, a seasonal dip) but short enough that a week-by-week direct forecast can be reasonably accurate. Beyond about a quarter, receipts-and-disbursements detail becomes guesswork; inside it, the weekly granularity gives you time to act. It's the sweet spot between visibility and reliability for short-term cash.

**Q: What is the difference between a 13-week forecast and a budget?**

A budget is an annual, accrual-based plan of profit and cost, usually by month. A 13-week cash flow forecast is a short-term, weekly, cash-based view of actual money moving in and out. The budget tells you whether the business is profitable over the year; the 13-week forecast tells you whether you'll have cash in the bank in week 7. They answer different questions, and a profitable company can still fail the 13-week test if cash timing goes wrong.

---

# How to Build a Daily Cash Position

Source: https://gravam.com/blog/how-to-build-a-daily-cash-position
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: A daily cash position is a consolidated view of the cash available today across every account and currency — prior-day vs intraday, actuals vs expected.

**A daily cash position is a consolidated view of the cash you actually have available today — across every bank account, currency and entity, as of this morning.** You build it from the opening balances on today's bank statements plus the day's known movements. It answers the treasurer's very first question — _how much cash do we have, where is it, and what will it do today?_ — and it's the anchor for every funding, investing and borrowing decision that follows. Get the position wrong and everything downstream, including the [forecast](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting), is built on sand.

## What a daily cash position is

The position is a _point-in-time snapshot of actual cash_, not a projection. It tells you, per account and rolled up to the group: what's the balance, what's already committed to move today, and what's therefore _available_ to use. It's distinct from the [cash flow forecast](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting), which is about the future — the position is the solid ground the forecast stands on.

## What goes into it

Two ingredients:

- **Opening balances** — the closing balance from yesterday's bank statement (tag `:62a:` in [MT940](https://gravam.com/blog/mt940-format-tags-explained)) for every account, which is this morning's starting point.
- **Today's known movements** — everything you already know will hit today: expected large receipts, scheduled outgoing payments, maturing deposits, loan drawdowns or repayments, and intercompany transfers.

Opening balance plus known movements gives you the **expected closing** and, more usefully, the **available** cash right now.

## Prior-day vs intraday

Most positions start from **prior-day** statements (yesterday's closing balances, delivered overnight as [MT940 or camt.053](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2)). That's enough to start the day. But cash moves _during_ the day, and a prior-day-only view goes stale by mid-morning. **Intraday** statements ([camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942)) update the picture through the day as credits and debits actually land — essential if you're managing tight balances, sweeping, or funding same-day payments.

> Rule of thumb: prior-day tells you where you _started_; intraday tells you where you _are_. If your day involves same-day funding decisions, prior-day alone isn't enough — you're managing this morning's cash with last night's numbers.

## Actuals vs expected

A good position separates two things clearly:

- **Actuals** — balances and transactions confirmed by the bank statement. Facts.
- **Expected** — movements you know are coming but the bank hasn't confirmed yet. Assumptions.

Keeping them visibly distinct is what lets a treasurer trust the number. Blending an unconfirmed €5m receipt into the "actual" balance is how a position lies to you — and how a same-day investment gets made against cash that didn't arrive.

## How to build one

The mechanics, in order:

1. **Collect** today's statements from _every_ bank account — this is the step that makes or breaks it.
2. **Normalize** balances into your reporting currency (at a consistent rate), keeping the original currency too.
3. **Layer on** the day's known movements, tagged as expected vs actual.
4. **Consolidate** by account → entity → currency → group.
5. **Present** the available position, with drill-down, before the day's decisions get made.

## By currency, entity and bank

A single group number hides what treasurers need. The position should slice **by currency** (you can't net USD against a trapped local currency), **by entity** (legal and tax reality constrains what's usable), and **by bank** (concentration and counterparty limits). Cash that exists but is [trapped or not truly available](https://gravam.com/blog/how-to-achieve-global-cash-visibility) shouldn't be counted as usable — showing only the group total invites exactly that mistake.

## What goes wrong at 8am

- **Missing accounts.** One bank's feed isn't set up, so an account is silently excluded and the position understates cash. Completeness is everything.
- **Stale statements.** Running the whole day on prior-day balances when intraday movement matters.
- **The eternal spreadsheet.** A manual workbook rebuilt by hand each morning — slow, fragile, and wrong the moment someone's on holiday. It is also the workflow I take through an [eight-dimension assessment](https://gravam.com/blog/how-to-find-enterprise-workflows-worth-redesigning-with-ai) and conclude is a connectivity and mapping problem rather than an AI one — which is exactly the kind of answer that assessment exists to produce. If you must build it in a workbook, the right formula patterns at least make it less brittle. (This is the pain [Delivery Sheet-style](https://gravam.com/blog/how-to-define-a-measurable-outcome) clarity and a real feed exist to remove.)
- **Blending expected into actual.** Treating unconfirmed flows as confirmed cash.
- **No cutoff discipline.** No agreed "as of" time, so different people quote different positions.

Build the position from a complete, timely statement feed, keep actuals and expected honest, slice it by currency and entity, and you give treasury the one number every other decision depends on. The next step up is making that view complete across the _entire_ group — that's [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility). And within the day, the position moves: running it as a live sequence against cut-offs is [intraday liquidity management](https://gravam.com/blog/intraday-liquidity-management).

***

_See also [cash positioning vs forecasting](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting) and [global cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility)._

## Questions this article answers

**Q: What is a daily cash position?**

A daily cash position is a consolidated view of the cash a company actually has available today, across all its bank accounts, currencies and entities, as of a point in time this morning. It combines the opening balances from bank statements with the day's known movements to answer the treasurer's first question: how much cash do we have, where is it, and what's it going to do today?

**Q: How do you build a daily cash position?**

Start from the opening balances on today's bank statements for every account, convert to a reporting currency, then layer on the day's known movements — expected receipts, scheduled payments, maturing investments, drawdowns. The result is the available position by account, currency and entity. The hard part isn't the arithmetic; it's getting a complete, timely statement feed from every bank so no account is missing or stale.

**Q: What is the difference between a cash position and a cash forecast?**

A cash position is about today — the actual cash you have right now, built from bank data. A cash forecast is about the future — the cash you expect to have over the coming days, weeks or months, built from projections. The position is the anchor the forecast starts from: a forecast that doesn't tie back to an accurate current position is guessing from a wrong starting point.

---

# Global Cash Visibility: Challenges and How to Achieve It

Source: https://gravam.com/blog/how-to-achieve-global-cash-visibility
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: Global cash visibility is seeing all the group's cash in one timely view. The challenges — banks, formats, time zones, manual accounts — and how to fix them.

**Global cash visibility is the ability to see all the group's cash — every account, entity, currency and bank — in one timely, consolidated view. The challenges of global cash visibility are what stands between a group and that view: many banks and statement formats, time zones and cut-offs, entities outside the main systems, manual and unknown accounts, and cash that can be seen but not moved.** It's mostly a _data problem_, not a dashboard problem: the barrier is almost never the screen at the end, it's getting a complete, standardized, on-time statement feed from every single bank account into one place. Treasurers who lack visibility rarely lack a reporting tool; they lack coverage. Solve coverage and the view solves itself.

## What it actually means

Three properties, all required:

- **Complete:** _every_ account is included. One missing feed and the group number is wrong, quietly.
- **Timely:** current enough to act on. Cash you learn about at month-end is cash you couldn't use.
- **Consolidated:** one view, rolled up across entity, currency and bank, with drill-down, not thirty spreadsheets in thirty inboxes.

Miss any one and you don't have visibility; you have a partial, late, or fragmented picture that _feels_ like visibility until it costs you.

## The challenges of global cash visibility

A large group is a visibility nightmare by default: dozens of banks across many countries, each with its own [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) and [statement format](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2); subsidiaries that report cash manually, weekly, in local currency; and accounts that get opened locally without treasury ever being told. The result is the familiar one: the centre emails the regions, waits, consolidates by hand, and the number is late and suspect the moment it's finished.

Taken apart, that default is eight separate obstacles. Each has a different owner and a different fix, which is why "we need better visibility" rarely turns into a project until it is broken down like this.

### Bank fragmentation

Every additional bank is another connection to build, another agreement and another point of failure. Groups rarely chose their bank landscape; it accumulated through acquisitions and local decisions. The fix is partly technical (a channel that reaches many banks) and partly structural: [fewer banks and fewer accounts](https://gravam.com/blog/bank-account-rationalization) is the cheapest visibility project there is.

### Format fragmentation

Two banks reporting the same closing balance will not report it the same way — different statement formats, different versions, different use of the same fields. Until statements are normalized to one format, consolidation is manual translation. Covered under Standardization below.

### Time zones and cut-offs

"Today's balance" is not one moment. Each bank closes its books and produces its end-of-day statement on its own schedule, in its own time zone, so a group position assembled at 9 a.m. in Europe mixes yesterday's close in one region with a day still in progress in another. A consolidated number needs a stated as-of time per account, or it is adding balances from different days.

### Entities outside the main ERP or TMS

Newly acquired companies, joint ventures and small subsidiaries often run on a different ERP, or on local accounting software, and are not connected to the group's treasury system. Their accounts are known but not fed, and their balances arrive by email. These entities are usually where the manual long tail lives.

### Intraday vs end-of-day data

A prior-day statement tells you where the account stood at last night's close. For most reporting that is enough; for same-day funding decisions it is not, and the gap is filled by intraday reports — [camt.052 or MT942](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) — which not every bank delivers for every account. Knowing which accounts have intraday data, and which only have yesterday's, is part of the visibility picture. Whether you need it at all is an [intraday liquidity](https://gravam.com/blog/intraday-liquidity-management) question.

### Manual and unknown accounts

Some accounts have no electronic feed at all: the balance is read from a banking portal and typed into a spreadsheet. Others are worse — opened locally and never reported to treasury. Both come down to the same missing control, a governed process for opening, changing and closing accounts (the internal side of [electronic bank account management](https://gravam.com/blog/electronic-bank-account-management-ebam)), so the account inventory is complete by construction rather than by annual survey.

### Trapped and restricted cash

Cash can be fully visible and still unusable — held in a country it cannot leave freely, pledged, or required as a minimum balance. A visibility figure that does not flag it overstates what the group can deploy. See "Visible ≠ available" below.

### Data quality

The feeds can all be in place and the total still be wrong: an account mapped to the wrong entity, a currency missing, a closed account still in the inventory, the same balance counted twice through two channels. Visibility is only as good as the [account and entity master data](https://gravam.com/blog/treasury-master-data-management) the statements are matched against.

> The reason you can't see the group's cash is almost never the dashboard. It's the twelve bank accounts nobody set up a feed for — and the three the centre doesn't even know exist.

## The foundation: complete statement coverage

Visibility is built one account at a time. Two prerequisites:

- **An account inventory.** A maintained list of _every_ bank account in the group: which entity, which bank, which currency. You cannot get a feed from an account you don't know exists, and unknown accounts are where trapped cash hides.
- **A feed from every account.** An automated daily [bank statement](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) from each one, through [host-to-host, SWIFT or EBICS](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), or an aggregator that fans many banks into one channel.

## Standardization

Every bank speaks a slightly different dialect. To consolidate, you normalize incoming statements to a **standard format** (increasingly [ISO 20022 camt.053/camt.052](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2)) so a balance means the same thing regardless of which bank sent it. Without standardization you're not consolidating; you're hand-reconciling formats forever.

## Visible ≠ available: trapped cash

Seeing cash isn't the same as being able to _use_ it. Regulatory restrictions, minimum local balances, tax on repatriation and currency controls mean some visible cash is **[trapped](https://gravam.com/blog/trapped-cash-and-cash-repatriation)**. Good visibility distinguishes _total_ cash from _available_ cash; otherwise the group total flatters you into decisions against money you can't actually move. (Turning scattered visible cash into usable, concentrated cash is what [pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) and an [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) are for.)

## How to get there

1. **Inventory** every account: the unglamorous, decisive first step.
2. **Connect** a statement feed from each, via the right channel per bank.
3. **Standardize** everything to one format.
4. **Monitor** that a statement actually arrives from every account, every day, and [alert on gaps](https://gravam.com/blog/interface-monitoring-and-reconciliation). A silently missing feed is an invisible hole in the number.
5. **Consolidate and present** by entity, currency and bank, separating total from available.

## The cash-visibility maturity model

Visibility isn't on/off; it's a ladder of coverage and timeliness. Locate yourself honestly by what you can actually _do_, not by whether you own a dashboard.

| Level | Coverage & timeliness | What treasury can (and can't) do |
| --- | --- | --- |
| **1. Fragmented** | Regions email balances; partial, late | Guess the group number; act on stale data |
| **2. Partial feeds** | Major banks fed automatically; a long tail still manual | See most cash; stay quietly blind to the tail |
| **3. Full coverage** | Every _known_ account fed daily, normalized to one format | Trust the total; build a real [daily position](https://gravam.com/blog/how-to-build-a-daily-cash-position) |
| **4. Monitored & live** | Coverage is monitored, gaps alerted, total vs available split | Run treasury on a live number and concentrate with confidence |

The jump that matters is **2 → 3** (closing the long tail of accounts) and then **3 → 4** (monitoring that the feeds keep arriving). Most teams over-invest in the view and under-invest in exactly those two steps.

## Where the visibility quietly breaks

- **Silent gaps.** An account stops reporting and no one notices, so the position is quietly wrong. Coverage must be _monitored_, not assumed.
- **Unknown accounts.** Locally opened accounts the centre never learns about: pure invisible cash.
- **Manual regional reporting.** Subsidiaries emailing balances weekly: late, error-prone, and never truly current.
- **Confusing visible with available.** Counting trapped cash as usable.
- **Buying the dashboard first.** Investing in a shiny reporting layer on top of incomplete feeds: a beautiful view of the wrong number.

Get complete coverage, standardize it, monitor it, and separate total from available — and global cash visibility stops being a month-end scramble and becomes a live view treasury can actually run on. Once you can _see_ the group's cash, the next questions are concentrating it ([pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling)) and building today's [daily position](https://gravam.com/blog/how-to-build-a-daily-cash-position) on top of it.

***

_See also [building a daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) and [physical vs notional pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling)._

## Questions this article answers

**Q: What is global cash visibility?**

Global cash visibility is the ability to see all of a group's cash, across every bank account, legal entity, currency and banking partner, in one consolidated, timely view. It means treasury at the centre can answer 'how much cash does the group have and where is it?' without emailing subsidiaries or waiting for month-end. It's the foundation for cash concentration, funding decisions and reducing idle balances.

**Q: What are the challenges of global cash visibility?**

The challenges of global cash visibility are data-coverage problems, not dashboard problems. The main ones are: bank fragmentation (many banks, each with its own connectivity channel); format fragmentation (the same balance reported in different statement formats); time zones and cut-offs, so 'today's balance' means a different moment per region; entities that sit outside the main ERP or TMS; end-of-day data where intraday is needed; accounts reported manually or not known to treasury at all; trapped or restricted cash that is visible but not usable; and data quality in the account and entity master data. Getting a complete, standardized, timely feed from every account into one place, with no account silently missing, is the real work. The reporting view is the easy last step.

**Q: How do you improve cash visibility across a group?**

Start with an account inventory so you know every account that should be reporting, then establish an automated statement feed from every one (via host-to-host, SWIFT or an aggregator), normalized to a standard format like camt.053. Monitor that a statement actually arrives from each account daily, and flag gaps. Visibility improves exactly as coverage and timeliness improve; the dashboard is the last 5%.

---

# How to Measure Cash Forecast Accuracy

Source: https://gravam.com/blog/how-to-measure-cash-forecast-accuracy
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-10-09
Reviewed: 2026-10-09
Summary: Measure cash forecast accuracy by comparing forecast to actual per period and category — variance, MAPE, bias, hit rate — so you know where it's reliable.

**Measure cash forecast accuracy by comparing each forecast to what actually happened, per period and category, using metrics like variance, MAPE, bias and hit rate — then break the results down by horizon and category.** That breakdown is the point: an overall accuracy number is nearly useless, but knowing that your one-week forecast is tight while your collections forecast is chronically optimistic tells you exactly what to trust and what to fix. A forecast you don't measure is one you can neither trust nor improve — which is why forecast accuracy sits among the core [treasury KPIs](https://gravam.com/blog/treasury-kpis-measuring-treasury-performance).

## Why measure it at all

Two reasons. First, **trust**: if you don't know how accurate the forecast is, you can't know when to act on it — and treasury making funding decisions on an unmeasured forecast is guessing with extra steps. Second, **improvement**: measurement points at the specific inputs that are wrong, so forecasting becomes a discipline that gets better over time instead of a monthly ritual nobody believes.

## The metrics

- **Forecast variance.** The basic building block: actual minus forecast, in currency and as a percentage, for each period. Positive and negative variances tell different stories.
- **MAPE (mean absolute percentage error).** The average of the _absolute_ percentage errors across periods. Because it uses absolute values, offsetting errors don't cancel out, so it measures real dispersion, not luck.
- **Bias.** The average _signed_ error — are you systematically over- or under-forecasting? Bias is the most fixable problem: a forecast that's consistently 10% high can be corrected; one that's randomly wrong is harder.
- **Hit rate.** How often the forecast lands within an agreed tolerance (say ±5%). An intuitive, decision-oriented view: "we're inside tolerance four weeks in five."

> Track bias and dispersion separately. A forecast can be _unbiased but noisy_ (right on average, wrong each time) or _biased but stable_ (consistently off by a predictable amount). They call for different fixes — the first needs better inputs, the second needs a correction factor and a root-cause hunt.

## Break it down by horizon and category

This is where measurement earns its keep. A single "our forecast is 88% accurate" hides everything useful. Break it down:

- **By horizon.** Accuracy should be high at one week and looser at three months. Measuring per horizon tells you _how far out_ the forecast is still decision-grade — and stops you judging a long-range view by short-range standards (or vice versa).
- **By category.** Split collections, supplier payments, payroll, tax, treasury flows. Almost always, one or two categories drive most of the error — often collections, because customer timing is hard. Now you know precisely where to invest.
- **By entity / region.** In a group, one entity's poor inputs can dominate the total. Per-entity accuracy points at who needs help.

All of this assumes you kept the forecast you are scoring. Systems that hold only the current state of each flow need that switched on deliberately; in SAP it is the snapshot function, covered in [SAP S/4HANA cash forecasting, end to end](https://gravam.com/blog/sap-s4hana-cash-forecasting).

## Why cash forecast accuracy is poor: the usual causes

When the numbers come back and accuracy is poor, the cause is rarely the model. It is usually one of these, and the breakdown above is how you tell which:

- **Collections forecast on due dates.** Customers pay on their own habits, not on your terms. A forecast that assumes the due date is optimistic by construction, and it shows as a steady bias in the collections category.
- **Inputs nobody owns.** Business units send their numbers late, or send last month's again. The error concentrates in one or two entities — which is what the per-entity view is for.
- **Right amount, wrong week.** Payment runs, payroll, tax and interest fall on known dates, but the forecast spreads them evenly. Accuracy looks fine by month and poor by week.
- **Flows that never reach the forecast.** A tax settlement, a dividend, a capital purchase, an intercompany loan: one-offs that live in someone's inbox until they hit the bank.
- **Actuals that are not actual yet.** Unposted statements and unreconciled items make the comparison wrong on the "actual" side, and the forecast takes the blame.
- **No loop.** The forecast is never scored against what happened, so the same miss repeats every cycle.

Every one of them is an input or an ownership problem, not a formula problem — which is why the fix sits in the [forecast operating model](https://gravam.com/blog/cash-forecast-operating-model-and-ownership) and why a more sophisticated method on the same inputs produces the same error with more decimals.

## Turning measurement into improvement

Measurement is only worth it if it changes something:

1. **Find the biggest contributor.** Which horizon, category or entity accounts for most of the error?
2. **Diagnose it.** Bias (fixable with a correction and a root cause) or noise (fix the input data or process)?
3. **Fix the input, not the number.** If collections are always optimistic, the fix is better collections data or assumptions — not a fudge on the total.
4. **Re-measure.** Confirm the change actually improved accuracy, and move to the next contributor.

Run that loop for a few cycles and the forecast quietly becomes something treasury can act on.

## Accuracy metrics that hide the real error

- **Only tracking a headline number.** No horizon or category breakdown, so you know you're wrong but not _where_.
- **Chasing a target percentage.** Fixating on "95% accurate" instead of "unbiased, improving, and good enough at each horizon for the decisions it drives."
- **Not closing the loop.** Measuring accuracy and filing the report, without feeding it back into better inputs.
- **Ignoring bias.** Living with a forecast that's systematically off because the average error "looks small" — when a consistent bias is the easiest thing to correct.

Measure against actuals, break it down by horizon and category, fix the inputs behind the biggest errors, and your forecast stops being a number people quietly distrust. Build the forecast you're measuring in the free [13-Week Cash Flow Model](https://gravam.com/tools/13-week-cash-flow-model). And accuracy is a process, not just a metric: the [forecast operating model and ownership](https://gravam.com/blog/cash-forecast-operating-model-and-ownership) is what actually makes the numbers improve over time.

***

_See also [cash positioning vs forecasting](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting) and [direct vs indirect forecasting](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting)._

## Questions this article answers

**Q: How do you measure cash flow forecast accuracy?**

Compare each forecast to what actually happened, per period and category. Common metrics are forecast variance (actual minus forecast, in currency and %), MAPE (mean absolute percentage error) across periods, bias (whether you systematically over- or under-forecast), and hit rate (how often you land within a tolerance). Track them over time and, crucially, break them down by horizon and category so you know exactly where the forecast is reliable.

**Q: What is a good cash forecast accuracy?**

There's no universal number — it depends on horizon and business. Short-horizon direct forecasts should be quite accurate (low single-digit percentage error); longer horizons will be looser by nature. Rather than chase a target percentage, aim for a forecast that is unbiased, improving over time, and accurate enough at each horizon to support the decisions it drives.

**Q: Why measure cash forecast accuracy?**

Because a forecast you don't measure is a forecast you can't trust or improve. Measuring accuracy tells you which horizons and categories are reliable (so you know when to act on the forecast), surfaces systematic bias, and points to the specific inputs — a particular entity, a category like collections — that need fixing. It turns forecasting from a ritual into a discipline that gets better.

**Q: Why is cash forecast accuracy poor?**

Rarely because of the model. The usual causes are inputs and ownership: collections forecast on due dates rather than on how customers actually pay, numbers from business units that arrive late or unchanged, known payments spread evenly instead of placed on their dates, one-off flows such as tax or dividends that never reach the forecast, actuals that are not final because statements are unposted, and no comparison of forecast with actual, so the same miss repeats. Breaking accuracy down by category, entity and horizon shows which one it is.

---

# Direct vs Indirect Cash Flow Forecasting for Treasury

Source: https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: Direct forecasting builds cash bottom-up from expected receipts and payments; indirect derives it from projected financials. Which to use, over what horizon.

**Direct cash flow forecasting builds cash bottom-up from expected receipts and payments; indirect forecasting derives it top-down from projected financial statements.** Direct is accurate over short horizons and built for operational liquidity decisions — it works from concrete flows like collections, payroll and debt service. Indirect suits longer-term strategic planning — it starts from projected profit and balance-sheet movements, trading day-to-day precision for reach. Most treasuries use both, at different horizons.

## Direct forecasting: bottom-up

Direct forecasting adds up the actual cash movements you expect: receipts from customers, payments to suppliers, payroll, tax, interest, dividends, treasury flows. Because it's built from concrete, near-term items, it's **accurate over short horizons** and speaks the language of operational treasury — it tells you when a gap appears next week and how big it is, so you can fund or invest with confidence.

Its limits are effort and reach: forecasting individual flows gets impractical the further out you go, and its quality depends directly on the source data (AR, AP, payroll — the open items an ERP-native build such as [SAP S/4HANA cash forecasting](https://gravam.com/blog/sap-s4hana-cash-forecasting) reads straight from the ledger) and the discipline of the people feeding it — which is why the [operating model and ownership behind the forecast](https://gravam.com/blog/cash-forecast-operating-model-and-ownership) matter as much as the method.

## Indirect forecasting: top-down

Indirect forecasting starts from the **projected financials** — the forecast P&L and balance sheet — and works cash out from them (profit, adjusted for non-cash items and changes in [working capital](https://gravam.com/blog/working-capital-and-cash), debt and capital). It's the natural method for **longer horizons and strategic questions**: funding needs over the year, covenant headroom, the cash impact of the plan. It's less precise about _timing_ — it won't tell you Thursday's position — but it reaches where a direct forecast can't.

## Comparison

|  | Direct | Indirect |
| --- | --- | --- |
| **Built from** | Actual expected receipts & payments | Projected P&L and balance sheet |
| **Direction** | Bottom-up | Top-down |
| **Horizon** | Short (days to weeks/months) | Medium to long (quarters+) |
| **Accuracy / timing** | High, precise timing | Lower timing precision |
| **Best for** | Operational liquidity, funding decisions | Strategic planning, funding, covenants |
| **Effort** | High per period, data-dependent | Leverages existing financial plans |

## Which method for which horizon

- **Short term (days–weeks):** direct. You need timing and accuracy to manage liquidity and funding.
- **Medium to long term (quarters–year+):** indirect. Forecasting individual flows isn't feasible; derive cash from the financial plan.
- **The overlap:** in the medium term the two coexist, and their views should broadly reconcile — a large gap between them is a signal worth investigating.

## Combining them

The strongest treasury forecasting runs both and joins them up: the **direct** short-term forecast anchors to today's [actual cash position](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting) and drives operations; the **indirect** long-term forecast frames funding and strategy; and they meet in the middle, where a reconciliation between the bottom-up and top-down views exposes errors in either. Comparing what you forecast against what actually landed — [forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy) — is how you learn which horizons and categories to trust.

## Mismatching forecast method and horizon

- **Using one method for everything.** Forcing direct forecasting out to a year (impractical, low quality) or judging short-term liquidity on an indirect view (no timing).
- **No reconciliation.** Running direct and indirect in isolation, so nobody notices when they disagree.
- **Ignoring data quality.** A direct forecast is only as good as the AR/AP/payroll data feeding it; garbage in, confident-looking garbage out.

Match the method to the horizon, reconcile them where they overlap, and measure accuracy so you know where the forecast earns trust.

***

_See also [cash positioning vs forecasting](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting), [measuring forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy), and what this process looks like redesigned around AI: [the cash-forecasting teardown](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting)._

## Questions this article answers

**Q: What is the difference between direct and indirect cash flow forecasting?**

Direct forecasting builds the cash flow bottom-up from actual expected receipts and payments — collections, disbursements, payroll, tax, debt service — which makes it accurate over short horizons and ideal for operational liquidity decisions. Indirect forecasting derives cash from projected financial statements (P&L and balance sheet movements), which suits longer-term, strategic planning but is less precise for day-to-day cash. Treasury typically uses direct for the short term and indirect for the long term.

**Q: Which cash flow forecasting method is more accurate?**

Direct is more accurate over short horizons because it's built from concrete expected flows. Indirect is better suited to long horizons where forecasting individual flows isn't feasible, but it's less precise about timing. Accuracy is really a function of matching the method to the horizon — direct for weeks, indirect for quarters and beyond.

**Q: Should treasury use direct or indirect forecasting?**

Usually both, at different horizons. Use direct forecasting for short-term operational cash and liquidity management, where timing and accuracy matter. Use indirect forecasting for medium- and long-term strategic planning, funding and covenant analysis. The two views should reconcile at the boundary, and the short-term direct forecast anchors to today's actual position.

---

# What Is an In-House Bank? A Treasury Guide

Source: https://gravam.com/blog/what-is-an-in-house-bank
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-09-02
Summary: An in-house bank is a central treasury acting as a bank for the group — internal accounts, intercompany funding, on-behalf-of payments and netting.

**An in-house bank (IHB) is a [centralized treasury function](https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized) that acts as a bank for a group's operating entities** — giving them internal accounts, intercompany loans and deposits, payments and collections on behalf of, netting and internal FX. Instead of every subsidiary running its own external bank relationships, treasury runs an internal bank: the group's cash concentrates centrally, external accounts and fees shrink, and control and standardization move to one place.

## What an in-house bank does

Think of treasury opening an account for each subsidiary — not at an external bank, but _inside_ the group. Each entity has an internal current account with the IHB; its surplus cash is a deposit with the IHB, its funding need is a loan from the IHB, and much of what it used to do through external banks now flows through the internal bank. The group's real external cash concentrates (usually via [physical pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling)), while entities transact against their internal positions.

## Core capabilities

- **Internal accounts.** Each entity holds one or more internal current accounts with the IHB, replacing external operating accounts.
- **Intercompany lending and deposits.** Surplus and deficit are managed as intercompany loans/deposits with the IHB, priced and documented at arm's length.
- **Payments on behalf of (POBO).** The IHB makes external payments _for_ the entities from central accounts, so subsidiaries need far fewer external accounts.
- **Collections on behalf of (COBO).** Similarly, incoming funds are collected centrally and credited to the entity's internal account.
- **Netting.** Intercompany obligations are [netted](https://gravam.com/blog/intercompany-netting) so only net positions settle externally, cutting payment volume and FX.
- **Internal FX.** Currency needs are offset internally where possible, reducing external FX trades.

## The benefits

- **[Cash concentration](https://gravam.com/blog/cash-concentration-sweeping-and-zba) and liquidity efficiency** — the group's cash sits centrally and is used across entities instead of [trapped in local accounts](https://gravam.com/blog/trapped-cash-and-cash-repatriation).
- **Fewer external accounts and lower fees** — POBO/COBO collapse many subsidiary accounts into a few central ones.
- **Reduced external FX** — internal offsetting and netting cut the volume of external currency trades.
- **Centralized control and standardization** — one set of processes, controls and visibility instead of dozens.
- **Stronger governance** — payments and funding run through a controlled central function.

## In-house bank vs payment factory

They're related and often confused. A **payment factory** centralizes _payment execution_ — one controlled, standardized place that makes the group's outgoing payments. An **in-house bank** is broader: it maintains internal accounts, does intercompany lending, netting and internal FX, and usually _includes_ POBO/COBO. In practice a payment factory is often one capability within a fuller in-house-bank structure — and the [payment hub versus payment factory](https://gravam.com/blog/payment-hub-vs-payment-factory) distinction is a third axis on top of it. In SAP this structure is [In-House Cash](https://gravam.com/blog/sap-in-house-cash-ihc).

> POBO and COBO — payments and collections "on behalf of" — are what let an in-house bank shrink the external account footprint dramatically. They also carry legal and regulatory nuance (who is the account holder, how the entity's ledger reflects it), so they're designed carefully, not switched on casually.

## How an in-house bank gets built

An IHB is assembled in sequence, not switched on. Each step depends on the one before it — and skipping a prerequisite is exactly where these programmes come unstuck.

| Step | What you establish | Prerequisite before it |
| --- | --- | --- |
| **1. Concentrate the cash** | [Physical pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) to a header account | Account inventory; bank and jurisdiction support |
| **2. Stand up internal accounts** | One (or more) internal current account per entity | A treasury system that can run internal ledgers |
| **3. Add POBO / COBO** | Central [payments and collections on behalf of](https://gravam.com/blog/what-is-a-payment-factory) | Tax & legal design; intercompany accounting |
| **4. Netting & internal FX** | Net intercompany obligations; offset currency internally | An intercompany framework, arm's-length pricing |
| **5. Govern & reconcile** | Controls, clear ownership, sub-ledger-to-GL reconciliation | Clean master data and named owners |

Read top to bottom, the sequence is also a dependency chain: no pooling, no meaningful internal accounts; no tax/legal design, no safe POBO/COBO. Most failed in-house-bank programmes tried to start at step 3.

## Prerequisites and what usually goes wrong

An in-house bank is powerful but not lightweight. It needs:

- **A capable treasury system** to run internal accounts, intercompany positions and POBO/COBO — this is not a spreadsheet exercise.
- **An intercompany framework** — arm's-length pricing, documentation, and handling of withholding tax and thin-capitalization rules.
- **Tax and legal design** — POBO/COBO, internal accounts and cross-border flows all have tax and regulatory implications that vary by country.
- **Clean master data and clear ownership** — internal accounts, entities and mappings must be right, and someone must own them.

Where it goes wrong is almost always the same: treating it as a treasury-only initiative and underestimating the intercompany, tax and system requirements. Designed properly — with tax and legal in the room and a system that can actually run it — an in-house bank is one of the highest-leverage structures in corporate treasury. Designed casually, it becomes a standing question from your auditors and tax advisors.

***

_See also [physical vs notional cash pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) and [cash positioning vs forecasting](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting)._

## Questions this article answers

**Q: What is an in-house bank?**

An in-house bank (IHB) is a centralized treasury structure that provides banking services to a group's operating entities — internal current accounts, intercompany loans and deposits, payments and collections on behalf of the entities, netting, and internal FX. It lets treasury concentrate the group's cash, reduce the number of external bank accounts and fees, and centralize control, effectively acting as an internal bank for the subsidiaries.

**Q: What is the difference between an in-house bank and a payment factory?**

A payment factory centralizes the execution of payments — one place that makes outgoing payments for the group in a controlled, standardized way. An in-house bank is broader: it maintains internal accounts for entities, does intercompany lending and deposits, netting and internal FX, and typically includes payments/collections on behalf of. A payment factory is often one capability within an in-house bank.

**Q: What are the benefits of an in-house bank?**

Concentrated cash and better liquidity use, fewer external bank accounts and lower banking fees, centralized control and standardized processes, reduced external FX through internal offsetting and netting, and stronger visibility and governance. The trade-off is complexity: internal accounting, intercompany and tax frameworks, and a capable treasury system to run it.

---

# Physical vs Notional Cash Pooling: How to Choose

Source: https://gravam.com/blog/physical-vs-notional-cash-pooling
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: Physical pooling moves funds to concentrate cash; notional pooling offsets balances for interest without moving money. The trade-offs, and when to use each.

**Physical cash pooling moves funds between accounts to concentrate cash in one place; notional pooling offsets account balances to optimize interest without moving any money.** Physical pooling gives you real, consolidated cash and tight control — at the cost of intercompany positions and daily movements. Notional pooling preserves each entity's balance and autonomy — at the cost of depending heavily on your bank's support and on legal and tax treatment that varies by jurisdiction. The right choice depends on your structure, your banks, and your appetite for intercompany and cross-border complexity.

## Physical cash pooling: concentration

In a physical pool (also called cash concentration), balances are [physically swept between participating accounts](https://gravam.com/blog/cash-concentration-sweeping-and-zba) and a central **header account** so the group's cash sits in one place, ready to fund, invest or offset borrowing. Because money actually moves between legal entities, each sweep creates an **intercompany loan** that must be tracked, priced and documented.

Physical pooling comes in two main flavours:

- **Zero balancing** — every participating account is swept to zero each day; all cash concentrates in the header. Maximum concentration, but local accounts start each day empty.
- **Target balancing** — accounts are swept to a defined target (not zero), leaving a working balance in the local account. Less concentration, but operationally gentler where entities need a buffer.

## Notional cash pooling: offset

In a notional pool, **no cash moves**. Each account keeps its own balance, and the bank simply _offsets_ the credit and debit balances across the pool to calculate net interest — so a group can effectively use surplus in one account against an overdraft in another without an intercompany transfer. Entity balances and autonomy are preserved, and there are no intercompany loans to administer.

The catch: notional pooling depends entirely on the bank offering it and on the **legal right of set-off** holding up in each jurisdiction. And the bank's willingness depends on whether its own regulator lets it count the pool as one net balance rather than as every account gross, so availability is not guaranteed.

## What the bank-capital rules actually say

"Regulatory capital treatment" is usually cited without a reference. There are two separate rules behind it, and both are in the Basel Framework.

**The leverage ratio.** The leverage ratio exposure measure "generally follows gross accounting values" (LEV30.1), and banks may not net assets and liabilities unless the framework says otherwise (LEV30.2). Cash pooling gets its own paragraph, [LEV30.12](https://www.bis.org/committees/bcbs/basel-framework/standard/lev/30/inforce/2023-01-01/published/2020-03-27), which does not use the words "physical" or "notional" but draws the line by whether balances are transferred:

- Where the arrangement transfers the participating balances into a single account **at least daily**, the individual accounts are treated as extinguished and the single balance is the exposure — provided the bank is not liable for the balances individually after the transfer.
- Where the transfer **does not happen daily**, the bank may still use a single balance, but only if every condition is met: the arrangement provides a single account into which all balances can be transferred; the bank has a legally enforceable right to make that transfer and can exercise it at any time; its supervisor does not consider the transfer frequency inadequate; there are no maturity mismatches between the balances, or all are overnight or on demand; and interest or fees are charged on the combined balance.
- If those conditions are not met, each account's balance goes into the exposure measure separately — a credit balance in one entity does not reduce a debit balance in another.

That is the mechanism. A pool whose balances are transferred less often than daily can still be netted under the second limb; the texts do not say that a pool which never transfers balances qualifies. Otherwise it is carried gross, and gross means the bank holds capital against the overdrafts as if the offsetting deposits were not there. The EU has written the same test into law: Article 429b(2) and (3) of the Capital Requirements Regulation, inserted by [Regulation (EU) 2019/876](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32019R0876), sets conditions for cash pooling that include daily transfer into a single account or, failing that, a legally enforceable right of set-off through such a transfer at any time, no maturity mismatches, interest on the combined balance, and the competent authority's view that the transfer frequency is adequate.

**Risk-weighted capital.** Separately, a bank may calculate capital on the net of loans and deposits only under the on-balance-sheet netting conditions of [CRE22.68](https://www.bis.org/committees/bcbs/basel-framework/standard/cre/22/inforce/2023-01-01/published/2020-11-26): a well-founded legal basis that the netting agreement is enforceable in each relevant jurisdiction whether or not the counterparty is insolvent, the ability to identify at any time the assets and liabilities with the same counterparty that are covered, and monitoring of roll-off risk and of the exposures on a net basis. CRE22.9 adds that the documentation must be binding and legally enforceable in all relevant jurisdictions, backed by sufficient legal review.

What is and is not established here. The texts above establish that net treatment of a pool is conditional, and that legal enforceability in every relevant jurisdiction is one of the conditions — which is why a multi-country, multi-entity pool is the hard case and why banks ask for cross-guarantees and set-off rights. They do not establish how any particular national regulator applies the conditions, how a netting rule written for "the same counterparty" is satisfied across several legal entities, or that any named bank has restricted or withdrawn the product for this reason. Banks' appetite does vary; ask yours, in writing, for each jurisdiction in the structure.

## Comparison

|  | Physical pooling | Notional pooling |
| --- | --- | --- |
| **Does cash move?** | Yes — swept to a header account | No — balances offset only |
| **Concentration** | Real, consolidated cash | Virtual; cash stays in accounts |
| **Intercompany** | Creates intercompany loans | None |
| **Entity autonomy** | Reduced (accounts swept) | Preserved |
| **Admin burden** | Intercompany tracking, pricing, docs | Lower operationally |
| **Dependence** | Works broadly | Heavily bank / legal / tax dependent |
| **Typical use** | Concentrate to fund/invest/offset debt | Optimize interest, keep balances local |

## The legal and tax layer (where the real decision lives)

The operational comparison above is the easy half. The choice usually turns on the _legal and tax_ dimension — the part that needs your tax and legal advisers in the room, not just treasury.

| Dimension | Physical pooling | Notional pooling |
| --- | --- | --- |
| **Ownership of cash** | Transfers to the header (intercompany loan) | Stays with each entity |
| **Interest treatment** | On the intercompany loans, priced arm's-length | Bank offsets balances to compute net interest |
| **Cross-guarantees** | Usually not required | Bank typically requires cross-guarantees / rights of set-off |
| **Main tax exposure** | Withholding tax and thin-cap on IC interest | Enforceability of set-off; "deemed loan" risk in some countries |
| **Bank / jurisdiction availability** | Broadly available | Varies by bank; net capital treatment is conditional (LEV30.12) |

The pattern: physical pooling pushes the complexity into _intercompany_ (loans, pricing, docs); notional pushes it into _bank and legal dependence_ (set-off, guarantees, availability). Choose the complexity you can actually administer.

## When to use which

- **Physical** when you want genuine cash concentration — to fund centrally, invest surplus, or reduce gross external borrowing — and you can administer intercompany positions. It's the backbone of most in-house-bank structures.
- **Notional** when you want interest optimization without disturbing entity balances or creating intercompany loans, _and_ your bank supports it in your jurisdictions with acceptable tax and legal treatment.
- **Both** — many groups run physical concentration domestically and notional (or none) cross-border, shaped by what each bank and jurisdiction allows.

## Cash pooling tax, legal and intercompany traps

- **Underestimating intercompany.** Physical pooling silently generates intercompany loans; without proper tracking, pricing (arm's length) and documentation, you create a tax and audit problem.
- **Assuming notional is available.** Structures designed around cross-border notional pooling that the bank cannot, or will no longer, treat as a net exposure — check availability and legal set-off _before_ you design around it.
- **Tax and legal blind spots.** Withholding tax on intercompany interest, thin-capitalization rules, and the enforceability of set-off vary by country; pooling structures need tax and legal review, not just a treasury design.
- **Cross-border and currency complexity.** Multicurrency and cross-border pooling add FX, regulatory and repatriation constraints that a single-country design ignores.

Get the structure, the intercompany framework and the tax/legal review right up front, and pooling becomes a quiet, powerful liquidity tool. Skip them, and it becomes the thing your auditors and tax advisors ask about for years.

***

_See also [cash positioning vs forecasting](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting) and [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank)._

## Primary sources

The bank-capital statements are verified against the Basel Framework (LEV30.1, LEV30.2 and LEV30.12; CRE22.9, CRE22.68 and CRE22.69, versions effective 1 January 2023) and Article 429b of the EU Capital Requirements Regulation as inserted by Regulation (EU) 2019/876. How each national regulator applies them, which banks have changed their notional pooling offering and why, and the tax and set-off law of any particular country are not verified here.

- Basel Committee on Banking Supervision — Basel Framework, LEV30 Exposure measurement (effective 1 January 2023) — accessed 2026-10-04 — https://www.bis.org/committees/bcbs/basel-framework/standard/lev/30/inforce/2023-01-01/published/2020-03-27
- Basel Committee on Banking Supervision — Basel Framework, CRE22 Standardised approach: credit risk mitigation (effective 1 January 2023) — accessed 2026-10-04 — https://www.bis.org/committees/bcbs/basel-framework/standard/cre/22/inforce/2023-01-01/published/2020-11-26
- EUR-Lex — Regulation (EU) 2019/876 of the European Parliament and of the Council of 20 May 2019 amending Regulation (EU) No 575/2013 (Article 429b, cash pooling arrangements) — accessed 2026-10-04 — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32019R0876

## Questions this article answers

**Q: What is the difference between physical and notional cash pooling?**

Physical pooling physically transfers funds between accounts to concentrate cash in a single header account — the money actually moves, creating intercompany positions. Notional pooling leaves each account's balance where it is and offsets the balances only for the purpose of calculating interest, so no cash moves and entity balances are preserved. Physical gives real concentration and control; notional preserves autonomy but depends heavily on bank, legal and tax support.

**Q: What is zero balancing vs target balancing?**

Zero balancing and target balancing are both forms of physical pooling. Zero balancing sweeps each participating account to zero every day, moving all cash to the header account. Target balancing sweeps to a defined target balance instead of zero, leaving a set amount in the local account. Zero balancing maximizes concentration; target balancing leaves working balances where they're needed.

**Q: Is notional pooling still allowed?**

Whether notional pooling is available depends on jurisdiction and bank. Notional pooling relies on the bank offsetting balances and on the legal right of set-off, and a bank can only treat the pool as one net balance for capital purposes if regulatory conditions are met. Under the Basel Framework's leverage ratio rules (LEV30.12), a cash pool whose balances are not transferred into a single account at least daily counts as a single balance only if, among other conditions, the bank has a legally enforceable right to make that transfer at any time, there are no maturity mismatches and interest is charged on the combined balance; otherwise each account is counted gross, which makes the pool more capital-intensive for the bank. Availability therefore varies. It must be checked with your bank and advisors for your specific structure — don't assume it's available everywhere.

---

# Cash Positioning vs Cash Flow Forecasting: The Difference

Source: https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting
Topic: Corporate Cash & Liquidity Management — https://gravam.com/topics/cash-and-liquidity-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: Cash positioning tells you the cash you have now; forecasting projects what you'll have. Two different jobs — and why confusing them costs treasury teams.

**Cash positioning tells you the cash you have right now; cash flow forecasting projects the cash you'll have.** Positioning is a short-horizon, high-accuracy, operational job — it drives today's funding, investing and covering decisions. Forecasting is a longer-horizon, lower-certainty, planning job — it drives funding strategy, liquidity buffers and risk decisions. They use different data and serve different decisions, and treating them as one thing is a common, costly mistake.

> **Figure — Cash position and cash forecast**
>
> On the left, a sheet marked today with one firm figure and a tick, labelled cash position, confirmed. An arrow leads to a chart of four weeks — the first bar solid, the next three dashed outlines — labelled cash forecast, estimated.
>
> The position is what you have now and can confirm; the forecast is what you expect, and it gets less certain the further out it looks.

## The core difference

|  | Cash positioning | Cash flow forecasting |
| --- | --- | --- |
| **Question** | How much cash do we have _now_? | How much cash _will_ we have? |
| **Horizon** | Today to a few days | Weeks to months (or longer) |
| **Accuracy** | Near-certain (confirmed data) | Estimated (improves as it nears) |
| **Data** | Confirmed balances + known same-day flows | Projected receipts and payments |
| **Purpose** | Operational: fund, invest, cover today | Planning: funding, buffers, risk |
| **Cadence** | Daily (often intraday) | Rolling; daily/weekly/monthly buckets |

## Cash positioning: the daily discipline

Positioning is the morning job: pull confirmed balances from every bank, add the flows you _know_ will settle today (a maturing deposit, a scheduled large payment), and arrive at the actual available cash by account, currency and entity. Because the decisions it drives are immediate — sweep surplus to where it earns, cover a shortfall before cut-off, release or hold a payment run — it lives or dies on **accuracy and timeliness**, not on how far ahead it looks.

> A good position is built from _confirmed_ data. The moment you're estimating today's number, you're forecasting, not positioning — and you shouldn't be making same-day funding decisions on an estimate.

## Cash flow forecasting: the planning view

Forecasting projects future cash from expected receipts and payments — collections from AR, disbursements from AP, payroll, tax, debt service, treasury flows — across a horizon and granularity you choose. Its value is in the decisions it enables _before_ they're forced: how much to borrow or invest, how big a liquidity buffer to hold, when funding gaps appear, what FX you'll need. It is inherently uncertain, and that's fine — a forecast's job is to be _useful and improving_, not perfect.

## Why teams confuse them — and what it costs

Because both are "cash numbers," teams blur them, and each mistake has a cost:

- **Making same-day decisions on forecast data** — funding or sweeping on an estimate instead of a confirmed position, and getting caught short or leaving cash idle.
- **Judging the forecast by positioning standards** — expecting a three-month forecast to be as accurate as today's position, then declaring forecasting "unreliable" and abandoning it.
- **One tool, one process for both** — a single spreadsheet that's neither an accurate position nor a disciplined forecast.

Keeping them distinct is what lets you demand near-certainty from the position _and_ accept useful-but-imperfect from the forecast.

## Direct vs indirect forecasting

Forecasting itself splits into methods — **direct** (bottom-up from actual expected receipts and payments) and **indirect** (derived from projected financials). They aren't rivals; they answer different horizons, and most treasuries run both. For positioning, the method question doesn't arise: it's confirmed data or it isn't a position.

|  | Direct | Indirect |
| --- | --- | --- |
| **Built from** | Actual expected receipts & payments (AR, AP, payroll, treasury) | Projected P&L and balance-sheet movements |
| **Best horizon** | Short-term — days to ~13 weeks | Medium/long-term — months to quarters |
| **Strength** | Operational accuracy, real cash-_timing_ detail | Ties to the plan; far less data-hungry |
| **Weakness** | Data-heavy; needs clean operational feeds | Coarse on timing; little use for same-day action |
| **Typical use** | The [13-week cash flow](https://gravam.com/blog/13-week-cash-flow-forecast), liquidity operations | Strategic funding, covenant and plan views |

The practical rule: use **direct** for anything you'll act on operationally, **indirect** for the long view — and never judge one by the other's yardstick.

## How they work together

In practice they're a continuum. Today's confirmed position is the anchor point of the forecast; the near-term forecast becomes tomorrow's position as flows confirm; and comparing what you forecast against what actually landed is how you **measure and improve forecast accuracy** over time. Run both, keep them distinct, and let each do its own job: the position for what's real today, the forecast for what's likely tomorrow. To build the short-horizon forecast itself, the free [13-Week Cash Flow Model](https://gravam.com/tools/13-week-cash-flow-model) turns weekly receipts and payments into a running position.

***

_See also [physical vs notional cash pooling](https://gravam.com/blog/physical-vs-notional-cash-pooling) and [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank)._

## Questions this article answers

**Q: What is the difference between cash positioning and cash flow forecasting?**

Cash positioning is knowing your actual available cash right now and over the next few days — high accuracy, short horizon, operational. Cash flow forecasting is projecting future cash over weeks, months or longer — lower certainty, longer horizon, for planning and funding decisions. Positioning is about today's reality; forecasting is about tomorrow's estimate.

**Q: What is cash positioning in treasury?**

Cash positioning is the daily process of determining exactly how much cash is available across all bank accounts and currencies, using confirmed balances and known same-day flows, so you can decide today's actions — funding, investing, or covering shortfalls. It prioritizes accuracy and timeliness over horizon.

**Q: Is cash forecasting the same as cash positioning?**

No — cash forecasting and cash positioning are related but distinct jobs. Positioning answers 'how much cash do we have now?' with near-certainty; forecasting answers 'how much will we have?' with estimates. They use different data (confirmed balances vs projected flows) and serve different decisions (operational vs planning). Good treasury does both, and doesn't confuse one for the other.

---

# Balance Sheet FX Hedging vs Cash Flow Hedging

Source: https://gravam.com/blog/balance-sheet-fx-hedging
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: Balance sheet FX hedging offsets remeasurement of booked FX balances, so it rarely needs hedge accounting. How it differs from cash flow hedges, and SAP's take.

**Balance sheet FX hedging protects the P&L against the remeasurement of foreign-currency balances an entity already carries: receivables, payables, intercompany loans, foreign-currency cash. Because the balance is revalued through profit or loss and the hedging derivative is too, the two offset without any hedge accounting. Cash flow hedging protects transactions that are only forecast, and there hedge accounting is what stops the derivative from moving the P&L ahead of the transaction it hedges.** Same forwards, same dealing desk, two different accounting problems. Treating them as one is how treasuries end up documenting hedges that didn't need it, or leaving hedges undocumented that did.

_(This explains how the two approaches work. It isn't accounting or hedging advice for any particular entity, and your auditors decide the treatment.)_

## Two exposures, two problems

Both exposures are [transaction exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure). They differ in whether the exposure is on the balance sheet yet, and that difference decides everything else.

| Question | Balance sheet (remeasurement) hedge | Cash flow hedge |
| --- | --- | --- |
| What is hedged | Booked FX monetary items: AR, AP, intercompany loans, FX cash | Forecast or committed flows not yet recognized |
| Accounting of the hedged item | Retranslated at closing rate; difference to P&L (IAS 21) | Nothing recognized until the transaction happens |
| Derivative without hedge accounting | Fair value through P&L | Fair value through P&L, ahead of the item: a genuine mismatch |
| Hedge accounting needed? | Usually not: the offset is natural | Yes, if the P&L volatility matters |
| Paperwork | Policy, exposure report, deal tickets | Designation, documentation, effectiveness at inception and ongoing |
| Typical cadence | Monthly (or more often), rolled around closing dates | Layered over the forecast horizon |
| Data source | The general ledger | The forecast |

The last row causes more practical trouble than the rest put together. A balance-sheet programme is only as good as the ledger balances it reads. A cash flow programme is only as good as the forecast. They're different data problems owned by different people, and one [hedging strategy](https://gravam.com/blog/fx-hedging-strategy) document has to cover both.

## Why the balance sheet hedge needs no hedge accounting

The mechanics come straight from IAS 21. Foreign-currency **monetary items are translated at the closing rate** at each reporting date (IAS 21.23), and **exchange differences on them are recognized in profit or loss** in the period they arise (IAS 21.28). A USD receivable in a EUR entity therefore generates a P&L gain or loss every month-end the rate moves.

An FX forward that isn't designated in a hedging relationship is a derivative at fair value through profit or loss. Sell USD forward against that receivable and its value moves the other way, in the same P&L, in the same period. Nothing needs deferring, because nothing is out of step. **Hedge accounting under IFRS 9 is optional**: it's a tool for fixing an accounting mismatch, and this relationship doesn't have one.

US GAAP gets to the same place by a different route. Foreign-currency balances are remeasured at spot under ASC 830 with the transaction gain or loss in earnings, and practitioner guidance on ASC 815 notes that applying fair value hedge accounting to such an item produces the same overall result as not applying it at all.

> Hedge accounting fixes a timing mismatch. A balance sheet hedge doesn't have one. The receivable and the forward already move through the same P&L in the same month.

## What doesn't offset, even without the paperwork

"Natural offset" doesn't mean a perfect one. Four residuals are worth predicting before someone asks about them in the month-end review:

- **Forward points.** The balance is remeasured at spot. The forward is valued at fair value, which reflects the forward rate and discounting. The difference, broadly the interest differential between the two currencies, lands in P&L as carry. It's expected and it can be budgeted, but it isn't zero.
- **Timing of the exposure read.** Balances move every day, while hedges are usually set from a snapshot of the ledger. Anything booked or settled between the snapshot and the closing date is unhedged or over-hedged by that amount.
- **Functional currency, not group currency.** Remeasurement happens in each entity against its own functional currency. Two entities' balances in the same currency don't offset each other's P&L if their functional currencies differ, so the exposure has to be measured per entity and currency pair, not netted at group level by instinct.
- **Net investment balances.** IAS 21.32 treats monetary items that form part of a net investment in a foreign operation differently in the consolidated statements, where exchange differences go to other comprehensive income instead. A long-term intercompany loan designated that way isn't a balance sheet exposure in the group P&L, and hedging it as one creates the very mismatch the programme exists to remove.

Each of these is an exposure-data question more than a dealing question, which is why [exposure data quality](https://gravam.com/blog/treasury-exposure-data-quality) decides whether a balance-sheet programme works.

## Where cash flow hedges are different

A cash flow hedge covers something that isn't on the balance sheet yet: next quarter's forecast sales in USD, a committed purchase in JPY. Without hedge accounting, the forward's fair value moves the P&L now, while the sale it protects arrives later. That's the mismatch [hedge accounting](https://gravam.com/blog/hedge-accounting-explained) exists to remove.

Under IFRS 9 the effective portion of the hedging instrument's gain or loss goes to **other comprehensive income** (the cash flow hedge reserve) and is **reclassified to profit or loss in the period the hedged cash flows affect it**. If the hedged cash flows are no longer expected to occur, the amount is reclassified immediately. In exchange for that deferral, the standard asks for formal designation and [documentation at inception](https://gravam.com/blog/hedge-documentation-requirements) and an ongoing [effectiveness assessment](https://gravam.com/blog/hedge-effectiveness-testing). That's real, recurring work, and it's worth doing only where the alternative, P&L volatility on unrecognized flows, matters to someone.

## The handover: when a forecast becomes a receivable

The two programmes meet at invoicing. The day a forecast sale is invoiced, the exposure stops being a forecast and becomes a booked receivable. It moves from the cash flow bucket to the balance sheet bucket.

There are two broad designs, and the system has to support whichever you pick:

1. **One instrument, two phases.** The same forward covers the forecast under a cash flow hedge and, once the item is recognized, offsets its remeasurement. How the relationship and the reserve are treated after recognition is an accounting-policy decision, and one to settle with your auditors before the first deal, not after the first quarter.
2. **Two programmes.** Cash flow hedges run to the point of recognition. A separate balance-sheet programme, rolled each month, covers booked balances from the ledger.

What fails is not choosing. The same receivable ends up covered by a forecast hedge that nobody de-designated and by a balance-sheet hedge sized from the ledger, and the exposure is hedged twice. That's [natural and financial hedging](https://gravam.com/blog/natural-hedging-vs-financial-hedging) losing track of each other inside one treasury.

## How SAP supports balance sheet FX risk

SAP models the split in the product itself. [Hedge Management in SAP](https://gravam.com/blog/hedge-management-in-sap) has two FX processes, and only one of them involves hedge accounting.

**Hedge Management of Balance Sheet FX Risk** is the remeasurement process. SAP defines balance sheet FX risk as arising from the revaluation of monetary balance sheet items in foreign currency, and the process is built around that:

| Step | What SAP provides |
| --- | --- |
| Exposure | The **Review Balance Sheet FX Risk** app reads open items and balances in foreign currency on G/L accounts in Financial Accounting, plus operational data from One Exposure, as FX exposures |
| Hedges | Financial transactions from the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) appear as the hedges against those exposures |
| Freeze | A **snapshot** of exposures and hedges, taken from the app and stored, gives the reference point for decisions |
| Hedge requests | Balance sheet exposure hedge requests are **generated from released snapshot data**, or created manually |
| Release | In **Process Hedge Requests - Balance Sheet FX Risk** you edit, delete and release requests; on release the system creates a **trade request** automatically |
| Monitoring | The **Balance Sheet FX Risk** tile shows hedges, exposures and absolute net exposures by company code in a display currency |

Notice what isn't in that list: designation, a hedge relationship, an effectiveness test. The process goes from ledger exposure to snapshot to hedge request to trade request to deal, and the accounting takes care of itself because the offset is natural.

The forecast side runs through the other process, **Hedge Management and Accounting of Net Open Exposures (FX Risk)**, which SAP describes as managing the risks of planned and confirmed foreign-currency cash flows in future periods. There, hedging areas set the granularity, the Hedge Management Cockpit shows net open exposure, and hedge accounting has to be switched on deliberately: the hedging area is marked relevant for hedge accounting before automated designation of exposure items applies.

The practical upshot for a design: **scope the balance-sheet process as a treasury and ledger-data project, and the net-open-exposure process as a treasury and accounting project.** They share instruments and a trading desk. They don't share a data source, a control set or a workload.

## Splitting balance sheet and forecast hedging

- Write down, per exposure type, whether it's hedged on the balance sheet or as a forecast, and where the handover at invoicing sits.
- Run the balance-sheet programme without hedge accounting, and budget the forward points as carry.
- Measure balance-sheet exposure per entity against its functional currency, and exclude net-investment balances explicitly.
- Reserve hedge accounting for the forecast programme, where the mismatch is real, and staff it with someone who knows the standard.
- In SAP, use the balance-sheet process for the ledger side and the net-open-exposure process for the forecast side, and don't force one to do the other's job.

_See also [FX hedging instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) and [what treasury risk management covers](https://gravam.com/blog/what-is-treasury-risk-management)._

## Primary sources

IAS 21 and IFRS 9 as currently issued; US GAAP ASC 830 and ASC 815 as amended by ASU 2017-12; SAP S/4HANA Treasury and Risk Management (Hedge Management of Balance Sheet FX Risk, and Hedge Management and Accounting of Net Open Exposures) as documented for current on-premise and Cloud releases. Claims were checked on 2026-09-25 through cross-checked excerpts of the listed sources; the standards' primary text and SAP Help could not be opened directly. This is educational, not accounting or hedging advice — confirm treatment with your auditors.

- IFRS Foundation — IAS 21 The Effects of Changes in Foreign Exchange Rates — accessed 2026-09-25 — https://www.ifrs.org/issued-standards/list-of-standards/ias-21-the-effects-of-changes-in-foreign-exchange-rates/
- IAS Plus — IAS 21 summary (closing rate for monetary items; exchange differences in profit or loss; net investment exception) — accessed 2026-09-25 — https://www.iasplus.com/en/standards/ias/ias21
- ACCA — IFRS 9 Financial Instruments, part 2 (hedge accounting is optional; cash flow hedge reserve and reclassification) — accessed 2026-09-25 — https://www.accaglobal.com/us/en/student/exam-support-resources/professional-exams-study-resources/strategic-business-reporting/technical-articles/ifrs9-pt2.html
- The CPA Journal — Hedges of Recognized Foreign Currency–Denominated Assets and Liabilities — accessed 2026-09-25 — https://www.cpajournal.com/2019/09/04/hedges-of-recognized-foreign-currency-denominated-assets-and-liabilities/
- SAP Help — Hedge Management of Balance Sheet FX Risk — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/444a7358ff3ca107e10000000a441470.html
- SAP Help — Balance Sheet FX Risk (tile and measures) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/3c44a1d78aed4200b6c544d126020c7a.html
- SAP Help — Process Hedge Requests - Balance Sheet FX Risk — accessed 2026-09-25 — https://help.sap.com/doc/474a13c5e9964c849c3a14d6c04339b5/100/en-US/3eb10ce1701d43c2b408f4ed246915f5.html
- SAP Help — Generate Balance Sheet Exposure Hedge Requests — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/ee51492f7d964874acae580cfd2007d3.html
- SAP Help — Hedge Management and Accounting of Net Open Exposures (FX Risk) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/104b7358ff3ca107e10000000a441470.html
- SAP Help — Hedging Area: Hedge Accounting I — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/6a8f3d58eaa89144e10000000a4450e5.html

## Questions this article answers

**Q: What is balance sheet FX hedging?**

Balance sheet FX hedging protects profit and loss against the remeasurement of foreign-currency monetary items an entity already carries, such as receivables, payables, intercompany loans and foreign-currency cash. Under IAS 21 those items are retranslated at the closing rate each reporting date and the exchange difference goes to profit or loss. A treasury offsets that by holding FX forwards or swaps in the opposite direction, sized to the net booked balance per entity and currency, and rolled each period.

**Q: Why does balance sheet hedging usually not need hedge accounting?**

Because the offset happens on its own. The hedged balance is remeasured through profit or loss under IAS 21, and an undesignated derivative is measured at fair value through profit or loss, so both movements land in the same line of the same period. Hedge accounting exists to fix a timing mismatch between the hedge and the hedged item, and here there is none to fix. US GAAP reaches the same place: fair value hedge accounting for a recognized foreign-currency item gives the same overall result as not applying it.

**Q: What is the difference between a balance sheet hedge and a cash flow hedge?**

A balance sheet hedge covers an exposure that is already recognized, where the remeasurement of the item and the derivative both hit profit or loss, so no hedge accounting is needed. A cash flow hedge covers a forecast transaction that is not yet on the balance sheet, such as next quarter's expected sales. There the derivative would move profit or loss before the transaction exists, so hedge accounting defers the effective portion in other comprehensive income until the hedged cash flows affect profit or loss, which requires formal designation, documentation and effectiveness assessment.

---

# Treasury Risk Aggregation & Reporting

Source: https://gravam.com/blog/treasury-risk-aggregation-and-reporting
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-28
Updated: 2026-09-02
Reviewed: 2026-09-02
Summary: How to aggregate treasury risk across exposures, entities and instruments — and report it so it drives a decision, not just fills a pack.

**A treasury risk report is a decision aid or it's decoration — and which one it is gets decided before the report, in the aggregation.** Every risk pack rests on a quiet assumption: that the exposures it sums are accurate, complete and current. When that assumption holds, the report drives real decisions — hedge more, cut a counterparty, hold a buffer. When it doesn't, you get a confident-looking number nobody can defend, and a risk committee making calls on data that doesn't tie. The banking world learned this the hard way; the Basel Committee's [BCBS 239 principles](https://www.bis.org/publications/201301-guidelines-principles-effective-risk-data-aggregation-and-risk-reporting) are the response, and they map cleanly onto what a corporate treasury needs. This is how to aggregate risk you can trust and report it so it actually decides something.

## Aggregation is where risk reporting succeeds or fails

The instinct is to judge a risk report by its layout. Judge it by its **aggregation** instead — the step that pulls exposures from across entities, currencies, instruments and systems into one view. Everything the report shows is only as good as that step:

- If exposures are **incomplete**, the report understates real risk.
- If they're aggregated at **different moments**, you're summing numbers that don't belong together.
- If entity/currency **consolidation** is inconsistent, concentrations hide.
- If any step is **manual and untraceable**, the aggregate can't be defended.

Aggregation fails at the data layer, not the report layer — which is why cosmetically fixing a report never helps. The fix is always upstream, in the [data quality and lineage](https://gravam.com/blog/treasury-data-lineage) beneath it.

## The BCBS 239 lens, applied to treasury

BCBS 239 was written for large banks, but its eleven bank-facing principles (of fourteen — Principles 12 to 14 are addressed to supervisors) are the cleanest checklist for whether risk data and reporting can be trusted anywhere. Grouped, and translated to a corporate treasury:

| Group | Principle (BCBS 239) | In a treasury, this means… |
| --- | --- | --- |
| **Governance & infrastructure** | Governance; data architecture & IT | Someone owns risk data; systems can produce it |
| **Aggregation capabilities** | Accuracy & integrity | Exposures reconcile to source; no untraceable steps |
|  | Completeness | All material exposures, all entities, all currencies |
|  | Timeliness | Aggregated as of one moment, fast enough to act |
|  | Adaptability | You can re-cut by entity, currency, counterparty on demand |
| **Reporting practices** | Accuracy | The report reflects reconciled data |
|  | Comprehensiveness | Covers FX, rate, counterparty, liquidity; shows concentrations |
|  | Clarity & usefulness | Says what it means and what to decide |
|  | Frequency | Produced when decisions are made, not just monthly |
|  | Distribution | Reaches the people who can act |

The two most-skipped in practice are **adaptability** and **clarity & usefulness**. A risk view you can't re-cut by counterparty the moment a bank wobbles is a report, not a risk tool. And a report that states numbers without stating the decision they support is a data dump — comprehensive and useless at once.

> The test of a risk report isn't "is it complete?" — it's "did it change or confirm a decision?" A pack nobody acts on isn't risk management; it's risk documentation.

## Report to the decision, not to the calendar

Most treasury risk reporting is organised by _cadence_ — the monthly pack, the quarterly committee. Organise it by _decision_ instead, and both the content and the frequency fall out:

- **Hedging decisions** need current exposure and hedge-ratio-vs-[limit](https://gravam.com/blog/risk-appetite-and-limits-in-treasury) views, at the frequency you actually rebalance.
- **Counterparty decisions** need exposure-by-name and concentration views, available _on demand_ when a bank's credit moves — not waiting for month-end.
- **Liquidity decisions** need the buffer-vs-floor view at the cadence liquidity actually changes.
- **Governance decisions** need the appetite-vs-actual and breach view for the committee.

Each is a different report, a different audience, a different frequency — united by the same aggregated, reconciled data underneath. Build the data foundation once; cut the reports to the decisions many times.

## What a report must make obvious

Whatever the decision, a treasury risk report earns its place only if three things are impossible to miss:

1. **The position against appetite/limit.** Not just "VaR is X" but "X against a limit of Y" — the [decision the metric supports](https://gravam.com/blog/value-at-risk-var-in-treasury).
2. **The concentrations.** Where risk is bunched — one counterparty, one currency, one maturity — because concentration is what turns a manageable risk into a loss.
3. **The change.** What moved since last time, and why. A static snapshot hides the trend that's the actual signal.

A number with no limit is trivia; a total with no concentration hides the danger; a snapshot with no change hides the story.

## Why aggregated risk numbers are hard to defend

- **Aggregating unreconciled data.** Summing exposures that don't tie to source, so the total is authoritative-looking and indefensible.
- **Timing mismatches.** Adding positions as of different moments because systems don't align.
- **Spreadsheet aggregation.** A manual consolidation step nobody can trace or repeat — the classic single point of failure.
- **Comprehensive but useless.** Pages of accurate numbers with no "so what," so the committee nods and decides nothing.
- **Calendar-bound reporting.** Only monthly views, so a counterparty decision that needs today's concentration waits three weeks.

## Fix the data before the risk deck

Fix the data before the deck. Aggregation you can defend — reconciled to source, complete across entities and currencies, as of one moment, re-cuttable on demand — is the whole game; the report layout is the easy part once the data is right. Report to decisions, not cadences: build one trusted aggregation and cut it into the hedging, counterparty, liquidity and governance views each audience actually acts on. And hold every report to one test — did it change or confirm a decision? If not, it's documentation, and treasury has enough of that already.

***

_See also [risk appetite and limits in treasury](https://gravam.com/blog/risk-appetite-and-limits-in-treasury), [value-at-risk in treasury](https://gravam.com/blog/value-at-risk-var-in-treasury) and [cash flow at risk (CFaR)](https://gravam.com/blog/cash-flow-at-risk-cfar)._

## Primary sources

BCBS 239 is a banking-supervision framework for G-SIBs/D-SIBs; its principles are applied here to corporate treasury risk data and reporting, where they're a strong benchmark rather than a regulatory obligation. Your obligations depend on your entity type and jurisdiction.

- BCBS — Principles for effective risk data aggregation and risk reporting (BCBS 239) — accessed 2026-07-28 — https://www.bis.org/publications/201301-guidelines-principles-effective-risk-data-aggregation-and-risk-reporting

## Questions this article answers

**Q: What is risk data aggregation in treasury?**

Risk data aggregation is pulling together risk exposures from across entities, currencies, instruments and systems into one accurate, complete, timely view — so you can see the group's real exposure and any concentrations, not just fragments per system. It's the step between raw positions and a risk report: if aggregation is wrong, every number downstream is wrong. The Basel Committee's BCBS 239 principles frame it well — accuracy and integrity, completeness, timeliness and adaptability — and while they were written for large banks, the same properties decide whether a corporate treasury's risk numbers can be trusted.

**Q: What makes a good treasury risk report?**

One that drives a decision. A good risk report is accurate (built on reconciled data), comprehensive (covers the material risks — FX, interest rate, counterparty, liquidity — with concentrations visible), clear and useful (says what the numbers mean and what decision they support, not just what they are), produced at the right frequency, and distributed to the people who can act. The failure mode is a report that's technically complete but decision-useless: pages of numbers with no 'so what.' If a risk report doesn't change or confirm a decision, it's a data dump wearing a cover page.

**Q: Why does risk aggregation fail?**

Usually because the data underneath it is fragmented and unreconciled. Exposures live in different systems with different conventions; entities and currencies aren't consolidated consistently; timing differs, so you're adding numbers as of different moments; and manual spreadsheet steps introduce errors nobody can trace. The result is an aggregate that looks authoritative but can't be defended — you can't say it's accurate, complete or current. Aggregation fails at the data layer, not the report layer, which is why fixing the report cosmetically never works: the fix is upstream, in data quality, ownership and reconciliation.

---

# Treasury Exposure Data Quality

Source: https://gravam.com/blog/treasury-exposure-data-quality
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Every hedge and risk decision rests on exposure data. How to make it trustworthy — accuracy, completeness, timeliness, adaptability — and who owns each.

**Every hedge is a bet sized against a number — and if that number is wrong, executing the hedge perfectly just makes you precisely wrong.** Treasury spends enormous care on hedging strategy, instruments and effectiveness, and comparatively little on the exposure data all of it rests on. Yet the exposure — the FX receivable, the floating-rate debt, the forecast flow, the counterparty balance — is what you're actually managing. Get the data wrong and the best hedging framework in the world produces confident, well-documented, wrong decisions: over-hedging a number that's overstated, leaving real risk uncovered because it's incomplete, hedging last quarter because it's stale. This is how to make exposure data trustworthy, using the same dimensions the banking world settled on after the crisis.

## Exposure data is upstream of everything

Keep the distinction sharp: **exposure** is what you're at risk to; **position** is what you've done about it. [Hedging strategy](https://gravam.com/blog/fx-hedging-strategy) compares the two — hedge ratio is position over exposure — so the quality of the exposure figure flows directly into every hedging and risk decision. That makes exposure data quality _upstream_ of hedging, not a technical detail beneath it. A hedge executed flawlessly against a bad exposure is a bad hedge.

The failure is subtle because it's invisible until it bites: the exposure number _looks_ authoritative, the hedge _looks_ right, and nobody questions a decision that isn't obviously broken — until the exposure it was sized against turns out never to have been real.

## The four dimensions that decide trust

The Basel Committee's [BCBS 239](https://www.bis.org/publications/201301-guidelines-principles-effective-risk-data-aggregation-and-risk-reporting) risk-data principles were written for large banks, but its data-quality dimensions are the cleanest test for whether _any_ risk data can be trusted. Applied to treasury exposure data:

| Dimension | The question | Fails as… | Owner |
| --- | --- | --- | --- |
| **Accuracy & integrity** | Does it reconcile to source, with no untraceable steps? | An exposure that can't be tied back to a document | Exposure data owner |
| **Completeness** | All entities, currencies, exposure types, forecast where relevant? | A whole entity or currency silently missing | Group treasury |
| **Timeliness** | Is it current, as of a known moment? | Hedging last quarter's business | The feeding processes |
| **Adaptability** | Can you re-cut by entity, currency, counterparty on demand? | A fixed report you can't slice when a bank wobbles | Reporting / data owner |

The two most quietly broken are **completeness** and **timeliness**. Completeness fails when a subsidiary's exposures never make it into the group view — so the aggregate understates real risk. Timeliness fails when exposure is refreshed on a slow cycle — so you're always managing a slightly-past reality. Both look fine on the surface; both make every downstream hedge slightly wrong.

> Exposure data doesn't fail loudly. It fails as a hedge that was perfectly executed against a number that was never quite real — and you only find out when the "hedged" exposure moves anyway.

## Forecast exposure: the hardest quality problem

Confirmed exposures (a booked FX receivable) are hard enough to keep clean; **forecast** exposures are harder, because they're estimates that hedging still acts on. The quality questions sharpen:

- **How firm is it?** A high-certainty forecast (a signed contract) and a low-certainty one (a sales projection) are different data with different reliability — and should be hedged differently, per the [certainty tiers](https://gravam.com/blog/fx-hedging-strategy) in hedging strategy.
- **Who owns the forecast?** Exposure forecasts usually come from the business, not treasury — so the data quality depends on a source treasury doesn't control, which has to be _governed_, not just consumed.
- **How is it reconciled?** Forecast-to-actual comparison is the only way to know whether the exposure data is systematically biased — the same discipline as [cash forecast accuracy](https://gravam.com/blog/how-to-measure-cash-forecast-accuracy), applied to exposures.

Treating forecast exposure as if it were as firm as a booked one is how a hedging programme quietly builds risk on sand.

## Ownership: the fix that isn't technical

Every dimension above ends in an _owner_ for a reason. Exposure data quality is not primarily a systems problem — it's an ownership problem wearing a technical costume. The recurring failure is that exposure data is _everyone's input and no one's responsibility_: the business provides forecasts, systems hold booked exposures, treasury consumes the aggregate, and when a number is wrong there's no one accountable for it having been right.

The fix is the [system-of-record discipline](https://gravam.com/blog/treasury-system-of-record) applied to exposures: name, per exposure type, the single owning source and a person accountable for its accuracy, completeness and timeliness. Without that, every quality initiative is a spreadsheet cleanup that decays the moment attention moves on.

## How exposure data quality decays

- **Spreadsheet-collected exposures.** Gathered ad hoc each period from sources nobody reconciles, so quality decays invisibly.
- **A missing entity.** One subsidiary never in the group view, so risk is understated by exactly the amount you can't see.
- **Stale forecasts.** Exposure refreshed slowly, so hedging always lags the business.
- **Forecast treated as fact.** Low-certainty projections hedged as if they were signed, building risk on estimates.
- **No owner.** Everyone's input, no one's responsibility — so a wrong exposure has no one accountable for having been right.

## Putting exposure data ahead of hedge strategy

Put exposure data quality _upstream_ of hedging strategy in the priority order, because that's where it sits in reality. Hold it to the four dimensions — accuracy, completeness, timeliness, adaptability — and give each an owner and a reconciliation, not a promise. Treat forecast exposure as the distinct, harder data it is: tiered by certainty, governed at the business source, reconciled to actuals. And apply the system-of-record rule — one owner per exposure type — because the cleanest exposure model still rots without someone accountable for keeping it real. Sophisticated hedging on unreliable exposure data isn't risk management; it's precision applied to the wrong number. The wider discipline this sits inside — ownership, definitions, change control and drift monitoring across every treasury domain, not just exposures — is [treasury data quality and governance](https://gravam.com/blog/treasury-data-quality-and-governance).

***

_See also [treasury risk aggregation & reporting](https://gravam.com/blog/treasury-risk-aggregation-and-reporting) and [FX hedging strategy](https://gravam.com/blog/fx-hedging-strategy)._

## Primary sources

BCBS 239's data-quality principles are framed for large banks; applied here to corporate treasury exposure data as a benchmark, not a regulatory obligation. Your obligations depend on entity type and jurisdiction.

- BCBS — Principles for effective risk data aggregation and risk reporting (BCBS 239) — accessed 2026-07-28 — https://www.bis.org/publications/201301-guidelines-principles-effective-risk-data-aggregation-and-risk-reporting

## Questions this article answers

**Q: What is exposure data in treasury?**

Exposure data is the record of what the company is actually exposed to — the foreign-currency receivables and payables, the floating-rate debt, the forecast flows, the counterparty balances — that hedging and risk decisions are made against. It's distinct from position data (the deals and instruments you hold): exposures are the underlying risk; positions are what you've done about it. Good treasury risk management compares the two, so the quality of the exposure data directly determines whether you're hedging the right amount of the right thing. Bad exposure data means hedging a number that isn't real.

**Q: How do you ensure exposure data is accurate?**

By treating it as owned, reconciled data rather than a periodic extract. The dimensions that matter — borrowed from the BCBS 239 principles — are accuracy and integrity (it reconciles to source, with no untraceable manual steps), completeness (all entities, currencies and exposure types, including forecast where relevant), timeliness (current as of a known moment), and adaptability (you can re-cut it by entity, currency or counterparty on demand). Each dimension needs an owner and a reconciliation. Exposure data that's collected ad hoc from spreadsheets each quarter fails all four quietly — it looks fine until a hedge is sized against a number nobody can defend.

**Q: Why does poor exposure data matter for hedging?**

Because a hedge is only as right as the exposure it covers. If the exposure is overstated, you over-hedge and create a new position; if it's understated or incomplete, you leave real risk unhedged; if it's stale, you're hedging last quarter's business. The hedge itself can be executed perfectly and still be wrong, because it was sized against bad data. That's why exposure data quality is upstream of hedging strategy, not a detail beneath it — the most sophisticated hedging framework applied to unreliable exposure data produces confident, precise, wrong decisions.

---

# Stress Testing and Scenario Analysis in Treasury

Source: https://gravam.com/blog/stress-testing-and-scenario-analysis-treasury
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Treasury stress testing and scenario analysis probe the severe tail that VaR and CFaR leave undescribed — and fail on imagination, not maths.

**Stress testing and scenario analysis probe what your statistical measures can't: the severe, low-probability moves that actually threaten a business.** [Value at Risk](https://gravam.com/blog/value-at-risk-var-in-treasury) and [Cash Flow at Risk](https://gravam.com/blog/cash-flow-at-risk-cfar) describe the distribution of outcomes up to a confidence level — but they go quiet exactly where it matters, at the tail beyond that threshold. Stress testing asks a different question altogether: not "how bad is an ordinary bad day?" but "what happens _if_ this specific bad thing occurs?" It's the tool for the cliff the measurement numbers refuse to describe.

_(This is a plain explanation of a risk-management practice, not investment or hedging advice for any particular situation.)_

## The gap it fills

A 95% VaR tells you where the edge of an ordinary bad day sits, and CFaR tells you the shortfall against plan you wouldn't expect to breach over the year. Both are genuinely useful, and both share the same silence: they say almost nothing about what lies _beyond_ the confidence level. The worst 5% of outcomes get summarised into a single threshold and then left undescribed — and that undescribed tail is precisely where the losses that wreck companies live.

That's not a flaw you can calibrate away; it's structural. A probability-weighted measure exists to characterise the body of a distribution. To understand the tail, you stop asking "how likely?" and start asking "what if?" Stress testing is that second question made systematic — it sets probability aside on purpose and looks at consequence: _if_ this severe move happened, what would it do to our positions, cash flows and covenants?

## Scenario analysis

The workhorse is scenario analysis: define a shock, apply it to the book, and read off the impact. Scenarios come in two flavours, and a serious programme uses both.

- **Historical scenarios** replay a real crisis — the actual market moves from a past episode of stress — against your _current_ positions. Their strength is that nobody can argue the moves were implausible: they happened. Their weakness is that the next crisis rarely rhymes exactly with the last.
- **Hypothetical scenarios** construct a plausible but unseen combination — a set of moves that hasn't occurred in your data but could. They cover the blind spot history leaves, at the cost of being harder to defend, because you're asserting the scenario is realistic rather than pointing at a date.

Either way, the output is concrete: what the scenario does to positions, to the cash flows the business is counting on, and — the one people forget until it's too late — to loan covenants. A move that bruises the P&L but breaches a leverage or interest-cover covenant is a different, more urgent problem than the loss alone suggests.

## Single-factor versus multi-factor

The simplest test shifts one variable: a single rate, a single currency, everything else held still. That's **single-factor sensitivity**, and it's useful for isolating exactly how much a given exposure moves the number — the treasury equivalent of nudging one input to see the output.

But crises don't move one variable at a time. They arrive as coherent, correlated bundles: a currency falls _while_ rates jump _while_ funding tightens, each feeding the others. A **multi-factor scenario** moves several variables together in a combination that hangs together as a story — closer to how real stress behaves, and where scenario analysis earns its keep, because the interactions between moves are often nastier than any single move in isolation. A hedge that neutralises one factor can be quietly undone by a second one the single-factor test never looked at.

> A crisis never sends its variables in one at a time and politely. It sends them together, correlated and compounding — which is exactly why a single-factor sensitivity can look survivable while the multi-factor version of the same event does not.

## Reverse stress testing

Forward scenarios start from a shock and find the impact. **Reverse stress testing** runs it backwards: start from an outcome you cannot accept — a covenant breach, a liquidity shortfall, a loss that would threaten the business — and work out what combination of moves would _cause_ it.

I've found this the more revealing exercise more often than not. Forward scenarios flatter you, because a team naturally reaches for the shocks it already believes in. Reverse stress testing removes that comfort: it names the failure first and forces you to describe the exact conditions that produce it. Sometimes the answer reassures — it would take a genuinely extreme, compound move to break the covenant. Sometimes it's the opposite, and you find the distance to a breach is far shorter than anyone assumed. Either way you learn something a forward scenario would never have surfaced, because you were asking "what would it take to sink us?" instead of "what does this shock do?"

## What to do with the results

A stress test that ends in a spreadsheet has done nothing. The results only matter when they meet a decision. So each scenario's impact gets compared against [risk appetite and limits](https://gravam.com/blog/risk-appetite-and-limits-in-treasury) — is this outcome inside what we've agreed to bear, or outside it? — and that comparison drives one of three responses: **hedge** the exposure down, **hold more liquidity** as a buffer against the shortfall, or **accept** the risk deliberately because the cost of protection outweighs it. Accepting is a legitimate answer, as long as it's a choice rather than a default.

And the scenarios don't stay fixed. Exposures change, the market regime shifts, new risks appear and old ones fade. A stress-testing programme is a living thing, re-examined as conditions move — the same monitor-and-repeat discipline that runs through all of [treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management).

## Why stress tests fail on imagination and follow-through

Here's the part worth saying plainly: stress tests almost never fail on the maths. Applying a shock to a book is the easy part. They fail on **imagination** and on **follow-through**.

The imagination failure is choosing comfortable scenarios. Teams run the shocks they can already picture and quietly skip the genuinely nasty combinations — the correlated, multi-factor events that are unpleasant to contemplate and therefore never modelled. The scenario that would actually hurt is the one nobody proposes, because proposing it means admitting it's possible.

The follow-through failure is worse, because it wastes even the good work. A team runs a hard scenario, sees an alarming result, and _files it_ — reported, noted, left to sit, with no decision to hedge, build liquidity, or formally accept. A stress test that changes nothing is theatre. The value was never in producing the number; it was in acting on it before the scenario stopped being hypothetical.

Run the uncomfortable scenarios, run them backwards from the outcomes you fear, compare every result against appetite, and _act_ — and stress testing becomes what [VaR](https://gravam.com/blog/value-at-risk-var-in-treasury) and CFaR can't be: an honest look at the tail, and a decision made before the tail arrives.

***

_See also [Value at Risk in treasury](https://gravam.com/blog/value-at-risk-var-in-treasury) and [Cash Flow at Risk (CFaR)](https://gravam.com/blog/cash-flow-at-risk-cfar)._

## Questions this article answers

**Q: What is stress testing in treasury?**

Stress testing is the practice of applying severe but plausible shocks to a treasury's positions, cash flows and covenants to see what happens if a specific bad thing occurs. Rather than estimating a loss threshold from a distribution, it asks a conditional question — if this scenario played out, what would it do to our liquidity, our hedged and unhedged exposures, and our compliance with loan covenants? It deliberately targets the severe, low-probability moves that statistical measures summarise but don't describe, so treasury can decide in advance whether to hedge, hold more liquidity, or accept the risk.

**Q: How is stress testing different from VaR?**

Value at Risk and Cash Flow at Risk describe the distribution of outcomes up to a confidence level — the edge of an ordinary bad day, or an ordinary bad year. They say little about the tail beyond that threshold, which is exactly where the losses that threaten a business live. Stress testing asks a different, conditional question: not 'how bad is a 95th-percentile outcome?' but 'what happens IF this particular severe scenario occurs?' VaR gives you a probability-weighted summary; stress testing gives you the consequence of a named event, regardless of how likely it is. They're complements — one measures the body of the distribution, the other explores the tail.

**Q: What is reverse stress testing?**

Reverse stress testing runs the logic backwards. Instead of starting from a scenario and reading off the impact, you start from an unacceptable outcome — a covenant breach, a liquidity shortfall, a loss that would threaten the business — and work out what combination of market moves would cause it. It's often more revealing than forward scenarios because it forces you to confront the specific conditions that would actually break you, rather than the comfortable scenarios a team tends to choose on its own. It answers 'what would it take to sink us?' rather than 'what does this shock do?'

---

# ISDA Agreements, CSAs and Collateral Management

Source: https://gravam.com/blog/isda-csa-and-collateral-management
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: How the ISDA Master Agreement, its schedule and the Credit Support Annex document and collateralise the counterparty risk in over-the-counter derivatives.

**An over-the-counter derivative is a long-lived promise between two parties, and the ISDA Master Agreement plus its Credit Support Annex are how the market documents and collateralises the counterparty risk in that promise.** When you enter a five-year swap, you're trusting the party on the other side to still be there, and still be able to pay, five years from now. If they default with the trade in your favour, that unpaid mark-to-market is a real credit exposure — the same [counterparty risk](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) treasury manages everywhere, but concentrated in a contract that can run for years. ISDA documentation and collateral are the machinery the market built to manage exactly that.

_(This is a plain explanation of standard derivative documentation, not legal or investment advice for any particular situation.)_

> **Figure — The ISDA Master Agreement, its trades and the collateral under a CSA**
>
> A folder labelled ISDA Master Agreement holds three trades — one agreement, many trades. Below it stand two parties, one out of the money and one in the money. An arrow carries collateral from the party that is out of the money to the party that is in the money, and is labelled CSA.
>
> The Master Agreement puts every trade with a counterparty under one contract; the CSA makes whoever is out of the money post collateral to the other.

## The problem a derivative creates

A [forward, option or swap](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) isn't settled and done — it's a position that lives, and its value swings with the market. On any given day one party is in-the-money and the other is out. The in-the-money party is, in effect, owed that value. If the other side fails before the trade matures, the value they owe may never arrive. So every open derivative carries a running credit exposure to whoever is on the losing side of it, and that exposure grows and shrinks as the market moves. The trade did its hedging job; the counterparty exposure it created still has to be managed.

## The ISDA Master Agreement

In my SAP TRM years I watched teams treat this as a legal-department problem. It isn't — it's the frame the whole derivative relationship hangs on. The **ISDA Master Agreement** is the standard framework contract two parties sign to govern their derivatives. Sign it once, and every trade you do with that counterparty falls under it — one agreement, many trades. The party-specific negotiated terms live in an attached **schedule**: governing law, which events count as default, the elections that tailor the standard text to the two parties.

Its single most important protection is **close-out netting**. Without it, if a counterparty defaults you'd settle each trade individually — and the defaulter's administrator could honour the ones where you owe them and walk away from the ones where they owe you. Netting stops that. On a default, every trade under the agreement collapses to _one_ net amount owed in one direction. You're exposed to the net, not the gross, and cherry-picking is off the table.

> Close-out netting is the quiet hero of the ISDA. It's the difference between being exposed to the net of everything you've done with a counterparty and being exposed, trade by trade, to whichever ones the administrator decides to keep.

## The Credit Support Annex

Netting shrinks the exposure; it doesn't fund it. That's the job of the **Credit Support Annex (CSA)** — the collateral agreement bolted onto the ISDA. Under a CSA, as the mark-to-market moves, the out-of-the-money party **posts collateral** to the in-the-money party. So instead of an open, unsecured exposure that grows quietly until a default reveals it, the exposure is _covered_ day by day. If your counterparty owes you more this week because the market moved, they post more collateral this week. The CSA also defines what collateral is eligible — usually cash or high-quality securities — and the mechanical terms: the **threshold** below which no collateral changes hands, and the **minimum transfer amount** that stops tiny calls being made every day.

## Variation margin and initial margin

Collateral under a CSA comes in two flavours, and the distinction matters. **Variation margin** tracks the daily mark-to-market change — it keeps the _current_ exposure covered as the position moves. **Initial margin** is an extra buffer posted on top, sized to cover the _potential future_ move in the position over the gap between a counterparty defaulting and you actually closing out and replacing the trade. Variation margin covers where the exposure is now; initial margin covers where it could get to before you're clear. Since the financial crisis, regulation has pushed margining — variation and, for larger participants, initial — onto many **non-cleared derivatives** that firms used to run uncollateralised. For a lot of treasuries, posting margin on hedges went from optional to obligatory.

## The operational reality nobody staffs for

Here's where documentation becomes daily work. A live CSA means **margin calls** — often daily. Someone has to value the portfolio, agree that valuation with the counterparty (or fight about it, because **valuation disputes** are routine when two models disagree on the same trade), and then actually _move_ collateral: pull cash, transfer securities, book it, reconcile it. Collateral management stops being paperwork and becomes a genuine operational function with people, systems and deadlines.

And it consumes liquidity. Collateral you post is cash or securities you can't use for anything else. When the market moves hard against your positions, the calls get bigger precisely when everything else is stressed too — the CSA turns a market move into an immediate, non-negotiable demand for cash. That's the same [liquidity risk](https://gravam.com/blog/what-is-treasury-risk-management) treasury manages elsewhere, arriving through the back door of a hedge.

## The collateral call nobody modelled

The trap I've seen most: a team focuses entirely on the trade — the rate, the structure, whether it hedges the [interest rate exposure](https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars) — and treats the ISDA and CSA as legal boilerplate to be signed and filed. Then the first big market move lands, the margin calls start, and they discover the collateral demand is a live liquidity requirement nobody modelled. The hedge was supposed to _reduce_ risk; the CSA underneath it quietly created a new liquidity exposure that only shows up when it's already biting.

The lesson is to read the CSA as a treasury document, not a legal one. Before you sign, know what it will demand of your cash in a stressed market, and model that alongside the hedge itself. The ISDA and CSA are how derivative counterparty risk gets documented and collateralised — but the collateral has to come from somewhere, and that somewhere is your liquidity.

***

_See also [counterparty and credit risk in treasury](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) and [FX hedging instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps)._

## Primary sources

ISDA documentation has multiple CSA versions (e.g. 2014 Standard CSA, 2018 IM CSA) under New York or English law; the right one depends on your jurisdiction and margin obligations. Verify against the current ISDA documentation.

- ISDA — Credit Support Annex (CSA) — accessed 2026-07-28 — https://www.isda.org/tag/credit-support-annex-csa/
- ISDA — 2014 Standard Credit Support Annex (Security Interest — New York Law) — accessed 2026-07-28 — https://www.isda.org/book/isda-2014-standard-credit-support-annex-2014-scsa-ny-law/

## Questions this article answers

**Q: What is an ISDA Master Agreement?**

The ISDA Master Agreement is the standard framework contract that governs over-the-counter derivative trades between two parties. Published by the International Swaps and Derivatives Association, it's signed once between two counterparties and then governs every derivative trade they do — one agreement, many trades. A negotiated schedule attaches the party-specific terms. Its most important protection is close-out netting: if one party defaults, all outstanding trades collapse to a single net amount rather than being settled trade by trade, which stops a failing counterparty (or its administrator) from cherry-picking the ones in its favour.

**Q: What is a CSA in derivatives?**

A Credit Support Annex (CSA) is the collateral agreement that attaches to the ISDA Master Agreement. It sets out that the party whose position is out-of-the-money posts collateral to the in-the-money party as the mark-to-market of the trades moves, so the exposure between them is covered rather than left open. The CSA defines what collateral is eligible (typically cash or high-quality securities), how often it's valued and called, and the mechanical terms such as thresholds and minimum transfer amounts. Not every ISDA has a CSA, but a CSA is what turns the ISDA's netting into actively collateralised exposure.

**Q: What is the difference between variation margin and initial margin?**

Variation margin tracks the day-to-day change in the mark-to-market of the trades — as the position moves, the losing party posts (or the gaining party returns) collateral so the current exposure stays covered. Initial margin is an additional buffer posted up front, sized to cover the potential future move in the position over the period between a counterparty's default and the trades being closed out and replaced. Variation margin covers what the exposure is today; initial margin covers what it could become before you're out. Regulation has pushed both onto many non-cleared derivatives that were previously uncollateralised.

---

# Interest Rate Benchmark Reform: LIBOR to SOFR

Source: https://gravam.com/blog/interest-rate-benchmark-reform-libor-sofr
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: The move from LIBOR to risk-free reference rates like SOFR and SONIA — why it happened, how RFRs differ, and what the transition meant for corporate treasury.

**Interest rate benchmark reform is the market-wide move from LIBOR to risk-free reference rates — SOFR for the US dollar, SONIA for sterling, €STR for the euro, and their peers — largely complete now.** LIBOR was retired because the interbank borrowing it was meant to measure had all but stopped happening, so the rate leaned on bank judgement and was open to manipulation. In its place regulators put transaction-based, near risk-free overnight rates. The concept is simple: swap the benchmark. The work, as always, was in the long tail — legacy contracts, fallback language, system conventions, and getting the interest calculation right under a rate that behaves differently from the one it replaced.

_(This is a plain explanation of what benchmark reform changed, not investment or hedging advice for any particular situation.)_

## Why LIBOR had to go

For decades LIBOR was the reference rate under most floating-rate debt and [interest rate risk in corporate treasury](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury). Your loan was quoted as LIBOR plus a margin; your [swaps and caps](https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars) referenced the same LIBOR. It was the rate the whole edifice sat on.

The problem was what LIBOR actually measured: the rate at which a panel of banks estimated they could borrow unsecured from each other. Two things went wrong with that. First, after the financial crisis, banks largely stopped lending to each other unsecured for term — so the transactions the rate was supposed to reflect increasingly weren't there. The number rested more on expert judgement than on trades. Second, a benchmark built on submissions rather than transactions is manipulable, and the rate-rigging scandals proved it was. A benchmark underpinning an enormous stock of contracts couldn't credibly rest on so few real trades and so much judgement. Regulators drew the obvious conclusion and pushed the market onto something anchored in actual transactions.

## What replaced it: risk-free rates

The replacements are the **risk-free reference rates (RFRs)**, one per currency, each built on real market transactions:

- **SOFR** (Secured Overnight Financing Rate) — the US dollar, based on overnight secured borrowing in the Treasury repo market.
- **SONIA** — sterling.
- **€STR** — the euro area.
- **TONA** — Japan.
- **SARON** — Switzerland.

They're called _near risk-free_ because they're overnight and carry little of the bank-credit risk baked into unsecured interbank lending. Sterling and most non-USD LIBOR settings ended around the end of 2021, and the main USD LIBOR settings ended around mid-2023. RFRs are the standard now — this isn't a coming change to prepare for, it's the world you already operate in.

## The differences that actually matter

On paper it's just a different rate. Operationally, the structure is different in ways that reach into every interest calculation.

|  | LIBOR | RFRs (e.g. SOFR) |
| --- | --- | --- |
| **Tenor** | Forward-looking term rate | Overnight |
| **Timing** | Known at the start of the period | Compounded in arrears; known near the end |
| **Basis** | Panel-bank estimates | Actual transactions |
| **Credit premium** | Yes — bank-credit and term premium | Near risk-free |

The one that bites is **timing**. LIBOR was forward-looking: at the start of an interest period you already knew the rate for it. An RFR is overnight, so a term interest amount is usually built by **compounding the daily rate in arrears** — you don't know the final figure until close to the payment date. That single change ripples into cash forecasting, invoicing, loan operations and system logic.

Two bridges were needed to make legacy contracts work. Because RFRs are near risk-free and LIBOR carried a credit and term premium, moving an existing contract from one to the other would silently change its economics — so a **credit spread adjustment** was added to bridge the gap and keep legacy deals roughly whole. And for cases that genuinely need a rate known _in advance_ — some trade finance, some loans where compounding in arrears is impractical — **term RFR** variants (forward-looking rates derived from RFR derivatives) exist to fill that specific gap.

> The hard part was never picking the new rate. It was that a backward-looking, compounded overnight rate doesn't behave like a forward-looking term rate — and every contract, system and interest calculation had quietly assumed the old behaviour.

## What it meant for corporate treasury

If you ran a treasury through this, the transition wasn't a memo — it was a programme of work:

- **Repapering.** Every LIBOR-referencing loan and derivative needed amending or replacing — new reference rate, fallback language, the credit spread adjustment where relevant. The long tail of old bilateral agreements was the slow part.
- **Fallbacks.** Contracts needed robust language for what the rate becomes when LIBOR ends — the difference between an orderly switch and a dispute.
- **Systems and conventions.** Treasury and loan systems had to handle compounding in arrears: lookback periods, observation shifts, day-count and rounding conventions. Small choices that have to match the counterparty's, or the two sides disagree on the interest due.
- **Interest calculation.** Getting the compounded-in-arrears number right, reconciled against the bank, was the unglamorous core of it — and the place errors actually showed up.
- **Hedge relationships.** A swap that referenced LIBOR against a loan that now references SOFR is no longer a clean match. [Hedge documentation](https://gravam.com/blog/hedge-documentation-requirements) had to be updated and relationships re-checked so they still passed [effectiveness testing](https://gravam.com/blog/hedge-effectiveness-testing) — the industry-wide reliefs helped, but the work still had to be done.

## Where the benchmark transition actually got hard

The slide-deck version is one line: replace LIBOR with SOFR. The reality was months of reconciling legacy paper, chasing counterparties for amendments, and arguing with a treasury system about lookback conventions. Nothing about the _concept_ was hard. Everything about the _implementation_ was in the detail — the contracts nobody had looked at in years, the fallback clauses, the exact compounding method, and interest figures that had to tie out to the penny against a bank that had made its own convention choices.

That's the pattern with benchmark reform, and it's the pattern with most treasury change: the decision is trivial and the transition is not. The rate under your [interest rate risk](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) is now an RFR, your hedges reference it, and it works. Getting there was a reminder that in treasury the benchmark is never _just_ a number — it's a number wired into every contract, system and calculation you own.

***

_See also [interest rate risk in corporate treasury](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) and [what treasury risk management is](https://gravam.com/blog/what-is-treasury-risk-management)._

## Primary sources

Benchmark reform is currency- and date-specific: USD LIBOR panel settings ceased on 30 June 2023 and SOFR is the ARRC-recommended USD alternative; other currencies have their own RFRs and timelines. Verify the current position for your currency against the relevant official body.

- ARRC / Federal Reserve Bank of New York — SOFR & the transition from LIBOR — accessed 2026-07-28 — https://www.newyorkfed.org/arrc/sofr-transition

## Questions this article answers

**Q: Why was LIBOR replaced?**

LIBOR was based on panel banks' estimates of what it would cost them to borrow unsecured from each other — but the underlying market it was meant to measure had thinned out to the point where much of the rate rested on expert judgement rather than real transactions. That made it both vulnerable to manipulation, as rate-rigging scandals showed, and unrepresentative of any genuine market. Regulators concluded a benchmark underpinning trillions in contracts couldn't rest on so few real trades, and moved the market to transaction-based risk-free rates. Sterling and most non-USD LIBOR settings ended around the end of 2021, and the main USD settings ended around mid-2023.

**Q: What is the difference between LIBOR and SOFR?**

LIBOR was a forward-looking term rate — you knew the rate for the coming period at the start of it — and it carried a bank-credit and term premium, because it reflected unsecured interbank lending. SOFR is an overnight, near risk-free rate based on actual secured (repo) transactions in the US Treasury market. Because SOFR is overnight and backward-looking, a term interest amount is typically built by compounding the daily rate in arrears over the period, so you don't know the exact figure until near the end. That single structural difference — forward term rate with credit premium versus compounded overnight risk-free rate — is what drove most of the operational work in the transition.

**Q: What are risk-free rates?**

Risk-free reference rates (RFRs) are the family of benchmarks that replaced LIBOR: SOFR in the US dollar market, SONIA for sterling, €STR in the euro area, TONA in Japan and SARON in Switzerland. They're called near risk-free because they're overnight rates based on actual transactions and carry little bank-credit risk, unlike LIBOR's unsecured interbank premium. They're now the standard reference for floating-rate loans and derivatives in their respective currencies.

---

# Hedge Documentation for Hedge Accounting

Source: https://gravam.com/blog/hedge-documentation-requirements
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-08-19
Reviewed: 2026-08-19
Summary: Hedge documentation: what you must designate at inception — objective, instrument, hedged item, risk and effectiveness method — for hedge accounting.

**Hedge documentation is the formal record you prepare at the start of a hedge relationship to qualify for [hedge accounting](https://gravam.com/blog/hedge-accounting-explained) — the written designation, made at inception, that says exactly what you are hedging, with what, against which risk, and how you will prove the offset.** Under both IFRS 9 and US GAAP (ASC 815), this documentation is not paperwork you tidy up later. It is a condition of entry. No contemporaneous documentation, no hedge accounting — and I've watched genuinely good hedges lose the treatment on that point alone.

_(This is a plain explanation of what hedge documentation involves, not accounting advice for a specific situation — the exact rules live in standards like IFRS 9 and ASC 815, and applying them to your book needs your accountants.)_

## Why it exists at all

Hedge accounting is optional and privileged (and not always needed: [balance sheet FX hedging](https://gravam.com/blog/balance-sheet-fx-hedging) of monetary items offsets in P&L without it). It lets you defer or relocate a derivative's gains and losses so they land in profit _together_ with the item they hedge, instead of swinging around on their own timing. That's a valuable smoothing of reported profit — and because it's a privilege, the standards make you earn it. You earn it by formally **designating and documenting** the hedge before the fact, not by reconstructing a story after a good quarter.

That "before the fact" is the whole point. If you could designate hedges retrospectively, you could cherry-pick: call a position a hedge when it happened to move your way, and leave it undesignated when it didn't. Contemporaneous documentation closes that door. It fixes your intention in writing at the moment you enter the relationship, when you don't yet know how it will turn out.

## What you actually have to document

The specifics vary by standard, but the substance is consistent across IFRS 9 and ASC 815. At inception you document, in essence, five things:

- **The risk management objective and strategy** for undertaking the hedge — _why_ you're doing it, and how it fits your broader approach to the risk — for currency hedges, the [FX hedging strategy](https://gravam.com/blog/fx-hedging-strategy) your policy sets.
- **Identification of the hedging instrument** — the specific derivative or other instrument being used.
- **Identification of the hedged item or transaction** — the recognised asset, liability, firm commitment or forecast transaction being protected.
- **The nature of the risk being hedged** — FX, interest rate, a specific priced component, and so on.
- **How hedge effectiveness will be assessed** — the method by which you'll show the instrument actually offsets the risk.

That last one is where the documentation hands off to a companion discipline. Naming your effectiveness method here is what you commit to in [hedge effectiveness testing](https://gravam.com/blog/hedge-effectiveness-testing) — designation is the promise, effectiveness testing is keeping it. (If you're weighing dollar-offset against regression, the [Hedge Effectiveness Checker](https://gravam.com/tools/hedge-effectiveness-checker) lets you run both on sample data before you commit to a method in writing.) Designation, documentation and effectiveness are the three legs of the same stool; pull any one and hedge accounting falls over.

## The inception-timing rule

Say it plainly: the documentation must be **in place at the start of the hedge relationship.** Not the same week, not "we always intended to." At inception.

> You cannot decide, after a good quarter, that a trade "was" a hedge all along. No contemporaneous documentation at inception, no hedge accounting — however clean the economics look in hindsight.

This is the rule people underestimate most, because it feels bureaucratic when the economics are obviously fine. But the timing requirement _is_ the safeguard. It's what separates a designated hedge from a bet you're re-labelling with the benefit of knowing the answer.

## What getting it wrong actually costs

The consequence is concrete and it's the exact thing you were trying to avoid. Incomplete or late documentation **disqualifies** the relationship. The hedge keeps working economically — the protection is unchanged — but the derivative reverts to being marked to market through P&L on its own timing, unmatched by the hedged item. You get the full, unhedged fair-value swing hitting reported profit: the artificial volatility hedge accounting exists to remove, delivered right back to you by a filing failure.

You did the right thing economically and got punished in the numbers, on process. That's a miserable conversation to have with a CFO, and I've had it.

## Making it survive contact with reality

The fixes are unglamorous, which is why they get skipped:

- **A documentation template or library.** Standardise the five elements so nothing gets forgotten under time pressure. A blank page at inception is how fields go missing.
- **Discipline to complete it before the trade settles.** Tie the paperwork to the trade lifecycle, not to month-end. If the documentation isn't done, the designation isn't real.
- **Keeping it current.** Relationships change — a rollover, a re-designation, a change in the hedged forecast. Documentation that describes last year's relationship doesn't support this year's.

## Why hedge documentation arrives too late

Here's what I actually see. The hedge economics are almost always fine. Treasury sizes the exposure sensibly, picks a reasonable instrument, executes. Where hedge accounting gets lost is **process** — a trade done Friday afternoon and "documented" the following week, once someone in accounting has a moment. By then the designation isn't contemporaneous, and the treatment is gone for that relationship.

The discipline that keeps hedge accounting is contemporaneous paperwork, full stop. It's dull enough that people quietly defer it until an auditor asks to see the inception file — and that's the worst possible moment to discover the file was assembled after the fact. Build the documentation into the trade, not around the audit.

One honest caveat: not everything needs a financial hedge in the first place. [Natural hedging](https://gravam.com/blog/natural-hedging-vs-financial-hedging) — offsetting exposures inside the business — carries no instrument to designate and no inception file to get wrong, which sidesteps this entire problem for the exposures it can reach. Where you do use instruments, though, the documentation is the price of the accounting, and it's due at inception.

***

_See also [hedge accounting explained](https://gravam.com/blog/hedge-accounting-explained) and [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management)._

## Primary sources

- IFRS 9 Financial Instruments, Chapter 6 (Hedge Accounting) — full text as adopted for use in the EU by Commission Regulation (EU) 2016/2067 of 22 November 2016, OJ L 323 — EU-adopted text, OJ L 323, 29.11.2016 — accessed 2026-08-19 — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R2067

## Questions this article answers

**Q: What is hedge documentation?**

Hedge documentation is the formal, written record a company prepares at the start of a hedge relationship to qualify for hedge accounting. Under both IFRS 9 and US GAAP (ASC 815), it must set out the risk management objective and strategy for the hedge, identify the hedging instrument and the hedged item or transaction, state the nature of the risk being hedged, and describe how hedge effectiveness will be assessed. Without it, the relationship cannot use hedge accounting, however sound the hedge is economically.

**Q: What must be documented at hedge inception?**

At inception you generally have to document five things: the risk management objective and strategy for undertaking the hedge; identification of the hedging instrument; identification of the hedged item or transaction; the nature of the risk being hedged; and the method you will use to assess whether the hedge is effective. The critical word is inception — the documentation has to be in place at the start of the relationship, before the fact, not written up afterwards once you know how the hedge performed.

**Q: What happens if hedge documentation is incomplete?**

Incomplete or late documentation disqualifies the relationship from hedge accounting. The hedge still works economically — nothing changes about the protection — but the derivative goes back to being marked to market through profit and loss on its own timing, while the item it hedges sits on a different timing. The result is exactly the artificial P&L volatility hedge accounting exists to remove. Documentation failures are a process problem, not a hedging problem, and they are one of the most common ways companies lose hedge accounting.

---

# FX Hedging Strategy: How Much to Hedge and When

Source: https://gravam.com/blog/fx-hedging-strategy
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-08
Summary: FX hedging strategy: deciding your hedge ratio, tenor and timing — how much of an exposure to hedge, over what horizon, and static versus layered.

**An FX hedging strategy is the decision that comes _before_ the instrument: how much of an exposure to hedge, over what horizon, and when to put the hedge on.** Forwards, options and swaps are the tools — but knowing the tools tells you nothing about how much of a forecast to cover, or whether to hedge it all today or in slices over the year. That's strategy, and in my experience it's where most of the real FX pain lives. The instrument is usually the easy part.

_(This describes how hedging strategy is set — it isn't hedging or investment advice for any particular situation.)_

## Three questions before any instrument

Once you've [identified an exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) and you know [which instruments exist](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps), three strategy questions decide what you actually do:

- **How much?** What proportion of the exposure do you hedge — the _hedge ratio_.
- **How far?** Over what horizon, matched to which tenor.
- **When?** All at once, or built up over time — _static_ versus _layered_.

Answer those and choosing a forward or an option is almost mechanical. Skip them and the fanciest instrument in the world is just a well-executed guess.

## The hedge ratio: not automatically 100%

The first instinct is to hedge everything. It's usually wrong, for three reasons.

First, **hedging has a cost** — a premium, a locked-away upside, or the operational drag of running the position. Second, **forecasts are uncertain.** Much of what treasury hedges isn't a signed contract; it's a forecast of flows that may or may not arrive. Third — the one that catches people — **over-hedging creates a new exposure.** Hedge a forecast at 100% and if it doesn't materialise you're left holding a hedge with no underlying flow behind it. That's not risk reduction; that's a [speculative position](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) you built by accident.

So the ratio is a **deliberate policy choice**, tied to [risk appetite](https://gravam.com/blog/risk-appetite-and-limits-in-treasury). It's the same principle the whole discipline runs on: manage risk _within appetite, not to zero._ The ratio is where that principle gets a number — and [cash flow at risk](https://gravam.com/blog/cash-flow-at-risk-cfar) is the measure that tells you what the unhedged remainder could still do to you.

> Hedging 100% feels like caution, but a full hedge on an uncertain forecast is a bet the flow arrives. The hedge ratio is where "how much risk do we actually want to keep?" stops being a slogan and becomes a decision.

## Certainty tiers: hedge what you know, hedge less of what you don't

The natural way to set ratios is by how _certain_ the exposure is.

**Firm, committed exposures** — a signed contract, an invoiced receivable, a confirmed payable — can be hedged with confidence and at high ratios. You know the amount, the currency and roughly the date, so the hedge genuinely offsets a real flow. Once a flow is invoiced it is a booked balance, and hedging it is usually a [balance sheet hedge](https://gravam.com/blog/balance-sheet-fx-hedging) that needs no hedge accounting.

**Forecast exposures** are different. A pipeline of expected sales in six, nine, twelve months is real enough to plan around but not certain enough to hedge to the hilt. So the ratio steps down: a larger share of near-term, high-confidence forecasts, a smaller share the further out and less certain the flow. It's a sliding scale — high ratios on what's firm and close, tapering to low on what's distant and speculative. That taper is what stops a forecast hedge from quietly becoming the over-hedge described above.

## Layered hedging: average in, don't bet the day

Even with the ratio decided, there's the _when._ Put the entire hedge on in a single transaction and your effective rate is whatever the market did on that one morning. That's timing risk — you've concentrated the whole outcome onto one execution point.

**Layered (or rolling) hedging** answers that. Instead of hedging a year's exposure in one go, you build the position in **tranches over time** — a slice each month or quarter as the flows roll toward you. The rate you end up with is an _average_ of many execution points, not a wager on a single day. It smooths the effective rate, reduces timing risk, and dovetails with the certainty tiers: near-dated layers sit at higher ratios, distant ones start thin and thicken as the flow firms up. You're averaging _into_ rates rather than trying — and failing — to pick the perfect moment.

The alternative, **static hedging** — one decision, one execution, held to maturity — is simpler and can suit a single dated exposure. But for a rolling book of forecast flows, layering is what keeps one bad morning from defining a whole year.

## Tenor and the budget rate

Strategy also has to answer _how far out._ The tenor should **match the exposure and the planning cycle.** If you build your annual plan on an assumed exchange rate — a **budget rate** — then an unhedged year means every currency move drops straight through to variances against that plan. Hedging to protect the budget rate, over a horizon that lines up with the budget period, is what lets the plan hold. Match the hedge horizon to the flows _and_ to the cycle the business is managing against, so the hedge protects a number someone cares about rather than an arbitrary date.

## Governance: a rule, not a punt

None of this should live in one person's head. The strategy belongs in **policy**: target hedge ratios (often as ranges) per certainty tier, the tenors allowed, the instruments permitted, who approves what. That's what turns "hedge sensibly" into a rule — and ties every hedge back to a stated [risk appetite](https://gravam.com/blog/risk-appetite-and-limits-in-treasury) rather than a view on where the rate is going. It's also what keeps the discipline consistent when the person deciding changes. It's the same governance logic that underpins [the whole risk discipline](https://gravam.com/blog/what-is-treasury-risk-management), pointed specifically at the _how much_ and _how far_ of FX.

## Why hedge ratios drift without a policy

Most FX hedging pain is not the instrument. The forward mechanics are well understood; any decent bank or treasury system can execute them. The pain is an **unclear policy on how much and how far to hedge** — which is why this sits at the centre of [treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management), not off to the side as a booking detail.

When the ratio isn't written down, it drifts with whoever's deciding. A cautious treasurer hedges most of everything; the next one, or the same one after a run of favourable moves, quietly lets it slide. The tenor lengthens or shortens with the mood of the last board meeting. And because each decision looks reasonable in isolation, nobody notices that the "strategy" has become a **series of ad-hoc calls** with no through-line. The documentation says there's a hedging strategy. The reality is a pattern you can only see looking backward.

The fix isn't a cleverer instrument. It's writing the ratios and tenors down, tying them to appetite, and treating a deviation as a decision that must be justified — not a mood. Get the _how much_ and _when_ onto paper, and the instrument choice becomes the small, boring last step it should always have been. None of it works on bad inputs, though: a hedge is only as right as the [exposure data](https://gravam.com/blog/treasury-exposure-data-quality) it's sized against.

***

_See also [FX risk exposure types](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) and [FX hedging instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps)._

## Questions this article answers

**Q: What is an FX hedging strategy?**

An FX hedging strategy is the set of decisions that sit before you pick an instrument: how much of an exposure to hedge (the hedge ratio), over what horizon or tenor, and when to put the hedge on (all at once, or built up over time). It turns a pile of exposures and available instruments into a deliberate, repeatable approach — how much, how far and how — tied to the company's risk appetite and written into policy, rather than a series of ad-hoc calls. The instrument is the last decision, not the first.

**Q: What is a hedge ratio?**

A hedge ratio is the proportion of an exposure you choose to hedge — for example hedging most of a committed receivable and a smaller share of a less certain forecast flow. It is a deliberate policy choice, not automatically 100%. Hedging has a cost, forecasts are uncertain, and over-hedging a forecast that doesn't materialise turns the hedge into a speculative position, so the ratio is set to keep risk within appetite rather than to eliminate it entirely.

**Q: What is layered hedging?**

Layered or rolling hedging means building a hedge in tranches over time instead of putting the whole position on in one go. You add a slice as each period approaches, so your effective rate is an average of many execution points rather than a bet on one day's rate. It smooths the rate you achieve, reduces timing risk, and lets you hedge nearer flows at higher ratios and more distant, less certain flows at lower ones.

---

# Value at Risk (VaR) in Corporate Treasury

Source: https://gravam.com/blog/value-at-risk-var-in-treasury
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: What Value at Risk is, how it's calculated, and why corporate treasuries use it to size market risk — plus the limits that make VaR only half the picture.

**Value at Risk (VaR) is a statistical estimate of the largest loss a portfolio is expected to suffer over a set horizon at a given confidence level — a way of squeezing the market risk in a whole book of positions into a single, comparable number.** It answers a specific question: under normal conditions, how bad might a bad day get? Used well, it's a genuinely useful lens on [interest rate](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) and [FX exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure). Used naively, it lulls people into thinking one number captures a risk it was never designed to describe.

_(This is a plain explanation of a risk measure, not investment or hedging advice for any particular situation.)_

## What VaR actually is

VaR has two parameters, and you can't quote it without both: a **horizon** (how far ahead — one day, ten days, a month) and a **confidence level** (how sure — 95%, 99%). Fix those, and VaR is the loss threshold you don't expect to breach.

The canonical example: a **95%, one-day VaR of $2m** means that, under normal market conditions, on roughly 95% of days the loss on that portfolio should not exceed $2m. Flip it around and it's easier to feel: on about 1 day in 20, you'd expect to lose _more_ than $2m. That's the whole idea — one figure that says "this is roughly [the edge of an ordinary bad day](https://gravam.com/blog/stress-testing-and-scenario-analysis-treasury)."

What makes it powerful is aggregation. A treasury book might hold a dozen currencies, several rate exposures and a handful of instruments. VaR rolls all of that — including how the pieces move together — into one number you can track over time and compare across desks. (How that rolling-up works across exposures, entities and instruments is its own discipline — [treasury risk aggregation and reporting](https://gravam.com/blog/treasury-risk-aggregation-and-reporting).) That single-number quality is exactly why boards like it, and also exactly why it's dangerous.

## The three ways to calculate it

There are three standard methods. They chase the same number and differ mainly in what they assume and how much machinery they need.

- **Historical simulation.** Take your _current_ positions and re-price them using the _actual_ market moves from a past window — say the last year or two of daily changes. Sort the resulting hypothetical gains and losses and read off the loss at your chosen percentile. It makes no assumption about the shape of the distribution; its weakness is that it assumes the future looks like the window you picked.
- **Variance-covariance (parametric).** Assume the risk factors' returns are normally distributed, then derive VaR from their volatilities and the correlations between them. It's fast and light — but the normal-distribution assumption understates the fat tails real markets have, so it tends to be optimistic about extreme moves.
- **Monte Carlo simulation.** Generate thousands of random market scenarios from an assumed statistical model, re-price the whole portfolio in each, and read the percentile off the simulated distribution. It's the most flexible — it copes with non-linear instruments the other two struggle with — and the most computationally expensive, and it's still only as good as the model you feed it.

None of these is "correct." Each trades a different assumption for a different convenience, and a number that changes depending on which method you chose is a number to treat with respect, not reverence.

## What treasury uses it for

In a corporate treasury, VaR earns its keep in a few concrete places. It **sizes market risk** across an FX or interest-rate portfolio, turning "we're exposed to a lot of currencies" into a figure you can act on. It's a natural **board and management reporting** metric — one line that says how much market risk the company is carrying this quarter versus last. And it underpins **risk limits**: a policy can state that portfolio VaR must stay under an agreed ceiling, giving treasury an objective, monitorable boundary rather than a matter of judgement. That limit-setting role is where VaR fits into the broader [treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management) framework — it's a measurement tool serving a governance job.

> VaR tells you where the edge of an ordinary bad day sits. It tells you nothing about the cliff on the other side — and it's the cliff, not the edge, that sinks companies.

## Where VaR falls short

This is the part the marketing brochures skip, and the part worth saying out loud.

**It says nothing about the tail.** A 95% VaR is a threshold; it is silent on how bad the worst 5% of outcomes get. Two portfolios can share the same VaR while one loses a little beyond it and the other loses catastrophically. The losses that actually threaten a business live in that tail — precisely where VaR stops describing anything.

**It's backward-looking.** Historical and parametric methods assume the future resembles a chosen slice of the past. In calm markets that makes VaR complacent; when a regime changes, it lags, and the number stays reassuring right up until it isn't. VaR is a rear-view mirror with a confidence interval.

**It's assumption-sensitive.** The horizon, the confidence level, the length of the data window, the assumed distribution — change any of them and the number moves, sometimes a lot. A figure that malleable demands you understand the choices behind it, not just the output.

Which is why corporates often lean on **cash-flow-based measures** instead of a bank-style VaR. A bank runs trading books marked to market daily; a market-value loss distribution is the right language for it. A corporate mostly cares whether tomorrow's cash flows survive a rate or currency move — an operating question, not a mark-to-market one. That's the pitch of [Cash Flow at Risk](https://gravam.com/blog/cash-flow-at-risk-cfar), the corporate-friendly companion to VaR: same statistical idea, aimed at cash flows and earnings rather than portfolio value, which is usually what a treasurer is actually trying to protect.

## How to hold it

Treat VaR as one instrument on the panel, not the whole dashboard. It's excellent for comparing risk over time, aggregating a messy book into one figure, and anchoring a limit. It's useless as a promise about disasters. Pair it with stress tests and scenario analysis for the tail it ignores, quote it always with its horizon and confidence level, and know which method produced it. Do that, and VaR becomes what it was meant to be — a disciplined summary of ordinary risk, sitting inside the wider [treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management) framework rather than pretending to be all of it.

***

_See also [Cash Flow at Risk (CFaR)](https://gravam.com/blog/cash-flow-at-risk-cfar) and [interest rate risk in corporate treasury](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury)._

## Questions this article answers

**Q: What is Value at Risk?**

Value at Risk (VaR) is a single-number estimate of the maximum loss a portfolio is expected to suffer over a set time horizon at a given confidence level, under normal market conditions. A 95%, one-day VaR of $2m means that on roughly 95% of days the loss should not exceed $2m — or, put the other way, on about 1 day in 20 you'd expect a loss larger than that. It always has two parameters: a horizon (how far ahead) and a confidence level (how sure). It's a way of compressing the market risk in an entire book of positions into one comparable figure.

**Q: How is VaR calculated?**

VaR is calculated by one of three standard methods. Historical simulation re-prices your current positions using actual market moves from a past window and reads the loss at the chosen percentile. The variance-covariance (parametric) method assumes returns are normally distributed and derives VaR from the volatilities and correlations of your risk factors. Monte Carlo simulation generates thousands of random market scenarios from an assumed statistical model and re-prices the portfolio in each. All three aim at the same number; they differ in their assumptions and in how much computation and modelling they demand.

**Q: What are the limitations of VaR?**

VaR tells you a threshold, not what lies beyond it — a 95% VaR says nothing about how bad the worst 5% of days actually get, which is exactly the tail that hurts. It's backward-looking: historical and parametric methods assume the future resembles a chosen past window, so it underestimates risk in calm markets and lags regime changes. It's highly sensitive to its assumptions — the horizon, confidence level, data window and distribution you pick all move the answer. For those reasons many corporates lean on cash-flow-based measures rather than treating a bank-style VaR as the whole story.

---

# Risk Appetite and Risk Limits in Treasury

Source: https://gravam.com/blog/risk-appetite-and-limits-in-treasury
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-29
Reviewed: 2026-09-02
Summary: Treasury risk appetite is how much financial risk a company chooses to bear; risk limits are the measurable guardrails that enforce it — why both matter.

**Risk appetite is how much of each financial risk a company deliberately chooses to bear; risk limits are the measurable guardrails that hold it to that choice.** Appetite is the intent, set at the top — how much foreign exchange, interest rate, counterparty and liquidity risk the business is willing to carry to pursue its goals. Limits are the concrete numbers that turn that intent into something a treasurer can actually check a decision against. Get the pair right and you have the foundation of a workable [treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy); get either wrong and the whole thing floats.

_(This is a plain explanation of governance concepts, not investment or hedging advice for any particular situation.)_

## Appetite is a choice, not a default

Across SAP FI/TRM projects and treasury desks, the thing I've most often seen skipped is the deliberate part. A company will hedge, set exposure caps, run reports — and never actually _decide_ how much risk it wants to carry. The appetite ends up being whatever the accumulated habits of the desk happen to produce.

Risk appetite is the opposite of that: the explicit statement that says, for each financial risk, _we are willing to bear this much of it to pursue our objectives_. Not zero — the point of the [identify-measure-manage-monitor discipline](https://gravam.com/blog/what-is-treasury-risk-management) is to keep risk within appetite, not to chase an impossible and expensive zero. A business that hedges everything has spent real money to forgo every favourable move as well as every unfavourable one. So appetite is a genuine choice with a cost on both sides, and that's why it belongs at board or treasury-committee level rather than on the desk. The people taking the risk should not be the ones deciding how much of it is acceptable.

That's the governance line that matters: **appetite is set above the desk; the desk operates within it.** Keep that separation and risk-taking stays deliberate. Blur it and appetite becomes a description of whatever treasury already does — which is not a control, it's a rationalisation.

## Limits are appetite made measurable

An appetite statement on its own is untestable. "We are conservative about currency risk" tells a treasurer nothing they can act on at 4pm with a live exposure in front of them. Limits are what fix that — the concrete, measurable boundaries that operationalise the appetite:

- **Hedge-ratio ranges** — hedge between X and Y percent of a given exposure, so the desk has a band to work within rather than a single brittle target. Where inside the band to sit, by certainty of the exposure and over what horizon, is the [FX hedging strategy](https://gravam.com/blog/fx-hedging-strategy) that sits under the limit.
- **VaR or CFaR limits** — a cap on modelled loss, using [value-at-risk](https://gravam.com/blog/value-at-risk-var-in-treasury) for market positions or [cash-flow-at-risk](https://gravam.com/blog/cash-flow-at-risk-cfar) for exposures measured against cash flows.
- **Counterparty exposure limits** — a maximum amount placed with any single bank or trading partner, plus minimum credit standards, so [counterparty and credit risk](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) stays diversified.
- **Maturity and tenor limits** — bounds on how far out positions or investments can run, so the book doesn't quietly extend its own risk horizon.
- **Minimum liquidity buffers** — a floor of available cash or committed facilities below which the company won't let itself drop.

The relationship is direct: **appetite is the intent, limits are the guardrails.** Each limit should be traceable back to a line in the appetite — if you can't say which piece of appetite a given limit enforces, either the limit is arbitrary or the appetite is too vague to have produced it. That traceability is the test of whether the two are actually connected or just filed in the same binder.

> Appetite without limits is a slogan — it can't stop or approve anything. Limits without appetite are arbitrary numbers nobody can defend when they bite. The work is in the arrow between them: making the limits genuinely follow from the appetite.

### Limits in operation: what a breach should trigger

A limit only earns its place if a breach leads to a _defined action_ — otherwise it's a number nobody enforces. This matrix maps each limit to the decision it supports and the operating action a breach should trigger:

| Limit | What it controls | A breach signals | Operating action |
| --- | --- | --- | --- |
| **Hedge-ratio range** | How much exposure is covered | Coverage drifted outside the band | Rebalance to the band; escalate if you can't |
| **VaR / CFaR limit** | Modelled loss taken | Risk exceeds appetite | Reduce the position, or get explicit approval to hold |
| **Counterparty limit** | Concentration with one name | Too much placed with a single bank | Move exposure out; block new until back within |
| **Tenor / maturity limit** | How far risk runs | The book is extending its own horizon | No new long-dated positions; review existing |
| **Liquidity buffer floor** | Minimum available cash | The cushion is breached | Trigger funding / escalation immediately |

The operating discipline behind the table is a **breach process** every limit shares: detect the breach, notify a named owner, decide (cure it, or approve an exception with a reason and a time limit), and record it. A limit with no breach process is monitoring theatre — it measures a boundary nobody is obliged to act on. Define the action _before_ the breach, so the 4pm decision is a lookup, not an argument.

## How appetite and limits reach the policy

Appetite and limits don't stand on their own — they feed something. The chain runs **appetite → limits → policy**, and then monitoring closes the loop. The [treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy) is where appetite and limits get codified with authority: written down, approved, made to apply regardless of who's on the desk that day. That's why this article builds toward the policy rather than duplicating it — the policy is where these choices become enforceable rules alongside permitted instruments, approvals and segregation of duties.

Then the loop closes with **monitoring and breach escalation.** A limit is only real if something checks it and something happens when it's crossed. Monitoring compares live exposures against the limits; a breach triggers a defined escalation path — reported, explained, either brought back inside the limit or formally accepted as an exception at the right level. Without that closing step, a limit is just a suggestion. For liquidity in particular, that path deserves designing in full — a [liquidity escalation framework](https://gravam.com/blog/liquidity-escalation-framework) with thresholds, tiers, actions and owners — because a squeeze is the worst moment to improvise one.

So the ownership map is clean: the **board sets appetite**, **treasury operates within limits**, and **breaches escalate** back up to the level that owns the appetite. Everyone knows which decisions are theirs.

## Appetite statements that never become limits

Here's where the gap between the framework and the filing cabinet usually opens.

The first failure mode is the **appetite statement nobody translated into limits.** It reads well in the board pack — measured, prudent, appropriately serious — and it changes nothing, because no treasurer can act on "we are prudent about FX." It's decoration. I've reviewed appetite statements that were genuinely thoughtful and completely inert, because the arrow to hard limits was never drawn.

The second is worse: **limits nobody monitors.** An unmonitored limit is more dangerous than no limit at all, because it manufactures false comfort. The board believes risk is bounded; the reports say a limit exists; and meanwhile the book has drifted past it with nothing watching. No limit at least keeps everyone honest that the exposure is unmanaged.

And the most common failure of all, the quiet one: **limits set once and never revisited.** The business grows, enters new currencies, takes on new debt, changes its whole risk profile — and the limits still reflect the company as it was three years ago. They're not wrong on the day they're written; they rot. The [review cycle](https://gravam.com/blog/treasury-risk-management-policy) keeps appetite and limits aligned with the business they govern, and it's the step that gets dropped first because nothing appears to break when you skip it — until it does.

## Getting it right

Decide the appetite deliberately, at the level that owns the business, for each financial risk. Translate it into limits you can measure and a treasurer can test a decision against — and make each limit traceable back to the appetite it enforces. Codify both in the [treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy) so they bind regardless of who's deciding. Then monitor, and escalate breaches, so the numbers stay real. Do that and you have deliberate, bounded, controlled risk-taking. Skip any link and you have a document that describes control without providing it.

***

_See also [the treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy) and [counterparty and credit risk in treasury](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury)._

## Questions this article answers

**Q: What is risk appetite in treasury?**

Risk appetite is the deliberate statement of how much of each financial risk — foreign exchange, interest rate, counterparty, liquidity — a company is willing to bear in pursuit of its objectives. It's a choice, not an accident: management and the board decide how much uncertainty they'll accept rather than hedge away, recognising that removing all risk is both impossible and expensive. Appetite is set at board or treasury-committee level, and it's the anchor everything else in treasury risk management is measured against.

**Q: What is the difference between risk appetite and risk limits?**

Risk appetite is the intent — the high-level statement of how much financial risk the company is willing to bear. Risk limits are the concrete, measurable boundaries that operationalise that intent: hedge-ratio ranges, value-at-risk or cash-flow-at-risk caps, counterparty exposure limits, maturity limits, minimum liquidity buffers. Appetite says 'we'll tolerate this much'; limits are the numbers a treasurer actually checks a decision against. Appetite without limits is a slogan; limits without appetite are arbitrary. You need both, and the limits have to genuinely follow from the appetite.

**Q: Who sets treasury risk appetite?**

Risk appetite is owned at board or treasury-committee level, not by the treasury desk. It's a governance decision about how much financial uncertainty the business as a whole is prepared to carry, so it belongs with the people accountable for the business, informed by treasury's analysis. Treasury then operates within the limits that flow from that appetite, and escalates when a limit is breached. Keeping appetite-setting above the desk is what stops the people taking the risk from also deciding how much is acceptable.

---

# Interest Rate Hedging: Swaps, Caps, Collars and FRAs

Source: https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: The instruments treasury uses to hedge interest rate risk — swaps fix the rate, caps insure against rises, collars fund the cap, FRAs lock a single period.

**The main instruments treasury uses to hedge interest rate risk are swaps, caps, floors, collars and forward rate agreements.** A **swap** exchanges floating-rate payments for fixed, locking the rate. A **cap** is an option that pays out when rates rise above a strike — insurance against rising rates. A **floor** is its mirror for an investor. A **collar** combines the two to fund the protection. An **FRA** locks a rate for one future period. Each shapes the same underlying exposure differently, and — as with [FX instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) — the point is to offset a real exposure, not to take a view on rates for its own sake.

_(This describes what the instruments do and how they hedge — it isn't a recommendation to use any particular one.)_

## The exposure, recapped

Floating-rate debt is the classic problem. You borrow at a [reference rate](https://gravam.com/blog/interest-rate-benchmark-reform-libor-sofr) plus a margin, and every time the reference resets your interest cost moves with it — a rise in rates lifts your cost with no cap on how far it goes. That's the core of [interest rate risk in corporate treasury](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury): your borrowing cost, or your investment income, is at the mercy of a rate you don't control. The instruments below don't remove that exposure — they let you **fix** it, put a **ceiling** on it, or **shape** it into something you can live with.

## Swaps: fixing the rate

An **interest rate swap** exchanges one interest stream for another on a notional amount, under the [ISDA documentation](https://gravam.com/blog/isda-csa-and-collateral-management) that governs such over-the-counter trades. The common corporate case is the **payer swap**: you pay fixed and receive floating. Run against a floating-rate loan, the floating leg you receive cancels the floating interest you owe on the loan, and you're left paying a net fixed rate.

- **Gives:** an effective fixed rate — certainty on your interest cost.
- **Costs:** no upfront premium.
- **Trade-off:** it's an _obligation_. If rates fall, you keep paying the fixed rate and forgo the saving. Certainty cuts both ways — the same trade-off a [forward](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) makes on an FX rate.

A swap suits a **committed, ongoing exposure** — term debt you intend to hold, where you want the interest cost known and off the table.

## Caps: a ceiling, with the downside kept

An **interest rate cap** is an option. You pay an upfront **premium**, and in return the cap pays out whenever the reference rate resets above an agreed **strike**. Below the strike it does nothing and you simply pay the floating rate; above it, the payout offsets the excess, so your effective cost is capped.

- **Gives:** protection against rising rates _and_ the full benefit if rates fall — you stay on the floating rate below the strike.
- **Costs:** an upfront premium, whether or not it ever pays out.
- **Trade-off:** you pay for that flexibility, exactly as you would for an [FX option](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps).

A cap suits a borrower who wants to sleep at night about a rate spike but doesn't want to lock away the benefit of falling rates — insurance, not a fixed price.

> A swap fixes your rate and takes the whole question off the table. A cap only removes the bad tail and leaves you the good one — which is exactly what you pay the premium for.

## Floors: the mirror

A **floor** is the cap turned around. It pays out when the reference rate falls _below_ a strike, protecting a party that _receives_ floating income — a floating-rate investor or lender — against rates dropping too far. Same option mechanics, opposite direction: a floor guards income the way a cap guards cost.

## Collars: funding the protection

A **collar** combines the two: you **buy a cap** and **sell a floor**. The premium you receive for selling the floor offsets — partly or entirely — the premium you pay for the cap, which is why a collar can be arranged at low or even zero upfront cost.

The catch is what you gave up to get there. Having sold the floor, you no longer keep the _full_ benefit if rates fall: below the floor strike you effectively pay the floor rate, because the floor you sold now pays out against you. So a collar fixes your cost into a **band** — a ceiling from the cap you bought, a lower bound from the floor you sold.

- **Gives:** capped cost with little or no upfront premium.
- **Costs:** you surrender the benefit of rates falling below the floor.
- **Trade-off:** the cheap middle ground between a swap and a naked cap — cheaper than the cap, more flexible than the swap, but no longer a free ride on falling rates.

## FRAs: locking one period

A **forward rate agreement** locks a rate for a **single future interest period**. You agree today the rate that will apply to a notional over one specified period ahead; at settlement, the difference between that agreed rate and the actual reference rate is paid one way or the other. Where a swap is effectively a strip of many periods fixed at once, an FRA fixes just one — useful for a specific dated exposure, like a known borrowing that falls in one future window.

## Swaptions: an option on the swap

A **swaption** is an option to _enter_ a swap at a future date on pre-agreed terms. It suits a conditional need — a borrowing that may or may not go ahead, where you want the right to lock a rate later without committing to the swap now. It's the same "right, not obligation" logic as a cap, applied to the swap itself.

## At a glance

|  | Swap | Cap | Collar | FRA |
| --- | --- | --- | --- | --- |
| **What** | Fix floating to fixed | Ceiling above a strike | Cap bought, floor sold | Fix one future period |
| **Upfront cost** | None | Premium | Low / zero | None |
| **Keeps downside benefit?** | No | Yes | Only above the floor | No |
| **Best for** | Committed term debt | Want a ceiling, keep upside | Cheap capped band | Single dated exposure |

## Choosing between them

There's no formula that picks the instrument — it comes down to your **view** on rates and your **appetite** for the downside:

- **Swap** — certainty, no premium, but no upside. You want the rate known and are content to give up the benefit of a fall.
- **Cap** — flexibility, at the cost of a premium. You want a ceiling but insist on keeping the benefit if rates drop.
- **Collar** — the cheap middle. Little or no premium, a capped cost, but you trade away the deep-downside benefit to fund it.

None of these is "best". The swap buyer who'd have saved on a cap and the cap buyer who paid a premium rates never justified both made defensible calls with the information they had. What isn't defensible is reaching for an instrument with **no underlying exposure** behind it — that's a rate bet, not a hedge, and exactly what [risk policy](https://gravam.com/blog/what-is-treasury-risk-management) exists to prevent.

## The accounting tail

Hedging these exposures has consequences on the books. A swap or cap carries a fair value that moves every period, and without the right treatment that volatility lands in your P&L even when the hedge is doing precisely its job — which is the whole reason [hedge accounting](https://gravam.com/blog/hedge-accounting-explained) exists. Decide the hedge and the accounting treatment together — including whether it will pass [effectiveness testing](https://gravam.com/blog/hedge-effectiveness-testing) — not months apart. (A quick sanity check with the [Hedge Effectiveness Checker](https://gravam.com/tools/hedge-effectiveness-checker) on expected fair-value changes costs minutes and can save a failed designation.)

## Hidden costs in swaps, caps and collars

- **Swapping debt you won't hold.** Fixing a rate on borrowing you refinance or repay early leaves a swap stranded against an exposure that's gone.
- **Treating a swap as free.** No premium doesn't mean no cost — you've locked away every benefit of a fall.
- **Buying caps and ignoring the premium.** The protection is real, but the premium is a genuine cost that has to be weighed against the risk it removes.
- **Selling a floor without pricing what you gave up.** A zero-cost collar isn't free — you sold the downside benefit to pay for the cap.
- **Hedging without an underlying exposure.** The cardinal error, same as in FX: an instrument that isn't offsetting a real rate exposure is a position, not a hedge.

Match the swap to committed debt, the cap to a borrower who wants a ceiling but keeps the downside, the collar to one who wants that ceiling cheaply, and the FRA to a single dated period — keep every instrument tied to a real exposure and sized to it, and interest rate hedging does its job: shaping a cost you don't control into one you can plan around, without turning treasury into a rate-trading desk.

***

_See also [interest rate risk in corporate treasury](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) and [what treasury risk management is](https://gravam.com/blog/what-is-treasury-risk-management)._

## Questions this article answers

**Q: What instruments hedge interest rate risk?**

The main ones are interest rate swaps, caps, floors, collars and forward rate agreements (FRAs). A swap exchanges floating-rate payments for fixed, locking the rate. A cap is an option that pays out when the reference rate rises above a strike, acting as insurance against rising rates for an upfront premium. A floor does the mirror for a floating-rate investor. A collar combines a bought cap with a sold floor to reduce or eliminate the premium. An FRA locks a rate for a single future interest period. Swaptions — options on a swap — sit alongside these for more conditional needs.

**Q: What is an interest rate swap?**

An interest rate swap is an agreement to exchange one stream of interest payments for another on a notional amount, most commonly floating for fixed. A borrower with floating-rate debt enters a payer swap — paying fixed and receiving floating — so the received floating leg offsets the floating interest on the underlying loan, leaving a net fixed cost. It locks the effective interest rate with no upfront premium, but it is an obligation: if rates fall, you are still paying the fixed rate and give up the benefit.

**Q: When would you use a cap instead of a swap?**

You use a cap when you want protection against rising rates but want to keep the benefit if rates fall — and you are willing to pay an upfront premium for that flexibility. A swap fixes your rate completely: certainty, no premium, but no upside if rates drop. A cap sets a ceiling while leaving you on the floating rate below it, so you still gain if rates fall. The choice comes down to your rate view and your appetite: a swap for certainty, a cap when you value keeping the downside.

---

# Hedge Effectiveness Testing and the Hedge Ratio

Source: https://gravam.com/blog/hedge-effectiveness-testing
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Hedge effectiveness testing proves your hedge offsets the hedged risk — the evidence you need to keep hedge accounting and avoid artificial P&L swings.

**Hedge effectiveness testing is how you prove a hedge actually offsets the risk it's meant to hedge — the evidence that lets you keep [hedge accounting](https://gravam.com/blog/hedge-accounting-explained).** The companion piece explains what hedge accounting is and why it exists; this one drills into the gate you have to pass to use it. Get it wrong and the consequence is concrete: you lose hedge accounting for that relationship, the hedge's gains and losses stop lining up in the P&L with the item they cover, and you get the artificial profit volatility hedge accounting was supposed to remove. I've watched effectiveness testing be the quiet difference between a hedge book that reports cleanly and one that generates surprise swings every quarter-end.

_(This is a plain explanation of effectiveness testing, not accounting advice for a specific situation — the exact rules live in standards like IFRS 9 and their equivalents, and applying them to your book needs your accountants.)_

## Why effectiveness matters at all

Hedge accounting is a privilege, not a default. To defer or relocate a hedge's gains and losses so they hit profit _together_ with the hedged item, you have to demonstrate the two really do offset. That demonstration is effectiveness testing. It's the price of admission I described in the [companion article](https://gravam.com/blog/hedge-accounting-explained): [formal inception documentation](https://gravam.com/blog/hedge-documentation-requirements), plus ongoing evidence that the relationship keeps working.

The stakes are asymmetric. A hedge that's economically sound still fails hedge accounting if you can't _evidence_ the offset — and once it fails, the derivative goes back to being marked to market through P&L on its own timing while the hedged item sits somewhere else. You did the right thing economically and got punished in the reported numbers. That's the outcome effectiveness testing exists to prevent, and it's why treasurers who never touch the accounting still need to understand it.

## The hedge ratio

At the centre of the test sits the **hedge ratio**: the quantity of hedging instrument relative to the quantity of hedged item. Hedge 80 units of a 100-unit exposure and your ratio is 80:100. The rule that matters under current standards is simple to state and easy to get wrong: the ratio must reflect **what you actually do** to manage the risk. You can't set a ratio to flatter the test — say, deliberately over- or under-hedging on paper to land a number in a comfortable range — if it isn't the ratio your risk management genuinely uses. The hedge ratio is meant to describe reality, not to be tuned for a pass.

## IFRS 9: principles, not a bright line

Here's the point people most often get wrong. Under **IFRS 9**, the standard in force today, there is **no mandated 80-125% offset band**. IFRS 9 replaced the old quantitative bright line with a principles-based test. A hedge qualifies when three conditions hold:

- there's an **economic relationship** between the hedging instrument and the hedged item — they move against each other because of the shared risk;
- **credit risk does not dominate** the value changes arising from that relationship; and
- the **hedge ratio** reflects the quantities the entity actually uses for risk management — for currency hedges, the ratio your [FX hedging strategy](https://gravam.com/blog/fx-hedging-strategy) actually sets, not one reverse-engineered for the test.

Notice what's absent: any single number you have to hit. You still often _do_ quantitative work under IFRS 9 — to size ineffectiveness, which still has to be measured and recorded — but passing no longer means landing inside a fixed band.

## The old 80-125% bright line

So where does 80-125% come from? It's the strict quantitative test from **IAS 39**, IFRS 9's predecessor: a hedge was "highly effective" only if offset fell within 80% to 125%. That regime is gone under IFRS, but the number refuses to die, for two reasons. First, habit — a generation of treasury and accounting staff learned "80-125%" as _the_ effectiveness rule and still reach for it reflexively. Second, geography: **US GAAP (ASC 815)** requires a hedge to be "highly effective" at inception and on an ongoing basis — a threshold the standard itself never quantifies, but which US practice has long read as offset of at least 80% and no more than 125%, assessed both prospectively and retrospectively. So if you work across IFRS and US GAAP books, or with colleagues who trained under IAS 39, you'll hear 80-125% quoted as gospel. Under IFRS 9 it isn't the rule — treat it as historical and comparative context, not a test you must pass. One US GAAP nuance: since ASU 2017-12, an entity whose initial quantitative test shows the hedge is highly effective, and that can reasonably support an expectation of high effectiveness, can elect hedge by hedge — documented at inception — to assess it qualitatively afterwards. So the 80–125% calculation is often run at inception and then only again if the facts change, not every quarter.

## Prospective vs retrospective, qualitative vs quantitative

Two distinctions worth one honest line each:

- **Prospective vs retrospective.** Prospective testing is forward-looking — at inception and thereafter, is the hedge _expected_ to offset? Retrospective testing looks back — did it? IAS 39 demanded both; IFRS 9's forward-looking principles reshaped this, though you still assess the relationship on an ongoing basis and measure realised ineffectiveness.
- **Qualitative vs quantitative.** A **qualitative** assessment reasons that terms match closely enough that offset is clear without arithmetic; **quantitative** methods put a number on it — **dollar-offset** (compare the value change of instrument and item directly) or **regression** (test the statistical relationship across scenarios). Simpler hedges can often be argued qualitatively; messier ones need the maths. If you want to see the maths on your own numbers, the [Hedge Effectiveness Checker](https://gravam.com/tools/hedge-effectiveness-checker) takes each period's fair-value changes and gives you the dollar-offset ratio against the 80–125% reference band, plus a regression.

## A worked dollar-offset example

Numbers make the whole debate concrete. Take a fair-value hedge and track the **cumulative** fair-value changes of the hedged item and the hedging instrument over three quarters. The dollar-offset ratio is the instrument's cumulative change divided by the item's, signs stripped:

| Period | Cumulative Δ FV, hedged item | Cumulative Δ FV, instrument | Dollar-offset ratio | IAS 39's 80–125% band |
| --- | --- | --- | --- | --- |
| Q1 | +100,000 | −92,000 | 92.0% | inside |
| Q2 | +140,000 | −130,000 | 92.9% | inside |
| Q3 | +25,000 | −19,000 | 76.0% | **outside** |

Q1 and Q2 are unremarkable: 92,000 ÷ 100,000 = 92.0% and 130,000 ÷ 140,000 = 92.9%, comfortably inside the band. Then look at what actually happened in Q3: the market largely round-tripped, so both cumulative changes collapsed toward zero — and a residual mismatch of 6,000 that was invisible against 140,000 is enormous against 25,000. The offset arithmetic reads 19,000 ÷ 25,000 = 76.0%.

Under **IAS 39**, that's a failed retrospective test: outside 80–125%, so hedge accounting is not permitted for that period — even though nothing about the hedge's economics changed. This "small numbers" failure, where a shrinking denominator fails a sound hedge on a technicality, is precisely the criticism that pushed the IASB toward principles. Under **IFRS 9**, the same figures get a different question: is there still an economic relationship, does credit risk dominate, is the hedge ratio still the one risk management actually uses? A small-denominator artefact doesn't, by itself, disqualify the hedge.

What doesn't change between the standards is measurement. In this fair-value hedge both legs are remeasured through P&L — the same P&L-to-P&L offset that lets [balance sheet FX hedging](https://gravam.com/blog/balance-sheet-fx-hedging) of monetary items run without designation at all — so the net difference lands there each period: +8,000 in Q1 (100,000 gain vs 92,000 loss), +2,000 in Q2, −4,000 in Q3 — a cumulative 6,000 of ineffectiveness in reported profit. The 6,000 is real either way; what the band decides is whether Q3's ratio also costs you the hedge accounting itself.

To run your own numbers through the same arithmetic, use the [Hedge Effectiveness Checker](https://gravam.com/tools/hedge-effectiveness-checker) — but note it takes one row per period and adds the rows up itself, so each row is that period's _movement_, not the running total. The table above is cumulative, so to reproduce it you'd enter the movements behind it: **+100,000 / −92,000**, then **+40,000 / −38,000**, then **−115,000 / +111,000**. Those are the same period moves as the P&L figures just above, they total the Q3 cumulative position, and the tool's cumulative line then reads 25,000 against 19,000 — the 76.0% again — with a regression view alongside.

## Where hedges actually leak: sources of ineffectiveness

Ineffectiveness is any way the instrument and the item fail to move together, and in real projects it's almost always a **mismatch**:

- **Timing** — the hedge settles on a different date from the hedged cash flow. The classic: a forward dated to a tidy month-end instead of the actual payment date.
- **Notional** — the hedged quantity and the instrument's notional don't line up, so part of the exposure is uncovered or the hedge overshoots.
- **Index or basis** — the instrument references a different rate, index or currency basis from the one the exposure is genuinely priced off, because that index was easier to trade.
- **Credit risk** — counterparty or own credit changes the instrument's value for reasons that have nothing to do with the hedged risk.

Docs-vs-reality: the documentation describes a clean, perfectly-matched relationship, and the test would sail through — but the _actual_ trade was booked to a convenient date against a standard index, because that's what was liquid the day it was executed. That gap between the documented hedge and the executed one is where I've seen effectiveness testing quietly fail. It's the same discipline the [instrument choice](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) demands, and it's why [natural hedging](https://gravam.com/blog/natural-hedging-vs-financial-hedging) — which offsets exposures inside the business with no instrument to mismatch — sidesteps the problem entirely for the exposures it can reach.

## Getting it right

Effectiveness testing isn't accounting box-ticking bolted onto treasury — it's the evidence layer that lets a genuinely good hedge report the way it economically behaves. Set the hedge ratio to match what you really do, understand that IFRS 9 asks for an economic relationship rather than a magic number, keep the executed trade honest to the documented one, and measure the ineffectiveness that remains. Do that and the test becomes a formality confirming what's already true. Skip it and you'll meet the volatility hedging was meant to remove. It all sits inside the broader discipline of [treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management), where the hedge decision itself always comes first.

***

_See also [hedge accounting explained](https://gravam.com/blog/hedge-accounting-explained) and [FX hedging instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps)._

## Primary sources

- IFRS 9 Financial Instruments, Chapter 6 (Hedge Accounting) — full text as adopted for use in the EU by Commission Regulation (EU) 2016/2067 of 22 November 2016, OJ L 323 — EU-adopted text, OJ L 323, 29.11.2016 — accessed 2026-08-19 — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R2067
- Deloitte — A Closer Look: Assessing hedge effectiveness under IFRS 9 (IAS 39's 80–125% band, prospective/retrospective tests, IFRS 9's three requirements, measurement of ineffectiveness) — accessed 2026-07-30 — https://iasplus.com/content/f9d7dadf-7b88-4be4-b047-87fbe1375b5c
- Deloitte Roadmap: Hedging — 2.5 Hedge Effectiveness (ASC 815 'highly effective' requirement and the 80–125% offset read in US practice) — accessed 2026-07-30 — https://dart.deloitte.com/USDART/home/codification/broad-transactions/asc815-10/hedge-accounting/chapter-2-hedge-accounting-requirements/2-5-hedge-effectiveness
- PwC Viewpoint — Derivatives and hedging guide, 9.12 Qualitative assessments of effectiveness (ASU 2017-12, ASC 815-20-35-2A to 35-2F) — accessed 2026-09-25 — https://viewpoint.pwc.com/dt/us/en/pwc/accounting_guides/derivatives_and_hedg/derivatives_and_hedg_US/chapter_9_effectiven_US/912_qualitative_asse_US.html

## Questions this article answers

**Q: What is hedge effectiveness testing?**

Hedge effectiveness testing is the evidence a company produces to show that a hedging instrument actually offsets changes in the hedged risk — the thing that keeps a hedge relationship qualifying for hedge accounting. It's done at inception (prospectively, to show the hedge is expected to work) and, depending on the standard, on an ongoing basis. Fail it, and you lose hedge accounting for that relationship, which usually means the hedge's gains and losses hit profit and loss on a different timing from the item being hedged, producing exactly the reported-profit volatility hedge accounting was meant to remove.

**Q: Did IFRS 9 remove the 80-125% rule?**

Yes. IFRS 9 replaced the old strict quantitative bright line — the 80% to 125% offset band from IAS 39 — with a principles-based effectiveness test. Under IFRS 9 a hedge qualifies if there is an economic relationship between the hedging instrument and the hedged item, credit risk does not dominate the value changes from that relationship, and the hedge ratio reflects the quantities the company actually uses to manage the risk. There is no mandated numeric pass band. The 80-125% figure lives on because people quote it out of habit and because a similar bright line still features in US GAAP (ASC 815) practice.

**Q: What causes hedge ineffectiveness?**

Ineffectiveness comes from any mismatch between the hedging instrument and the hedged item: different maturities or settlement dates (timing), a notional that doesn't line up with the exposure, a hedge referencing a different index or currency basis from the one that actually drives the exposure, and counterparty or own credit risk changing the instrument's value for reasons unrelated to the hedged risk. In real projects the usual culprits are practical: a forward dated to a convenient month-end rather than the actual cash flow date, or a standard index used because it was easy to trade rather than the one the exposure is genuinely priced off.

---

# Cash Flow at Risk (CFaR) Explained

Source: https://gravam.com/blog/cash-flow-at-risk-cfar
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-02
Reviewed: 2026-09-02
Summary: Cash Flow at Risk measures the worst shortfall in a company's cash flow versus plan over a period at a chosen confidence level — the corporate answer to VaR.

**Cash Flow at Risk (CFaR) measures the largest shortfall a company might see in its cash flow — or its earnings — over a defined period at a chosen confidence level.** It's the corporate-treasury cousin of Value at Risk, but it answers a different and, for most companies, far more useful question: not "how much could the mark-to-market value of our portfolio move today?" but "how bad could our cash flow be versus the plan we're relying on?" That shift — from portfolio value to cash against budget — is the whole point, and it's why CFaR fits a corporate treasury in a way that [VaR](https://gravam.com/blog/value-at-risk-var-in-treasury) often doesn't.

_(This is a plain explanation of a measurement concept, not investment or hedging advice for any particular situation.)_

## What CFaR actually measures

VaR was built for trading desks. It answers: over a short horizon — a day, a few days — how much could the value of this portfolio fall, at a given confidence level? That's the right question when your positions are revalued constantly and you can trade out of them in the morning.

A corporate treasury isn't a trading desk. Its exposures aren't tradeable positions revalued each night — they're the currency its sales come in, the floating rate on its debt, the cost of an input it buys ([commodity price risk](https://gravam.com/blog/commodity-price-risk)). What the business cares about is whether the _cash it planned for_ actually arrives. CFaR answers exactly that: over a period — usually a quarter or a year — what's the worst shortfall in cash flow (or earnings) we might realistically see against plan, at, say, a high confidence level? It's the same statistical machinery as VaR — a worst outcome at a confidence level — pointed at cash flow instead of portfolio value, and stretched over months instead of days.

The term isn't loose usage. RiskMetrics Group defined it in the _CorporateMetrics Technical Document_ (first edition, April 1999), alongside Earnings-at-Risk, as:

> Cash-Flow-at-Risk (CFaR). The maximum shortfall of net cash generated, relative to a specified target, that could be experienced due to the impact of market risk on a specified set of exposures, for a specified reporting period and confidence level.

Four things in that sentence are load-bearing, and each one is a place I've seen a CFaR go wrong. **Relative to a specified target** — it's a shortfall against a plan, not against zero, so if nobody agrees what the target is there is no measure. **Due to the impact of market risk** — it prices rates and prices moving, not customers paying late; that's a different discipline. **On a specified set of exposures** — the number covers what you put in it and nothing else. **For a specified reporting period and confidence level** — a CFaR quoted without both parameters is not a number, and the table below shows how far apart two legitimate answers can sit.

## Why it fits corporates better than VaR

I've watched treasuries try to run their FX and rate risk on a VaR number lifted from a bank, and it rarely tells them anything they can act on. The horizon is wrong, and the thing being measured is wrong.

Think about what a corporate is exposed to. Its foreign-currency revenues land over quarters. Its floating-rate interest cost accrues over the life of a facility. Its budget was built at a set of rates months before the cash shows up. None of that behaves like a trading book you mark to market at 5pm, so a one-day change in portfolio value is close to meaningless — the business will still be sitting on the same exposure tomorrow, and the day after.

CFaR lines up with how the business is actually run and funded. It's expressed in the currency of the plan: cash, earnings, budget rate. When a treasurer tells a CFO "at 95% confidence our cash flow won't come in more than _X_ below plan over the year," that's a sentence the CFO can do something with. A VaR figure on a notional portfolio usually isn't.

> VaR asks what your portfolio could lose overnight. CFaR asks what your cash flow could miss against plan over the year. For a company that lives on the second question, the first one is answering the wrong exam.

## CFaR vs VaR vs EaR

Three measures get used interchangeably in treasury conversations and they answer three different questions. The definitions below are the source documents' own — CFaR and EaR from CorporateMetrics, VaR from the RiskMetrics Technical Document that CorporateMetrics was built to complement.

| Measure | What it measures | Typical horizon | What's "at risk" | Whose question it answers |
| --- | --- | --- | --- | --- |
| **CFaR** — Cash-Flow-at-Risk | Shortfall in net cash generated versus a specified target, caused by market-rate moves | The plan's reporting period; CorporateMetrics targets 2 to 24 months or beyond | Cash against plan | The treasurer asking whether the cash the business is funded against actually turns up |
| **EaR** — Earnings-at-Risk | Shortfall in earnings versus a specified target, caused by market-rate moves | Same — the reporting period the target was set for | Reported earnings against plan (per share, it's EPSaR) | The CFO asking whether a number already given to the board survives the rates moving |
| **VaR** — Value-at-Risk | Fall in the mark-to-market value of a portfolio of financial instruments | One day or one month, as RiskMetrics frames it | Portfolio value, measured in absolute terms rather than against a target | The desk asking how much a book could lose before it can be traded out of |

The split that matters is the last two columns. CFaR and EaR are **relative** measures — risk against a target the business already committed to — while VaR is an **absolute** one, a loss against today's mark. That's why a bank-style VaR lands flat in a corporate meeting: nobody in the room is managing a mark. CFaR and EaR differ only in which line of the plan they protect, cash or earnings, and for a company where cash and recognised earnings land in different periods those two numbers genuinely differ — CorporateMetrics makes exactly that point about a payment terms lag between an expense and the cash that settles it.

## How it's estimated, at a high level

You don't need the formulas to understand the shape of it. The estimation runs in three conceptual steps:

1. **Model the exposures.** Lay out the things that turn market moves into cash-flow moves — [FX-denominated flows](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) (revenues, costs, intercompany settlements in foreign currency), floating-rate costs, and any other price the business is exposed to. This is where the forecast lives: CFaR needs a view of _what_ cash is expected, _when_, and _in what currency or rate_.
2. **Simulate market scenarios.** Generate a range of plausible futures for the relevant rates and prices — the currencies move, the reference rate moves — using whatever method fits (historical behaviour, a statistical model, [scenario sets](https://gravam.com/blog/stress-testing-and-scenario-analysis-treasury)). The point is to explore not one outcome but a distribution of them.
3. **Look at the distribution of resulting cash flows.** Push each scenario through the exposures and you get a spread of possible cash-flow outcomes against plan. CFaR is read off the bad tail of that distribution — the shortfall you wouldn't expect to exceed at your chosen confidence level.

That's the concept. The sophistication lives in how carefully you model exposures and simulate scenarios, but the intuition never changes: exposures plus scenarios gives a distribution of cash flows, and CFaR is how bad the tail of that distribution gets.

## A worked example, on assumed numbers

Those three steps describe a simulation, and a simulation needs a model. There's a parametric shortcut that doesn't, and it's worth knowing because it's how a first CFaR usually gets built — in a spreadsheet, before anyone has bought anything. Collapse the exposure to a single net amount, allow one risk factor, assume its returns are normally distributed, and the number falls out of a multiplication.

**The inputs below are assumed, for illustration. They are not a benchmark, not an observed market volatility, and not a recommendation** — the point is the arithmetic, not the figures.

Assume a euro-functional company with:

- **Net exposure over the next 12 months:** USD 40,000,000 of receipts, unhedged
- **Annualised volatility** assumed for the currency pair: 8%
- **Confidence level:** 95%, one-tailed, so z = 1.645

The formula is the parametric VaR formula pointed at a cash flow instead of a portfolio:

```text
CFaR ≈ net exposure × annualised volatility × √(horizon in months ÷ 12) × z
```

Over the full 12 months the square-root term is √(12 ÷ 12) = 1, so it drops out and two multiplications are left:

```text
40,000,000 × 0.08       = 3,200,000    ← one standard deviation, over a year
 3,200,000 × 1.645      = 5,264,000    ← the 95% one-tailed figure
```

**CFaR ≈ USD 5,264,000** — 5,264,000 ÷ 40,000,000 = 13.2% of the exposure. Quote it the way the definition demands, with both parameters attached: on these assumptions, cash from that exposure comes in more than USD 5.26m below a plan struck at today's rate in about one year in twenty.

Now vary the two parameters that a CFaR is meaningless without. Every cell is the same USD 40m exposure and the same 8% volatility; only the confidence level and the horizon change.

| Confidence level | 3 months (√0.25 = 0.5) | 6 months (√0.5 ≈ 0.7071) | 12 months (√1 = 1) |
| --- | --- | --- | --- |
| **90%** (z = 1.282) | 2,051,200 | 2,900,835 | 4,102,400 |
| **95%** (z = 1.645) | 2,632,000 | 3,722,211 | 5,264,000 |
| **99%** (z = 2.326) | 3,721,600 | 5,263,137 | 7,443,200 |

_USD, rounded to the nearest dollar in the 6-month column. The z-values are the standard-normal critical values published in the NIST/SEMATECH e-Handbook: 1.282 for p = 0.900, 1.645 for p = 0.950, 2.326 for p = 0.990. RiskMetrics used the rounded 1.65 for 95% throughout its 1996 Technical Document; on the 12-month figure here that rounding is worth 3,200,000 × 0.005 = 16,000._

Two things fall out of that grid that are worth carrying around.

**Time enters as a square root, not as a multiple.** Going from 3 months to 12 quadruples the horizon but only doubles the number — √4 = 2, and 2,632,000 × 2 = 5,264,000. Annualise a quarterly risk figure by multiplying it by four and you report 10,528,000 where the same assumptions give 5,264,000 — twice the risk that's actually there.

**Raising confidence costs about the same as doubling the horizon.** 2.326 ÷ 1.645 = 1.414, and √2 = 1.414 — the same factor. Which is why 99% over 3 months (3,721,600) and 95% over 6 months (3,722,211) come out within 611 of each other: two completely different questions, one indistinguishable answer. If someone hands you a CFaR without its horizon and confidence level, that grid is what they've hidden.

### Why this is a planning aid, not a promise

The multiplication buys its simplicity with three assumptions, and all three are wrong to some degree.

- **Normality.** A z-value only converts a confidence level into a number of standard deviations if the returns are normally distributed. Real currency and rate returns have fatter tails than that, so the parametric figure understates the bad end — the identical criticism that lands on variance-covariance [VaR](https://gravam.com/blog/value-at-risk-var-in-treasury).
- **Square root of time.** Scaling volatility by √t assumes each period's move is independent of the last and drawn from the same distribution. Trends and mean reversion both break it, and over a 12-month horizon there's plenty of room for either.
- **One factor, one amount.** A real exposure is several currencies and rates, arriving on a schedule, partly hedged, correlated with each other and sometimes with the volumes themselves. Collapsing that to one number and one volatility throws away the interactions, which is exactly where the risk that surprises people tends to live.

That's why CorporateMetrics doesn't do it this way. Its method is the three-step one above: map the exposures, generate scenarios, revalue, then rank the resulting outcomes and read the percentile straight off them — at 95% confidence across 1,000 trials, the 50th-worst result. A simulation copes with fat tails, with correlations between factors, with timing, and with hedges that pay off non-linearly. The multiplication copes with none of that.

So use the arithmetic for what it's good for: sizing the thing before you've built anything, and sanity-checking a model that hands you a number ten times larger than you expected. It tells you how big the risk is _on the assumptions you fed it_. It does not tell you what will happen, and the gap between those two sentences is the whole of the caveat below.

## What treasurers use it for

CFaR earns its place because it feeds real decisions:

- **Setting hedge ratios.** If the potential shortfall is bigger than the business can stomach, that's the case for hedging more of the exposure — and CFaR sizes how much, which is the input a [layered hedging strategy](https://gravam.com/blog/fx-hedging-strategy) turns into ratios by horizon.
- **Protecting a budget rate.** When the plan was struck at a given FX or interest rate, CFaR quantifies how exposed that budget is to the rate moving against you before the cash lands.
- **Deciding how much risk to carry.** Risk management is about staying [within appetite, not chasing zero](https://gravam.com/blog/what-is-treasury-risk-management). CFaR turns "how much FX and rate risk are we comfortable carrying?" into a number you can hold against a limit.
- **Board reporting.** It states risk in cash-versus-plan terms a board already thinks in, which makes the risk conversation land rather than glaze over.

## The honest limits

Here's the part the textbooks underplay: **CFaR is only as good as the forecast underneath it.** The whole measure is built on a view of what cash is expected and when — so if that forecast is soft, every number downstream is soft too. Feed it a wishful [cash-flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast) and CFaR becomes theatre: a precise-looking figure resting on a guess. I'd trust a rough CFaR on a disciplined forecast long before a sophisticated one on a forecast nobody stands behind.

The scenario assumptions carry the same warning. CFaR reflects the range of market moves you told it to consider; if reality serves up something outside that range, the measure quietly understates the risk. It's a tool for framing and sizing risk, not a promise about the future.

Used honestly, though, CFaR is one of the most useful things treasury can put in front of a CFO or a board: risk stated in the currency of the plan the business actually runs on. Pair it with its portfolio-value counterpart in [Value at Risk](https://gravam.com/blog/value-at-risk-var-in-treasury), and you've got both halves of the measurement picture — value and cash flow.

***

_See also [Value at Risk in treasury](https://gravam.com/blog/value-at-risk-var-in-treasury) and [FX risk: transaction, translation and economic exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure)._

## Primary sources

The CFaR and EaR definitions, the 2-to-24-month horizon framing and the ranked-trials percentile method are quoted from the CorporateMetrics Technical Document, first edition (April 1999); the VaR horizon and the 1.65 multiplier from the RiskMetrics Technical Document, fourth edition (December 1996). Both are historical documents and are not revised. The worked example uses assumed inputs, and its z-values are standard-normal critical values — neither is version- or vendor-dependent.

- RiskMetrics Group — CorporateMetrics Technical Document, first edition (April 1999) — accessed 2026-09-02 — https://www.msci.com/documents/10199/8af520af-3e63-44b2-8aab-fd55a989e312
- J.P. Morgan/Reuters — RiskMetrics Technical Document, fourth edition (December 1996) — accessed 2026-09-02 — https://www.msci.com/documents/10199/5915b101-4206-4ba0-aee2-3449d5c7e95a
- NIST/SEMATECH e-Handbook of Statistical Methods — Cumulative Distribution Function of the Standard Normal Distribution (with critical values) — accessed 2026-09-02 — https://www.itl.nist.gov/div898/handbook/eda/section3/eda3671.htm

## Questions this article answers

**Q: What is Cash Flow at Risk?**

Cash Flow at Risk (CFaR) is a measure of the largest shortfall a company might see in its cash flow — or its earnings — over a defined period, such as a quarter or a year, at a chosen confidence level. It answers the question a corporate actually cares about: how bad could our cash flow be versus the plan or budget we're relying on? Rather than measuring the mark-to-market value of a trading portfolio, it measures the risk to the cash the business expects to have, driven by exposures like foreign-currency flows and floating-rate costs.

**Q: How is CFaR different from VaR?**

Value at Risk (VaR) measures the potential loss in the mark-to-market value of a portfolio over a short horizon — typically a day or a few days — which suits a trading book that's revalued and can be traded out of quickly. Cash Flow at Risk measures the potential shortfall in cash flow or earnings against plan over a much longer horizon — a quarter or a year — which suits a corporate whose exposures are its real business flows, not tradeable positions. Same statistical idea, a worst outcome at a confidence level, but VaR is about portfolio value and CFaR is about the cash you'll actually have.

**Q: How do you calculate CFaR?**

A real CFaR is simulated: map the exposures, generate scenarios for the rates that drive them, revalue the cash flows under each scenario, then rank the results and read off the percentile matching your confidence level — at 95% confidence over 1,000 trials, the 50th-worst result. There is a parametric shortcut for a first estimate: multiply the net exposure by the annualised volatility of the risk factor, by the square root of the horizon in years, and by the z-value for the confidence level. On an assumed USD 40,000,000 net exposure over 12 months with 8% annualised volatility, at 95% confidence (z = 1.645), that is 40,000,000 × 0.08 × 1.645 = 5,264,000 — a CFaR of about USD 5.26m, or 13.2% of the exposure. Those inputs are illustrative, not benchmarks. The shortcut assumes returns are normally distributed, which real currency and rate moves are not, so it understates the tail.

**Q: Why do corporates use CFaR?**

Because a corporate doesn't live or die by the daily revaluation of a trading book — it lives by whether the cash it forecast actually turns up. CFaR frames risk in the terms a treasurer and CFO already think in: budget rates, forecasts, and the plan the business is funded against. That makes it directly useful for setting hedge ratios, deciding how much FX or interest-rate risk to carry, protecting a budget rate, and reporting risk to a board in language it understands — cash versus plan, not portfolio value.

---

# Commodity Price Risk in Corporate Treasury

Source: https://gravam.com/blog/commodity-price-risk
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: Commodity price risk: when the prices of what a company buys or sells hurt its finances. How it differs from FX and interest-rate risk, and how it's managed.

**Commodity price risk is the risk that moves in the prices of commodities a company buys or sells hurt its finances — jet fuel for an airline, metals for a manufacturer, grain for a food company, crude for a producer.** It's a market risk, like [FX](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) and [interest rate](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) risk, and it's managed with the same logic — [identify, measure, manage, monitor](https://gravam.com/blog/what-is-treasury-risk-management) — but it has its own quirks: commodity prices are often _more volatile_, exposure is frequently _indirect_, and hedging carries _basis risk_ that makes it imperfect. It's also the market risk most often owned _jointly_ with procurement and the commercial side, rather than by treasury alone.

## What it is

Any company whose costs or revenues depend materially on a commodity price it doesn't control has commodity price risk. Two directions:

- **On the buy side** — input costs. A manufacturer's metals, an airline's fuel, a food producer's crops. When the commodity rises, margins compress.
- **On the sell side** — output prices. A miner, farmer or oil producer whose revenue rises and falls with the price of what it sells.

Either way, an uncontrolled price move flows straight to the bottom line.

## How it differs from FX and rates

Commodity risk shares the market-risk framework but has features FX and rates don't:

- **Higher volatility.** Commodity prices can swing far more sharply than currencies or rates.
- **Indirect exposure.** You may be exposed to a commodity you don't buy _directly_ — its cost is embedded in a supplier's price. That hidden exposure is easy to miss.
- **Basis risk.** The traded hedging instrument rarely matches your _exact_ commodity, grade, location and timing — so hedges are imperfect in a specific way (more below).

> The most-missed commodity exposure is the _indirect_ one. You may not buy copper — but if your supplier does, and their price moves with it, you're exposed to copper through them. Mapping exposure means looking through your supply chain, not just at what you purchase directly — and holding the result to the same [exposure data quality](https://gravam.com/blog/treasury-exposure-data-quality) bar as any other risk number.

## Managing it: natural first

As with [FX](https://gravam.com/blog/natural-hedging-vs-financial-hedging), reduce exposure structurally before hedging financially:

- **Pass-through pricing** — moving the commodity cost to customers via price, so a rise in input cost is recovered in revenue.
- **Fixed-price or indexed supplier contracts** — locking input costs, or tying them to a known index.
- **Matching** — aligning the timing and currency of purchases and sales so exposures partly offset.

Where the business can pass the cost on or contract it away, that's usually cheaper and simpler than a financial hedge.

## Financial hedging — and basis risk

For the residual, companies use **commodity derivatives** — futures, forwards, swaps and options — to offset price exposure, exactly as with [FX instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps). But commodity hedging carries **basis risk** more acutely: the liquid traded contract (a benchmark grade, at a benchmark location, for a standard date) may differ from _your_ actual commodity, quality, delivery point and timing. So the hedge offsets the _benchmark_ move but not perfectly _your_ move — leaving a residual "basis" you have to understand and accept. A commodity hedge is rarely the clean offset an FX forward can be.

## Whose risk is it?

Unlike FX and rates — usually treasury's domain — commodity risk is often **shared**. Procurement owns supplier contracts, the commercial side owns pricing, and treasury owns the financial hedging and the framework. Managing it well means these functions working _together_, with a clear [policy](https://gravam.com/blog/treasury-risk-management-policy) on who does what. Commodity risk falls through the cracks precisely when everyone assumes someone else owns it.

## Commodity hedging mistakes to avoid

- **Ignoring indirect exposure.** Hedging only directly-purchased commodities and missing the exposure embedded in suppliers' prices.
- **Underestimating basis risk.** Treating a benchmark hedge as a perfect offset, then being surprised by the residual basis.
- **Over-hedging.** Hedging forecast volumes so aggressively that if they don't materialize, the hedge becomes a [speculative](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) position on the commodity.
- **No policy / no clear owner.** Commodity risk left between procurement, commercial and treasury, so it's managed by no one.
- **Forgetting natural options.** Reaching for derivatives when pass-through pricing or a supplier contract would have handled it.

Map the exposure including the indirect part, reduce it naturally where you can, hedge the residual with eyes open about basis risk, and give it a clear cross-functional owner under policy — and commodity price risk becomes a managed exposure rather than the volatile line that quietly wrecks a margin. It's the market risk that most needs treasury and the business to manage it _together_.

***

_See also [natural vs financial hedging](https://gravam.com/blog/natural-hedging-vs-financial-hedging) and [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management)._

## Questions this article answers

**Q: What is commodity price risk?**

Commodity price risk is the risk that changes in the prices of commodities a company buys or sells will hurt its finances. A manufacturer is exposed to the cost of its raw materials, an airline to jet fuel, a food company to agricultural inputs, and a producer to the selling price of what it extracts or grows. It's a form of market risk, like FX and interest rate risk, but it attaches to physical inputs and outputs rather than currencies or rates, and it's often more volatile.

**Q: How is commodity risk different from FX or interest rate risk?**

Commodity risk attaches to physical goods a company buys or sells, and it has some features that FX and rate risk don't. Commodity prices are often more volatile; exposure can be indirect (a supplier's costs, embedded in the price you pay, not a commodity you buy directly); and hedging carries basis risk — the traded instrument may not exactly match the specific grade, location or timing of your actual commodity, so the hedge is imperfect. It's also frequently owned jointly with procurement and the commercial side, not treasury alone.

**Q: How do companies manage commodity price risk?**

First by identifying the exposure (including indirect exposure embedded in suppliers' prices), then managing it through natural means where possible — pass-through pricing that moves the cost to customers, fixed-price or indexed supplier contracts, and matching purchases to sales — and through financial hedging using commodity futures, forwards, swaps or options for the residual. As with other risks, it should be governed by policy, sized to a real exposure, and mindful of basis risk, since commodity hedges rarely offset perfectly.

---

# How to Write a Treasury Risk Management Policy

Source: https://gravam.com/blog/treasury-risk-management-policy
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-26
Reviewed: 2026-09-26
Summary: How to write a treasury risk management policy: turn risk appetite into enforceable rules — permitted instruments, limits, approvals — so hedging isn't a bet.

**A treasury risk management policy is the governing document that turns risk appetite into enforceable rules — which risks are managed and how, the permitted instruments, the limits, the approval authorities, and the reporting.** It's what makes risk management _consistent and bounded_ rather than dependent on whoever happens to be deciding, and it's the single most important control keeping hedging from drifting into speculation. Every article in this pillar — [FX](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure), [interest rate](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury), [counterparty](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury), [hedging](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) — ultimately lives or dies by the policy that governs it. Without one, "manage risk sensibly" means whatever today's decision-maker thinks it means.

## What a treasury risk policy is for

The policy is where the company writes down, in advance and with authority, _how_ it handles financial risk — so the answer to "can we do this?" is a document, not an argument. It's the constitution of treasury risk: the rules that apply to everyone, every time, regardless of the individual or the temptation of the moment.

## Why the policy matters more than judgement

> Without a policy, risk management is just a series of individual judgements — and the day a judgement is wrong, or a hedge is really a bet, there's nothing that was supposed to stop it. The policy is that something.

Three things a policy does that judgement alone can't:

- **Encodes appetite.** It fixes _how much_ risk is acceptable, so it doesn't drift with whoever's deciding.
- **Ensures consistency.** The same rules apply across time, people and situations.
- **Prevents speculation.** By requiring an underlying exposure and permitting only certain instruments, it keeps treasury from [running a trading book](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps).

It's also what the **board and auditors** rely on to know financial risk is actually controlled.

## What it covers

A complete policy typically addresses:

- **Scope of risks** — which risks it governs (FX, interest rate, liquidity, counterparty, [commodity](https://gravam.com/blog/commodity-price-risk)).
- **[Risk appetite and limits](https://gravam.com/blog/risk-appetite-and-limits-in-treasury)** — how much of each risk is acceptable, in concrete numbers.
- **Permitted instruments** — which instruments are allowed (and, by exclusion, which are prohibited — exotic structures usually among them).
- **Counterparty limits & credit standards** — [caps per institution and minimum quality](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury).
- **Approval authorities** — who can approve what, at what size.
- **Segregation of duties** — the [separation](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) of dealing, confirming and settling.
- **Measurement** — how each exposure is quantified.
- **Reporting & monitoring** — what's reported, to whom, how often.
- **Exceptions** — how a breach or an exception is handled and escalated. For liquidity, this is worth expanding into a full [escalation framework](https://gravam.com/blog/liquidity-escalation-framework): thresholds, tiers, actions and owners.

## Risk appetite at its heart

Everything else flows from **risk appetite** — the deliberate statement of how much risk the company is willing to bear. Get that right and the limits, permitted instruments and approvals all follow logically. Get it vague ("we're prudent") and the whole policy floats, because there's no anchor to test any decision against. The appetite is the policy's foundation, not a preamble.

## Approval and segregation of duties

A policy without teeth is decoration. It must define **who approves what** and enforce **segregation of duties** — the same money-moving controls as the rest of [treasury](https://gravam.com/blog/segregation-of-duties-in-treasury-systems): the person who strikes a deal can't be the one who confirms and settles it. This is what stops a rogue position or an error from passing unchecked, and it's why a risk policy is as much about _control_ as about _strategy_.

## Review and governance

A risk policy should be **approved at board or senior level** — giving it the authority to actually bind — and **reviewed on a regular cycle**, because the business, its exposures and the market change. A policy written five years ago and never revisited may permit what's now imprudent or forbid what's now needed. Governance keeps it a living control, not a forgotten document.

## Why treasury risk policies fail to control anything

- **No policy.** Risk run on judgement and habit, with no agreed appetite or rules.
- **A policy that's ignored.** It exists on paper but isn't enforced, so it controls nothing.
- **Too vague.** "Be prudent" with no concrete limits or appetite — nothing to actually test decisions against.
- **Never reviewed.** Set once and left, drifting out of line with the business it governs.
- **No teeth.** No defined approvals, segregation or consequences for a breach, so it can't actually stop anything.

Anchor the policy on a clear risk appetite, translate it into concrete limits and permitted instruments, enforce it with approvals and segregation of duties, and keep it reviewed and board-owned — and it becomes the framework that makes all of treasury's risk-taking deliberate, consistent and controlled. It's the document that turns the whole [identify-measure-manage-monitor discipline](https://gravam.com/blog/what-is-treasury-risk-management) from principle into practice.

***

_See also [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management) and [counterparty and credit risk](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury)._

## Questions this article answers

**Q: What is a treasury risk management policy?**

A treasury risk management policy is the governing document that defines how a company manages its financial risks. It sets out the risk appetite, which risks are actively managed and how, the financial instruments permitted, the limits (including counterparty limits), who has authority to approve what, the segregation of duties, how risks are measured, and how they're reported. Its job is to turn risk appetite into concrete, enforceable rules so that risk decisions are consistent, bounded and controlled rather than ad hoc.

**Q: Why does a company need a treasury risk policy?**

Because without one, risk decisions depend on whoever is making them and whatever seems reasonable at the time — which is how exposures drift, hedging becomes inconsistent, and speculation creeps in disguised as risk management. A policy encodes the company's chosen risk appetite into rules that apply regardless of the individual, defines who can do what, and provides the control framework that keeps treasury's risk-taking deliberate and bounded. It's also what boards and auditors rely on to know financial risk is under control.

**Q: What should a treasury risk policy contain?**

At minimum: the scope of risks it covers (FX, interest rate, liquidity, counterparty); the risk appetite and specific limits; the financial instruments that are permitted (and, by implication, prohibited); counterparty limits and minimum credit standards; approval authorities and segregation of duties; how each risk is measured; reporting and monitoring requirements; and how exceptions are handled. It should be approved at board or senior level and reviewed on a regular cycle so it stays aligned with the business.

---

# Hedge Accounting Explained: IFRS 9 vs ASC 815

Source: https://gravam.com/blog/hedge-accounting-explained
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Hedge accounting under IFRS 9 and ASC 815: the three hedge types, designation, effectiveness, rebalancing, de-designation and cost of hedging, compared.

**Hedge accounting is an optional accounting treatment that aligns the timing of gains and losses on a hedging instrument with the item it hedges, so the income statement shows that the two offset.** A [derivative hedge](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) is normally marked to market through profit every period, while the exposure it hedges often isn't recognised yet, and reported profit swings even though the company is economically protected. Hedge accounting removes that mismatch in exchange for formal documentation and [effectiveness evidence](https://gravam.com/blog/hedge-effectiveness-testing). The two frameworks treasurers actually meet, **IFRS 9** and US GAAP's **ASC 815**, agree on the idea and disagree on a surprising number of mechanics, and those mechanics decide whether a hedge programme reports cleanly.

_(This is a conceptual explanation, not accounting advice. The rules live in IFRS 9 and ASC 815, and applying them to your book needs your accountants.)_

## The problem it solves

Take a forecast foreign-currency sale hedged with a forward. Economically you're protected: whatever the currency does, the forward offsets it. In the accounts the forward is a derivative, measured at fair value through P&L each period, while the sale hasn't happened, so nothing sits on the other side of the reporting. Profit now moves with the currency quarter by quarter, even though you deliberately removed that risk.

> Without hedge accounting, doing the economically right thing can make reported profit look more volatile, not less. The hedge works; the accounts just don't show it yet.

Hedge accounting fixes the timing: it defers or relocates the instrument's gains and losses so they land in profit at the same time as the hedged item's, and the two cancel in the numbers the way they cancel in the economics. For hedges of balances already on the balance sheet the problem often doesn't arise, because the item and the derivative already move through profit together, as [balance sheet FX hedging](https://gravam.com/blog/balance-sheet-fx-hedging) explains.

## The three hedge types and where the offset lands

Both standards use the same three relationships. What differs is how cleanly each one reports.

| Hedge type | What it hedges | IFRS 9 | ASC 815 (after ASU 2017-12) |
| --- | --- | --- | --- |
| **Fair value hedge** | Changes in the fair value of a recognised asset or liability or a firm commitment, e.g. fixed-rate debt | Instrument and the hedged item's change for the hedged risk both go to P&L, so they net | Same principle; the instrument's change included in the effectiveness assessment is presented in the same income-statement line as the hedged item |
| **Cash flow hedge** | Variability in future cash flows, e.g. a forecast FX sale or floating-rate interest ([interest rate hedges](https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars)) | Effective portion to OCI (the cash flow hedge reserve, capped at the lower of the instrument's and the hedged item's cumulative change), ineffectiveness to P&L; released when the hedged cash flow affects profit | The whole change in the instrument's fair value included in the assessment goes to OCI, with no separate ineffectiveness line; reclassified to the hedged item's line when the transaction affects earnings |
| **Net investment hedge** | The currency exposure of a net investment in a foreign operation, a [translation exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) | Effective portion to OCI with the translation differences; reclassified on disposal of the operation | Recorded in the cumulative translation adjustment in OCI; ASU 2017-12 also dropped separate ineffectiveness measurement here |

One difference hides inside the cash flow row. When a hedged forecast purchase results in a non-financial asset (inventory, equipment), IFRS 9 removes the reserve and puts it into the asset's initial cost, a **basis adjustment** that 6.5.11 says is not a reclassification. US GAAP makes no basis adjustment: the amount stays in AOCI and is released as the asset affects earnings. PwC's comparison flags that the two routes produce different AOCI balances and different asset carrying amounts for the same hedge.

## Designation and documentation

Neither framework lets you decide after the fact that a trade was a hedge. IFRS 9 6.4.1(b) requires formal designation and documentation **at inception** of the relationship and of the entity's risk management objective and strategy, identifying the hedging instrument, the hedged item, the nature of the risk being hedged and how effectiveness will be assessed, including the analysis of sources of ineffectiveness and how the hedge ratio is set. ASC 815 also requires contemporaneous documentation at inception. ASU 2017-12 added a practical allowance: the initial prospective quantitative effectiveness assessment can be completed after designation, up to the first quarterly effectiveness assessment date. The designation itself still has to exist on day one.

What goes in the file, and why late paperwork disqualifies a sound hedge, is the subject of [hedge documentation requirements](https://gravam.com/blog/hedge-documentation-requirements).

## Effectiveness: principles versus "highly effective"

This is where the frameworks diverge most in daily work.

- **IFRS 9** has no numeric pass band. A relationship qualifies when there is an **economic relationship** between instrument and hedged item, **credit risk does not dominate** the value changes, and the **hedge ratio** matches the quantities the entity actually uses to manage the risk. Ineffectiveness is still measured and booked; it just doesn't decide eligibility on its own.
- **ASC 815** requires the relationship to be **highly effective** at inception and on an ongoing basis. The standard never quantifies that, but US practice reads it as offset between 80% and 125%, per the Deloitte roadmap. ASU 2017-12 requires an initial quantitative test (dollar-offset or regression) unless an expedient such as the shortcut method or critical-terms match applies, and then lets an entity elect, hedge by hedge at inception, to assess effectiveness **qualitatively** afterwards if it can reasonably support an expectation of high effectiveness.

So an IFRS reporter asks "is this still an economic hedge at the ratio we manage to?", while a US GAAP reporter asks "is it still highly effective?", and after ASU 2017-12 that is often a documented qualitative answer rather than a quarterly calculation. The worked arithmetic, including the small-denominator trap that fails sound hedges under a bright line, is in [hedge effectiveness testing and the hedge ratio](https://gravam.com/blog/hedge-effectiveness-testing), and the [Hedge Effectiveness Checker](https://gravam.com/tools/hedge-effectiveness-checker) runs the dollar-offset calculation on your own period data.

## Rebalancing: adjusting without starting over

IFRS 9 6.5.5 introduced **rebalancing**. If the hedge ratio drifts out of line with the effectiveness requirement but the risk management objective for that designated relationship is unchanged, the entity adjusts the designated quantities of the hedged item or the instrument to restore the ratio. Rebalancing is accounted for as a **continuation** of the relationship: ineffectiveness up to that point is measured and recognised first, then the quantities change and the documentation is updated. If the objective itself has changed, rebalancing isn't available and the relationship is discontinued instead.

US GAAP has no equivalent. As KPMG's comparison puts it, a change to the hedge ratio under ASC 815 generally means de-designating the existing relationship and designating a new one, with the fresh documentation and inception testing that implies.

## You can't walk away from an IFRS 9 hedge

The mirror image of rebalancing is the ban on **voluntary de-designation**. Under IAS 39 an entity could simply revoke a designation. IFRS 9 removed that choice: a relationship that still meets its risk management objective and the qualifying criteria, after any rebalancing, cannot be discontinued at will. Hedge accounting ends only when the criteria stop being met, because the objective changed, the instrument expired, was sold or terminated, or credit risk came to dominate.

ASC 815 goes the other way. Its discontinuation guidance lists the entity **removing the designation** alongside failed criteria and an expired or terminated instrument as events that end hedge accounting prospectively, and PwC's comparison states plainly that US GAAP permits voluntary de-designation at any time after inception. For a group reporting under both, that asymmetry matters: a US GAAP book can be restructured by de-designating and re-designating; the IFRS book of the same trades cannot.

## Cost of hedging: forward points and time value to OCI

Most corporate FX hedges carry a part that has nothing to do with the hedged risk: the **forward points** of a forward, the **time value** of an option, the **currency basis spread** of a cross-currency swap. Left in the designation, that part generates ineffectiveness; excluded and marked to market, it generates P&L noise.

- **IFRS 9 6.5.15**: when only an option's intrinsic value is designated, the change in its time value **shall** go to OCI, to the extent it relates to the hedged item. For a transaction-related hedge it accumulates in equity and follows the hedged transaction (into a non-financial asset's cost, or into profit when the transaction does); for a time-period-related hedge the time value at designation is **amortised** to profit on a systematic and rational basis over the period.
- **IFRS 9 6.5.16**: when only the spot element of a forward is designated, or the currency basis spread is excluded, the entity **may** apply the same treatment to the forward element or the basis spread. Time value is compulsory cost-of-hedging treatment; forward points and basis are an election.
- **ASC 815**, after ASU 2017-12: excluded components can follow an **amortisation approach**, where the initial value is recognised in earnings on a systematic and rational basis over the instrument's life and the rest of the fair-value change sits in OCI (815-20-25-83A), or be **marked to market** through earnings (815-20-25-83B). Either way the earnings effect is presented in the same line as the hedged item.

For a forward-heavy FX programme, electing the forward-element treatment under IFRS 9, or the amortisation approach under ASC 815, is usually what turns quarterly forward-point noise into a predictable carry cost, which is how treasury thinks about it anyway.

## IFRS 9 vs ASC 815 at a glance

| Topic | IFRS 9 | ASC 815 |
| --- | --- | --- |
| Hedge types | Fair value, cash flow, net investment | Same three |
| Designation and documentation | Formal, at inception, incl. sources of ineffectiveness and hedge ratio (6.4.1(b)) | Contemporaneous at inception; initial quantitative test may follow, by the first quarterly assessment date at the latest (ASU 2017-12) |
| Effectiveness | Economic relationship, credit risk not dominant, hedge ratio as managed; no numeric band | Highly effective, read in practice as 80–125% offset |
| Ongoing assessment | Forward-looking, on an ongoing basis | Quantitative, or qualitative by election after a passed initial quantitative test |
| Cash flow hedge ineffectiveness | Measured and recognised in P&L (lower-of test) | Not separately measured; whole included change goes to OCI |
| Rebalancing | Yes (6.5.5), a continuation of the relationship | No concept; de-designate and re-designate |
| Voluntary de-designation | Prohibited while criteria are met | Permitted at any time |
| Forward points, time value, basis | Cost of hedging via OCI (time value mandatory, forward points and basis elective) | Excluded components: amortisation with OCI, or mark to market |
| Basis adjustment (non-financial item) | Yes, reserve moves into the asset's cost | No, released from AOCI as the asset affects earnings |
| Non-financial risk components | Allowed if separately identifiable and reliably measurable | Contractually specified components (ASU 2017-12), replaced by ASU 2025-09's clearly-and-closely-related model, effective for public business entities for annual periods beginning after 15 December 2026 |
| Legacy option | Policy choice to keep applying IAS 39 hedge accounting until the macro-hedging project ends (7.2.21) | Not applicable |

## Hedge accounting is not hedging

The distinction worth repeating in every policy discussion: **hedging is economic; hedge accounting is presentational.** You can hedge perfectly well without it; the protection is identical and only the smoothness of reported profit differs. Decide the hedge on the economics and the [risk policy](https://gravam.com/blog/treasury-risk-management-policy); decide hedge accounting on whether the reporting benefit is worth the documentation and testing effort. Some companies, for some exposures, reasonably choose to accept the volatility.

## Where hedge accounting breaks in practice

- **Assuming a good hedge auto-qualifies.** Without inception documentation and effectiveness evidence, a sound economic hedge still fails.
- **Documented hedge ≠ executed hedge.** A forward booked to a convenient month-end against a liquid index, when the documentation describes the actual payment date and the actual price driver, is where ineffectiveness and failed tests come from.
- **Forgetting the IFRS 9 exit is locked.** Designating broadly "to see how it goes" works under US GAAP; under IFRS 9 you can't later drop a relationship that still qualifies.
- **Ignoring forward points.** Designating the full forward and then being surprised by forward-point ineffectiveness, when the cost-of-hedging election was available at designation.
- **Letting accounting drive the hedge.** Choosing instruments for their accounting treatment rather than the exposure.

## Where it lives in SAP

In an SAP landscape the relationships, their documentation and the effectiveness runs usually sit in the Hedge Management and Accounting area of Treasury and Risk Management, with separate valuation areas carrying the IFRS and local-GAAP views of the same deals. How that is configured, and why it's harder than the deal capture, is covered in [hedge management in SAP](https://gravam.com/blog/hedge-management-in-sap) and [SAP TRM position management and valuation](https://gravam.com/blog/sap-trm-position-management-and-valuation).

Understand that hedge accounting aligns timing so the accounts show a hedge that already works; know which of the two rulebooks you report under, because rebalancing, de-designation and forward points behave differently in each; and resource the documentation and testing before you designate, not after. Then it stays what it should be, a reporting tool, rather than a driver of your risk decisions.

***

_See also [hedge effectiveness testing](https://gravam.com/blog/hedge-effectiveness-testing), [hedge documentation requirements](https://gravam.com/blog/hedge-documentation-requirements) and [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management)._

## Primary sources

IFRS 9 Chapter 6 (as issued by the IASB and adopted in the EU) and US GAAP ASC 815 as amended by ASU 2017-12; ASU 2025-09 is noted where it changes the comparison (effective for public business entities for annual periods beginning after 15 December 2026, one year later for others). Macro (portfolio) hedging of interest rate risk is out of scope. Claims checked on 2026-09-25 through cross-checked excerpts of the listed sources. A conceptual guide, not accounting advice.

- IFRS 9 Financial Instruments, Chapter 6 (Hedge Accounting) — full text as adopted for use in the EU by Commission Regulation (EU) 2016/2067 of 22 November 2016, OJ L 323 — EU-adopted text, OJ L 323, 29.11.2016 — accessed 2026-08-19 — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R2067
- AASB 9 Chapter 6 Hedge accounting — the Australian text identical to IFRS 9 Chapter 6 (paragraphs 6.4.1, 6.5.5, 6.5.15 and 6.5.16 quoted) — accessed 2026-09-25 — https://standards.aasb.gov.au/node/4486
- PwC — Achieving hedge accounting in practice under IFRS 9 (rebalancing, prohibition of voluntary de-designation, cost of hedging, IAS 39 policy choice) — accessed 2026-09-25 — https://www.pwc.com/hu/hu/szolgaltatasok/ifrs/ifrs_9/ifrs9_kiadvanyok/achieving_hedge_accounting_in_practice_under_ifrs9.pdf
- PwC Viewpoint — IFRS and US GAAP: similarities and differences, 11.15 Voluntary dedesignation of a hedging relationship — accessed 2026-09-25 — https://viewpoint.pwc.com/dt/us/en/pwc/accounting_guides/ifrs_and_us_gaap_sim/ifrs_and_us_gaap_sim_US/chapter_11_derivativ_US/1115_voluntary_dedes_US.html
- PwC Viewpoint — IFRS and US GAAP: similarities and differences, 11.13 Cash flow hedging and basis adjustments — accessed 2026-09-25 — https://viewpoint.pwc.com/dt/us/en/pwc/accounting_guides/ifrs_and_us_gaap_sim/ifrs_and_us_gaap_sim_US/chapter_11_derivativ_US/1113_cash_flow_hedgi_US.html
- Deloitte Roadmap: Hedging — 3.5 Discontinuing a Fair Value Hedge (ASC 815-25-40-1, including the entity removing the designation) — accessed 2026-09-25 — https://dart.deloitte.com/USDART/home/codification/broad-transactions/asc815-10/hedge-accounting/chapter-3-fair-value-hedges/3-5-discontinuing-a-fair-value
- Deloitte Roadmap: Hedging — 2.5 Hedge Effectiveness (ASC 815 'highly effective' requirement) — accessed 2026-09-25 — https://dart.deloitte.com/USDART/home/codification/broad-transactions/asc815-10/hedge-accounting/chapter-2-hedge-accounting-requirements/2-5-hedge-effectiveness
- KPMG — Hedge accounting: IFRS Standards vs US GAAP (rebalancing and de-designation differences) — accessed 2026-09-25 — https://kpmg.com/us/en/articles/2022/hedge-accounting-ifrs-standards-gaap.html
- FASB — Accounting Standards Update 2017-12, Derivatives and Hedging (Topic 815): Targeted Improvements to Accounting for Hedging Activities — accessed 2026-09-25 — https://storage.fasb.org/ASU%202017-12.pdf
- FASB — Accounting Standards Update 2025-09, Derivatives and Hedging (Topic 815): Hedge Accounting Improvements — accessed 2026-09-25 — https://storage.fasb.org/ASU%202025-09.pdf

## Questions this article answers

**Q: What is hedge accounting?**

Hedge accounting is an optional accounting treatment that aligns the timing of gains and losses on a hedging instrument with the item it hedges, so the income statement shows the offset instead of artificial volatility. Without it, a derivative is marked to market through profit or loss every period while the hedged item often is not recognised yet. To use it, a company must formally designate and document the relationship at inception and show it meets the effectiveness requirements of its standard, IFRS 9 or ASC 815.

**Q: What is the difference between IFRS 9 and ASC 815 hedge accounting?**

Both have the same three hedge types and both require designation and documentation at inception. The main differences: IFRS 9 tests effectiveness on principles (an economic relationship, credit risk not dominating, a hedge ratio that matches risk management) while ASC 815 requires a highly effective relationship, read in practice as 80 to 125 percent offset. IFRS 9 allows rebalancing a hedge ratio without ending the relationship and prohibits voluntary de-designation; US GAAP has no rebalancing concept and lets an entity de-designate at any time. IFRS 9 also applies a basis adjustment for hedged purchases of non-financial items, which US GAAP does not.

**Q: Can you voluntarily de-designate a hedge under IFRS 9?**

No. Under IFRS 9 an entity cannot discontinue a hedging relationship that still meets its risk management objective and the qualifying criteria, after any rebalancing. Hedge accounting stops only when those criteria are no longer met, for example because the risk management objective changed or the hedging instrument expired or was sold. US GAAP is different: ASC 815 lists the entity removing the designation as one of the events that ends hedge accounting.

**Q: What is cost of hedging under IFRS 9?**

Cost of hedging is IFRS 9's treatment for the parts of a hedging instrument left out of the designation: the time value of an option, and optionally the forward element of a forward contract or the foreign currency basis spread. Instead of hitting profit or loss as it moves, the excluded part goes to other comprehensive income and reaches profit or loss either with the hedged transaction or amortised over the hedged period. ASC 815 reaches a similar result through excluded components amortised to earnings, with the unamortised difference held in OCI.

---

# Interest Rate Risk in Corporate Treasury

Source: https://gravam.com/blog/interest-rate-risk-in-corporate-treasury
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-02
Summary: Interest rate risk is when rates raise floating-rate debt costs or cut investment income. The main lever is the fixed/floating mix; swaps and caps adjust it.

**Interest rate risk is the risk that changes in interest rates hurt a company's finances — chiefly by raising the cost of floating-rate debt, but also by cutting investment income or making refinancing dearer.** The core lever for managing it is the **fixed/floating mix** of debt: fixed protects against rising rates but forgoes falling ones; floating does the reverse. Managing interest rate risk isn't about predicting rates — it's about choosing a _deliberate_ mix that matches the company's appetite, and using [instruments like swaps and caps](https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars) to hit that target. The failure mode is ending up with an exposure by accident rather than by choice.

## What it is

Companies borrow, invest and refinance, and every one of those is sensitive to interest rates. When rates move, the cost of debt and the income on cash move with them. Interest rate risk is that sensitivity — and for most corporates, the dominant piece is **floating-rate borrowing**, where the interest bill rises directly as rates climb.

## Where it comes from

- **Floating-rate debt** — interest cost tracks a [reference rate](https://gravam.com/blog/interest-rate-benchmark-reform-libor-sofr); rising rates raise the bill. The main source for most.
- **Refinancing** — debt maturing into a higher-rate environment costs more to roll over.
- **Investments** — falling rates cut the income earned on [surplus cash](https://gravam.com/blog/managing-surplus-cash).

## Fixed vs floating: the fundamental trade-off

The heart of it:

|  | Fixed-rate debt | Floating-rate debt |
| --- | --- | --- |
| **Interest cost** | Set, unchanging | Moves with the market |
| **If rates rise** | Protected | Costs more |
| **If rates fall** | No benefit | Benefits |
| **Risk type** | Fair-value | Cash-flow volatility |

Neither is "safe." Fixed removes cash-flow uncertainty but locks you out of falling rates; floating gives you the downside _and_ the upside of moves. The question is never "which is safer?" — it's "what mix matches our appetite?"

> Interest rate management isn't a rate forecast. It's a deliberate decision about how much cash-flow certainty you want to buy — and how much flexibility you're willing to give up for it.

## The types of risk

- **Cash-flow / repricing risk** — on floating debt: the interest payment changes as rates reset.
- **Fair-value risk** — on fixed debt: the _value_ of the obligation changes with rates, even though the cash payment doesn't.
- **Refinancing risk** — the risk that debt has to be rolled over at a worse rate.

## The fixed/floating mix decision

The central management act is setting a **target mix** — say, a chosen proportion of fixed to floating — that reflects how much cash-flow certainty the company wants. This should be a _deliberate policy decision_, reviewed over time, not the accidental result of whatever each loan happened to be. A company that has never chosen its mix has an interest rate exposure it never decided to run.

## The instruments

To reach the target mix without renegotiating the underlying loans, treasury uses:

- **Interest rate swaps** — exchange floating-rate payments for fixed (or vice versa). The main tool: turn floating debt into effectively-fixed, or the reverse, to hit the target mix.
- **Caps** — set a ceiling on how high a floating rate can go, for a premium — protection against rising rates while keeping the benefit if they fall (the interest-rate cousin of an [FX option](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps)).

As always, these [offset a real exposure](https://gravam.com/blog/what-is-treasury-risk-management) — they adjust the risk on actual debt, not a bet on rates.

## A worked example: reading a debt book

The whole discipline fits in one illustrative example. Take a company carrying 100 of debt — 70 floating, 30 fixed — a 30%-fixed exposure it drifted into rather than chose:

| Step | This book |
| --- | --- |
| **Current mix** | 30% fixed / 70% floating |
| **Target (appetite)** | Say 60% fixed — more cash-flow certainty wanted |
| **The gap** | 30 of floating to convert |
| **The action** | A payer swap on 30 notional: pay fixed, receive floating |
| **The result** | Effectively 60/40, with the underlying loans left untouched |

Notice what the swap did and didn't do: it moved the _exposure_ to the chosen mix without renegotiating a single loan, and it offset a real position rather than betting on rates. That's the entire game — close the gap between the mix you have and the one you decided to run.

## Managing it

1. **Set a target fixed/floating mix** matching appetite, in policy.
2. **Measure** the current mix across all debt.
3. **Use swaps/caps** to move from actual to target.
4. **Monitor and adjust** as debt matures, is added, and appetite shifts.

## Fixed-floating mix mistakes

- **Unmanaged all-floating exposure.** Never choosing a mix, so a rate rise hits the full debt book unhedged.
- **100% fixed by reflex.** Locking everything fixed for "safety," forgoing all flexibility and any benefit from falling rates.
- **Ignoring refinancing timing.** Not seeing a wall of maturities rolling into a higher-rate environment until it's imminent.
- **Hedging without policy.** Swapping and capping on judgement, with no target mix, so the exposure drifts.
- **Forecasting instead of managing.** Trying to time rates rather than setting a deliberate, appetite-based mix.

Choose a target fixed/floating mix that matches appetite, measure where you actually are, and use swaps and caps to close the gap — and interest rate risk becomes a deliberate position you decided to hold, not an accident you discover when rates move. It's the same discipline as every other risk: [identify, measure, manage, monitor](https://gravam.com/blog/what-is-treasury-risk-management).

***

_See also [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management) and [FX hedging instruments](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps)._

## Questions this article answers

**Q: What is interest rate risk?**

Interest rate risk is the risk that changes in interest rates hurt a company's finances — most commonly by raising the cost of floating-rate debt when rates rise, but also by reducing income earned on cash and investments, or by making refinancing more expensive. For most corporates the biggest source is floating-rate borrowing, where the interest cost moves with the market. It's managed chiefly by choosing a deliberate mix of fixed- and floating-rate debt and adjusting it with instruments like swaps and caps.

**Q: What is the difference between fixed and floating rate debt for risk?**

Fixed-rate debt has a set interest cost that doesn't change, so it protects against rising rates but means you don't benefit if rates fall — its risk is 'fair value' rather than cash flow. Floating-rate debt has an interest cost that moves with the market, so it benefits when rates fall but raises your costs when they rise — its risk is cash-flow volatility. Neither is safer in the abstract; the point is to choose a deliberate fixed/floating mix that matches the company's risk appetite, rather than ending up with one by accident.

**Q: How do companies manage interest rate risk?**

The primary lever is the mix of fixed- versus floating-rate debt: a company sets a target proportion of each that matches its risk appetite. To reach that target without changing the underlying loans, treasury uses instruments — most commonly interest rate swaps, which exchange floating-rate payments for fixed (or vice versa), and caps, which limit how high a floating rate can go in exchange for a premium. The goal is a deliberate, policy-defined exposure, monitored over time, not an accidental one.

---

# Counterparty and Credit Risk in Treasury

Source: https://gravam.com/blog/counterparty-and-credit-risk-in-treasury
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: Counterparty risk is the risk that a bank or partner treasury relies on fails to meet its obligations. Managed with limits, diversification and monitoring.

**Counterparty risk — a form of credit risk — is the risk that a bank or trading partner treasury relies on fails to meet its obligations.** A bank holding your deposits becomes insolvent; a hedge counterparty can't honour its contract; money you're owed doesn't arrive. Because treasury _concentrates_ large amounts of cash and many contracts with a small number of institutions, the failure of one can hit the company's money directly. And it's insidious: banks feel safe until they aren't, so the exposure is invisible right up to the moment it matters. That's precisely why treasury manages it with deliberate limits rather than trust.

## What it is

Treasury can't operate without relying on financial institutions — it holds cash _at_ banks, invests _through_ them, and hedges _with_ them. Every one of those relationships is a dependency: if the institution fails, the thing treasury relied on it for fails too. Counterparty risk is that dependency, quantified and managed.

## Where treasury is exposed

- **Cash and deposits at banks** — the most direct: a bank failure can trap or lose the cash sitting in it.
- **Investments** — [surplus cash](https://gravam.com/blog/managing-surplus-cash) placed with an issuer depends on that issuer.
- **[Derivative counterparties](https://gravam.com/blog/isda-csa-and-collateral-management)** — a [hedge](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) is only as good as the counterparty's ability to honour it. A hedge with a failed counterparty is no hedge at all.
- **Receivables** — including [net settlements](https://gravam.com/blog/intercompany-netting) and payments in transit.

## Why it's easy to overlook

> Counterparty risk is the risk that feels like nothing — until a bank you trusted with a large share of your cash is suddenly the reason it's gone. It's invisible in every normal year, and decisive in the one that isn't.

Relationship banks are familiar and reassuring, and concentrating cash with them is convenient. In calm times nothing goes wrong, so the concentration never announces itself as risk. But institutions _do_ fail and get downgraded, and the loss when one holding a large share of your cash does is immediate. Managing counterparty risk means acting on that possibility _before_ it's obvious, not after.

## Managing it: counterparty limits

The primary tool is the **counterparty limit** — a cap on how much total exposure the company will carry to any single institution. Set limits per counterparty, size them to the counterparty's strength, and ensure no one bank holds so much of the company's cash or contracts that its failure would be catastrophic. Limits turn "these are all good banks" into an enforced ceiling that survives the day one of them isn't.

## Diversification

Limits imply **diversification** — spreading cash and contracts across several counterparties so no single failure is fatal. There's a balance: too concentrated is risky; too fragmented adds [account sprawl](https://gravam.com/blog/bank-account-rationalization), administrative cost and weaker relationships. The aim isn't maximum spread — it's _enough_ spread that the failure of any one counterparty is survivable.

## Credit quality

Not all counterparties are equal, so set **minimum credit standards** — rating floors, quality criteria — for who may hold the company's cash or be a hedge counterparty. Higher exposure and longer tenors demand stronger counterparties. And credit quality isn't static: a bank that met the bar last year may not this year, which is where monitoring comes in.

## Monitoring

Counterparty health _changes_, so managing the risk is ongoing: watch ratings, market signals and news on the institutions you're exposed to, and act early — reduce exposure, move cash, tighten limits — when a counterparty deteriorates. The worst outcome is learning a counterparty was in trouble _after_ it fails, when action is no longer possible.

## The limit framework at a glance

Each place treasury is exposed wants its own limit and its own signal to watch. A counterparty framework is really this table, filled in for your banks and kept current:

| Exposure | What's at risk | Primary limit / control | Signal to monitor |
| --- | --- | --- | --- |
| **Cash & deposits** | The cash itself | Per-bank deposit cap; minimum rating | Rating, CDS spread, news |
| **Investments** | Principal with an issuer | Issuer limit; quality floor; tenor cap | Rating, market spread |
| **Derivatives** | The hedge's value (MtM) | [ISDA/CSA + collateral](https://gravam.com/blog/isda-csa-and-collateral-management); counterparty limit | Mark-to-market exposure, rating |
| **Receivables / settlement** | In-flight amounts | Sound settlement mechanism; short tenor | Settlement fails |

The point isn't the exact numbers — it's that _every_ exposure has a named cap and a named signal, so a deteriorating counterparty triggers action (reduce, move, tighten) by rule rather than by whoever happens to read the news that morning.

## A note on settlement risk

A specific cousin worth naming: **settlement risk** — the risk in an exchange that you pay your side before receiving the other (money out before money in). It's short-lived but real, especially in FX settlement, and it's mitigated by settlement mechanisms and by choosing sound counterparties.

## How counterparty exposure builds up unchecked

- **Over-concentration.** Too much cash with one or two banks because they're the relationship banks — convenient, until one fails.
- **Ignoring bank credit quality.** Treating all banks as equally safe and never setting quality standards.
- **No limits.** Relying on trust instead of enforced caps, so exposure grows unchecked.
- **Static limits.** Setting limits once and never revisiting them as counterparties or exposures change.
- **Chasing yield into weak counterparties.** Placing cash with a shakier institution for a better rate — inverting the [security-first](https://gravam.com/blog/managing-surplus-cash) priority.

Set counterparty limits, diversify enough to survive any single failure, require minimum credit quality, and monitor counterparty health continuously — and counterparty risk stops being the invisible dependency that surprises you and becomes a bounded, watched exposure. Like every risk, it comes back to the same cycle: [identify, measure, manage, monitor](https://gravam.com/blog/what-is-treasury-risk-management) — applied to the institutions treasury can't operate without.

***

_See also [managing surplus cash](https://gravam.com/blog/managing-surplus-cash) and [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management)._

## Questions this article answers

**Q: What is counterparty risk in treasury?**

Counterparty risk (a form of credit risk) is the risk that a bank or trading partner treasury depends on fails to meet its obligations — for example a bank holding the company's deposits becomes insolvent, or a derivative counterparty can't honour a hedge contract. Because treasury concentrates large amounts of cash and many contracts with a small number of financial institutions, the failure of one counterparty can directly hit the company's money, which is why treasury actively manages this risk.

**Q: How does treasury manage counterparty risk?**

Primarily through counterparty limits — caps on how much exposure the company will have to any single bank or institution — combined with diversification across several counterparties, minimum credit-quality standards (such as rating floors), and ongoing monitoring of each counterparty's financial health. The goal is that no single counterparty holds so much of the company's cash or contracts that its failure would be catastrophic, and that deteriorating counterparties are spotted and acted on early.

**Q: Why is counterparty risk easy to overlook?**

Because banks and major financial institutions feel safe — until they aren't. Treasury naturally concentrates cash and hedges with a few trusted relationship banks, and in normal times nothing goes wrong, so the concentration is easy to ignore. But financial institutions can and do fail or get downgraded, and when one holding a large share of the company's cash does, the loss is immediate and real. The risk is invisible right up until it isn't, which is exactly why it needs deliberate limits rather than trust.

---

# Natural Hedging vs Financial Hedging

Source: https://gravam.com/blog/natural-hedging-vs-financial-hedging
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-02
Summary: Natural hedging offsets exposures by structuring the business; financial hedging uses instruments for what's left. Why you reduce naturally first, then hedge.

**Natural hedging reduces financial risk by structuring the business so exposures offset each other — matching costs and revenues in the same currency, borrowing in the currency you earn — before any financial instrument is used. Financial hedging offsets the _residual_ exposure with instruments like forwards, options and swaps.** The governing principle is order: **reduce exposure naturally first, then hedge what remains financially.** Natural hedges are usually cheaper, need no ongoing management, and carry no premium or counterparty — so a treasury that reaches straight for instruments, skipping the structural reductions available to it, is paying to hedge risk it could have removed for free.

## What natural hedging is

A natural hedge reduces the _underlying exposure itself_, through how the business is arranged. The cleanest example: a company that earns dollars _and_ spends dollars has a smaller net dollar exposure than one that only earns them — the two flows partly cancel. No instrument, no contract; the offset is built into the operation.

## What financial hedging is

Financial hedging leaves the exposure in place and _offsets_ it with a financial instrument — a [forward, option or swap](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps). The exposure still exists; the instrument produces an equal-and-opposite gain when the exposure produces a loss, so the net effect is neutralised. It's precise and flexible, but it costs money and has to be managed.

| Dimension | Natural hedging | Financial hedging |
| --- | --- | --- |
| What it does | Reduces the underlying exposure | Offsets the residual exposure |
| Mechanism | Structuring the business (currency matching, funding, netting) | Instruments (forwards, options, swaps) |
| Cost | No premium or spread | Costs money |
| Counterparty | None | Counterparty risk |
| Management | None; structural, persists | Active management, rollover |
| Order of use | First | For what's genuinely left |

## Natural first, then financial

> Natural hedging removes the risk; financial hedging offsets it. Removing is cheaper than offsetting — so you shrink the exposure structurally wherever you can, and only buy instruments for what's genuinely left.

The logic is simple economics: why pay a premium and manage a contract to offset an exposure you could have reduced by matching a cost to a revenue? Reduce naturally first, hedge the residual financially (for monetary items already on the books, that residual is what [balance sheet FX hedging](https://gravam.com/blog/balance-sheet-fx-hedging) covers) — and how much of that residual to cover, over what tenor, is the job of your [FX hedging strategy](https://gravam.com/blog/fx-hedging-strategy).

## Forms of natural hedging

- **Currency matching.** Incur costs in the same currency you earn, so revenues and costs offset.
- **Borrowing in the revenue currency.** Fund in the currency your cash flows come in, so debt service is naturally covered.
- **Invoicing currency choice.** Pricing or paying in your own currency shifts the exposure (though it may move it to a counterparty, not remove it — worth being honest about).
- **Production location.** Manufacturing in the market you sell to matches cost and revenue currencies structurally.
- **[Netting](https://gravam.com/blog/intercompany-netting) exposures across the group** — offsetting one entity's exposure against another's before hedging anything.

## Why natural hedging is attractive

- **No instrument cost** — no premium, no spread to pay.
- **No counterparty** — nothing that can fail to honour the hedge.
- **No rollover** — nothing to renew, re-margin or manage as it expires.
- **Structural** — the reduction persists as long as the business structure does.

For all these reasons, a reduction you can achieve naturally is almost always preferable to the same reduction bought financially.

## The limits — and the residual

Natural hedging can't do everything. You can't always match currencies, relocate production, or align every flow — and some exposures are simply mismatched by the shape of the business. What natural means can't remove is the **residual exposure**, and _that_ is what financial hedging is for. The two aren't rivals; they're a sequence — structure away what you can, then offset the remainder with instruments, sized to the residual and no more.

## Getting the natural-financial balance wrong

- **Jumping straight to instruments.** Hedging financially without first asking what could be reduced naturally — paying for offsets you didn't need.
- **Ignoring natural options.** Missing structural matches (funding currency, invoicing, netting) that were available for free.
- **Over-hedging the residual.** Financially hedging _more_ than the true residual, turning a hedge into a speculative position.
- **Pretend natural hedges.** Claiming an offset that just moves the risk to a counterparty or another entity rather than removing it — be honest about which is which.

Reduce exposure naturally wherever the business allows, then hedge only the residual with instruments sized to what's actually left — and hedging becomes efficient rather than expensive. The next step is knowing the instruments themselves: [forwards, options and swaps](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps), and which fits which exposure.

***

_See also [hedge accounting explained](https://gravam.com/blog/hedge-accounting-explained) for the treatment a financial hedge brings with it, and [how to write a treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy) for where the choice between the two gets settled._

## Questions this article answers

**Q: What is natural hedging?**

Natural hedging reduces financial risk by structuring the business so that exposures offset each other, without using financial instruments. The classic example is matching costs and revenues in the same currency — if you earn dollars and also incur dollar costs, those exposures partly cancel, so the net exposure to the dollar is smaller. Other forms include borrowing in the currency you earn, choosing invoicing currencies deliberately, and locating production in your sales markets. It's cheaper and lower-maintenance than financial hedging because there's no instrument, premium or counterparty involved.

**Q: What is the difference between natural and financial hedging?**

Natural hedging reduces the underlying exposure itself by how the business is structured — matching currency of costs and revenues, for example — so less risk exists in the first place. Financial hedging leaves the exposure in place but offsets it with financial instruments like forwards, options or swaps. Natural hedging is structural, free of instrument cost, and needs no ongoing management; financial hedging is flexible and precise but costs money and requires active management. The usual principle is to reduce exposure naturally first, then hedge the residual financially.

**Q: Why reduce exposure naturally before hedging financially?**

Because natural hedges are generally cheaper and lower-maintenance: there's no premium to pay, no counterparty risk, no contracts to roll over, and the reduction is built into how the business runs. Financial hedging has real costs and demands ongoing management, and it's easy to over-hedge. So the efficient approach is to first shrink the exposure through natural means wherever practical, and then use financial instruments only for the residual exposure that can't be structured away.

---

# FX Hedging Instruments: Forwards, Options and Swaps

Source: https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-02
Summary: FX hedging instruments explained: forwards lock a rate, options give the right for a premium, swaps exchange cash flows. Which suits which exposure.

**The main instruments treasury uses to hedge FX risk are forwards, options and swaps.** A **forward** locks in a future exchange rate today. An **option** gives the right, but not the obligation, to exchange at a set rate, in return for a premium. A **swap** exchanges cash flows or currencies between two parties. Each suits a different exposure — and the single most important framing is that these are tools for _hedging_, offsetting a real underlying exposure, not for betting on where a rate will go. Used against a genuine exposure they reduce risk; used without one they _are_ the risk.

_(This describes what the instruments do and how they hedge — it isn't a recommendation to use any particular one.)_

## Forwards: certainty

A **forward contract** fixes an exchange rate now for an exchange that happens on a future date. If you'll receive USD 1m in 90 days and you're a EUR company, a forward locks the EUR/USD rate today, so you know _exactly_ how many euros you'll get regardless of where the rate moves.

- **Gives:** full certainty.
- **Costs:** no upfront premium.
- **Trade-off:** it's an _obligation_ — you're committed at that rate, so if the rate moves in your favour you don't benefit. Certainty cuts both ways.

Forwards suit **certain, committed exposures** — a known amount on a known date, like a confirmed [transaction exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure).

## Options: protection with upside

An **FX option** gives you the _right, but not the obligation_, to exchange at a set rate. You pay a **premium** upfront; then if the market rate is worse than your option rate you exercise it (protected), and if it's better you let it lapse and use the market (upside kept).

- **Gives:** protection against adverse moves _and_ the ability to benefit from favourable ones.
- **Costs:** an upfront premium, whether or not you use it.
- **Trade-off:** you pay for that flexibility.

Options suit **uncertain exposures** — a flow that might or might not happen (a tender you may not win, a forecast that might not materialise) — where locking a forward could leave you obligated against an exposure that never appears.

## Swaps: exchanging streams

A **swap** exchanges cash flows between two parties. An **FX swap** combines a near-term and a far-term exchange (useful for managing timing of currency cash flows); a **cross-currency swap** exchanges principal and interest in one currency for another over time — often used alongside **borrowing in a foreign currency** as a [natural-hedge](https://gravam.com/blog/natural-hedging-vs-financial-hedging) companion.

- **Gives:** management of ongoing or financing-related currency flows.
- **Suits:** longer-term, recurring or debt-linked exposures rather than a single dated cash flow.

## At a glance

|  | Forward | Option | Swap |
| --- | --- | --- | --- |
| **What** | Lock a future rate | Right (not obligation) at a rate | Exchange cash-flow streams |
| **Upfront cost** | None | Premium | Varies |
| **Obligation?** | Yes | No | Yes (per terms) |
| **Keeps upside?** | No | Yes | Depends |
| **Best for** | Certain, dated exposure | Uncertain / contingent exposure | Ongoing / financing exposure |

## Matching instrument to exposure

The skill isn't knowing the instruments; it's matching them to the exposure:

- **Certain and committed** → forward (certainty, no premium).
- **Uncertain or contingent** → option (don't obligate against a flow that might vanish).
- **Ongoing or financing-linked** → swap.

Using a forward on a maybe-flow, or paying option premiums on a dead-certain one, is how hedging quietly wastes money.

## Hedging, not speculation

The line that must never blur: a **hedge offsets a real underlying exposure; a speculative position doesn't.** The same forward that hedges a genuine receivable becomes a bet if there's no receivable behind it. Corporate treasury exists to _reduce_ financial risk, not to run a trading book — so every instrument should trace to an exposure it offsets, [sized to that exposure](https://gravam.com/blog/fx-hedging-strategy) and no larger. This is exactly why [risk policy](https://gravam.com/blog/what-is-treasury-risk-management) restricts which instruments are allowed and requires an underlying exposure.

## Misusing forwards, options and swaps

- **Options as lottery tickets.** Buying options with no underlying exposure, hoping for a payout — that's speculation, not hedging.
- **Wrong instrument for the exposure.** Forwards on contingent flows, premiums paid on certain ones.
- **Over-complex structures.** Exotic combinations sold as clever hedges that treasury can't fully explain — a red flag, not a feature.
- **Hedging without an underlying exposure.** The cardinal error: an instrument that isn't offsetting a real exposure is a position, not a hedge.
- **Ignoring cost.** Treating forwards as "free" (they lock away upside) or options' premiums as trivial.

Match forwards to certain exposures, options to uncertain ones, and swaps to ongoing ones; keep every instrument tied to a real exposure and sized to it — and financial hedging does its job: neutralising risk you couldn't [remove naturally](https://gravam.com/blog/natural-hedging-vs-financial-hedging), without turning treasury into a trading desk.

***

_See also [natural vs financial hedging](https://gravam.com/blog/natural-hedging-vs-financial-hedging) and [FX risk exposure types](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure)._

## Questions this article answers

**Q: What are the main FX hedging instruments?**

The three most common are forwards, options and swaps. A forward contract locks in an exchange rate today for a currency exchange on a future date, giving certainty. An FX option gives the right, but not the obligation, to exchange at a set rate, in return for an upfront premium — protection against adverse moves while keeping upside. A swap exchanges cash flows or currencies between two parties, used for ongoing or financing-related exposures. Each suits a different type of exposure and need.

**Q: What is the difference between a forward and an option?**

A forward is an obligation: you agree today to exchange currency at a fixed rate on a future date, and you must, whatever the rate does — so you get full certainty but no benefit if the rate moves in your favour. An option is a right, not an obligation: you pay a premium upfront, and you can exchange at the agreed rate if it helps you or walk away if the market is better — so you get protection against adverse moves while keeping the upside, at the cost of the premium. Forwards give certainty; options give flexibility for a fee.

**Q: Are hedging instruments a form of speculation?**

No — when used properly, a hedging instrument offsets a real underlying exposure, reducing risk rather than creating it. The same instruments can be used speculatively (taking a position with no underlying exposure, purely to profit from a rate move), but that is trading, not hedging, and it is not what corporate treasury should be doing. The test is simple: a hedge has a real underlying exposure it offsets; a speculative position does not. Corporate treasury hedges; it does not run a trading book.

---

# What Is Treasury Risk Management?

Source: https://gravam.com/blog/what-is-treasury-risk-management
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-26
Reviewed: 2026-09-26
Summary: How a company identifies, measures and manages its financial risks — liquidity, FX, interest rate, counterparty — keeping risk within appetite, not at zero.

**Treasury risk management is how a company identifies, measures, manages and monitors the financial risks it's exposed to — chiefly liquidity, foreign exchange, interest rate, and counterparty/credit risk.** The crucial thing to understand up front: the goal is _not_ to eliminate risk. That's usually impossible and often undesirable — hedging costs money, and over-hedging is its own kind of risk. The goal is to keep each risk within a _deliberately chosen appetite_, so financial risk doesn't threaten the business or its plans. It's the other half of the treasury job, sitting alongside [cash and liquidity management](https://gravam.com/topics/cash-and-liquidity-management).

_(This is a plain explanation of the treasury discipline, not investment or hedging advice for any particular situation.)_

## What it is

A business is exposed to financial forces it doesn't control — currencies move, rates shift, counterparties can fail. Treasury risk management is the structured way a company gets a grip on those forces: knowing what it's exposed to, how much, and doing something deliberate about it. Not gut feel, not hope — a framework applied consistently.

## The financial risks treasury manages

- **Liquidity risk** — not having cash available when it's needed. The most existential: a profitable company that can't pay its bills still fails. (This is where [cash forecasting](https://gravam.com/blog/13-week-cash-flow-forecast) and [liquidity](https://gravam.com/topics/cash-and-liquidity-management) live.)
- **Foreign exchange risk** — currency movements hurting cash flows or the balance sheet. Comes in [three distinct types](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure).
- **Interest rate risk** — rate movements raising borrowing costs or cutting investment income.
- **Counterparty / credit risk** — a bank or trading partner failing to meet its obligations, so money you're owed doesn't arrive.
- **([Commodity risk](https://gravam.com/blog/commodity-price-risk)** — for businesses exposed to input prices, treasury may manage this too.)

## The framework: identify, measure, manage, monitor

Every financial risk is handled through the same four steps:

1. **Identify.** Find the exposures — every place the business is exposed to a currency, a rate, a counterparty. You can't manage what you haven't found, and missed exposures are unmanaged ones.
2. **Measure.** Quantify how big each exposure is — with measures like [Value at Risk](https://gravam.com/blog/value-at-risk-var-in-treasury) or, for cash flows, [Cash Flow at Risk](https://gravam.com/blog/cash-flow-at-risk-cfar). Vague awareness ("we're exposed to the euro") isn't enough to act on; you need the number.
3. **Manage.** Decide and act — accept it, reduce it (e.g. [natural hedging](https://gravam.com/topics/treasury-risk-management)), or hedge it with [instruments like swaps and caps](https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars) — to bring it within appetite.
4. **Monitor.** Keep watching. Exposures change, hedges expire, appetite shifts. Risk management is a cycle, not a one-off.

> The whole discipline rests on the first step. You cannot manage, measure or monitor an exposure you never identified — and the most dangerous risks are the ones nobody knew were there.

## The same framework, applied per risk

The four steps look abstract until you run each risk through them. This map is also the routing table for the rest of this pillar — each row is a cluster of its own:

| Risk | Identify | Measure | Typically managed by | Go deeper |
| --- | --- | --- | --- | --- |
| **Liquidity** | Map obligations vs available cash | Headroom, survival horizon | Buffers, committed facilities, forecasting | [Cash & liquidity](https://gravam.com/topics/cash-and-liquidity-management) |
| **Foreign exchange** | Find FC cash flows and foreign units | Net exposure by currency | Netting, forwards/options; operational choices | [FX exposure types](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) |
| **Interest rate** | Map floating vs fixed debt | Repricing gap, current mix | Target mix + [swaps and caps](https://gravam.com/blog/interest-rate-hedging-swaps-caps-collars) | [Interest-rate risk](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) |
| **Counterparty/credit** | List banks, issuers, derivative partners | Exposure per counterparty | Limits, diversification, credit floors | [Counterparty risk](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) |

Read across a row and it's the same discipline every time; read down the last column and it's the map of where each risk is managed in depth.

## Risk appetite and policy

Before you manage anything, you decide _how much_ risk is acceptable — the **[risk appetite](https://gravam.com/blog/risk-appetite-and-limits-in-treasury)** — and encode it in a [treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy): what's hedged and what isn't, which instruments are allowed, what limits apply, who approves what. The policy is what turns "manage risk sensibly" into concrete, enforceable rules, and what stops risk decisions from depending on whoever happens to be making them. It's the same governance logic as a [cash investment policy](https://gravam.com/blog/managing-surplus-cash), applied to risk.

## Manage, don't eliminate

The single most important mindset: **within appetite, not to zero.** Hedging isn't free — it costs money and effort, and a fully-hedged position forgoes favourable moves as well as unfavourable ones. Over-hedging can even _create_ risk (hedging an exposure that turns out not to exist is a speculative position in disguise). The art is bringing risk inside the chosen bounds efficiently, not chasing an impossible and expensive zero. For currency risk, a [layered hedging strategy](https://gravam.com/blog/fx-hedging-strategy) — hedging more of what's certain and less of what's only forecast — is how that works in practice.

## Why it matters

Financial risk can sink a profitable business. A company can be operationally healthy and still be wrecked by an unhedged currency move, a refinancing at the wrong moment, or a failed counterparty holding its cash. Treasury risk management is the function that keeps those financial forces from turning a good business into a casualty — quietly, in the background, until the day it's the only thing that mattered.

## Where risk programmes go wrong

- **No policy.** Risk managed by judgement and habit, so decisions vary and drift, and nobody can say what the appetite even is.
- **Poor identification.** Exposures missed entirely — the unmanaged risk that surfaces as a nasty surprise.
- **Measuring badly.** Acting on vague awareness instead of quantified exposure, so hedges are the wrong size.
- **Speculation disguised as hedging.** Taking positions that aren't offsetting a real exposure — that's a bet, not a hedge, and treasury is not a trading desk.
- **No monitoring.** Setting hedges and forgetting them, so the book drifts out of line with the exposures it was meant to cover. Monitoring at group level means [aggregating risk across exposures, entities and instruments](https://gravam.com/blog/treasury-risk-aggregation-and-reporting) — not reading each desk's numbers in isolation.

Identify every exposure, measure it, manage it within a policy-defined appetite, and monitor it as a cycle — and treasury risk management becomes the steady discipline that keeps financial forces from threatening the business. A policy that states who may commit the company to what, at what size, on what evidence, is a decision-rights model in everything but name — the same artefact that [any AI-native workflow needs written down](https://gravam.com/blog/human-decision-rights-in-ai-native-workflows) before a model is allowed near it. Start with the exposure most companies meet first: [foreign exchange risk](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure).

***

_See also [FX risk: transaction, translation and economic exposure](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) and [managing surplus cash](https://gravam.com/blog/managing-surplus-cash)._

## Questions this article answers

**Q: What is treasury risk management?**

Treasury risk management is the discipline of identifying, measuring, managing and monitoring the financial risks a company is exposed to — principally liquidity risk, market risk (foreign exchange and interest rate), and counterparty or credit risk. Its aim is not to eliminate risk, which is impossible and often undesirable, but to keep it within a deliberately chosen risk appetite, so that financial risk doesn't threaten the business or its plans. It's a core treasury function alongside cash and liquidity management.

**Q: What are the main financial risks treasury manages?**

The main ones are: liquidity risk (not having cash available when needed), foreign exchange risk (currency movements hurting cash flows or the balance sheet), interest rate risk (rate movements raising borrowing costs or cutting investment income), and counterparty or credit risk (a bank or trading partner failing to meet its obligations). Some treasuries also manage commodity price risk. Each is identified, measured and managed differently, but all follow the same framework.

**Q: Is the goal of risk management to eliminate risk?**

No. The goal of treasury risk management is to keep risk within a chosen appetite, not to remove it. Eliminating risk is usually impossible and often not worthwhile — hedging has a cost, and over-hedging is itself a risk. A company decides how much of each risk it is willing to bear (its risk appetite), sets policy accordingly, and manages exposures to stay within those bounds. Treasury risk management is about deliberate, bounded risk-taking, not zero risk.

---

# FX Risk: Transaction, Translation and Economic Exposure

Source: https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure
Topic: Treasury Risk Management — https://gravam.com/topics/treasury-risk-management
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-02
Summary: FX risk comes in three types — transaction, translation and economic exposure. Why classifying them correctly is where FX management actually starts.

**Foreign exchange risk — the risk that currency movements hurt a company's finances — comes in three distinct types: transaction, translation and economic exposure.** They arise differently, they hit different things (cash, the reported accounts, and long-term competitiveness respectively), and they're managed differently. So FX risk management doesn't start with hedging — it starts with _correctly identifying which exposure you actually have_. Hedge a translation exposure as if it were a transaction one and you can spend real cash creating real risk to protect an accounting number. Getting the classification right is most of the battle.

## What FX risk is

Any time a company's finances depend on an exchange rate it doesn't control, it has FX risk. A euro-based company with a dollar receivable, a group with subsidiaries reporting in other currencies, an exporter competing against foreign rivals — all exposed, but in different ways. The three types are how treasury tells those ways apart.

## Transaction exposure

**The risk on specific, committed cash flows in a foreign currency.** You've sold goods for USD 1m, to be paid in 90 days; you're a EUR company; the EUR/USD rate in 90 days decides how many euros you actually get. That's transaction exposure — a real, datable cash flow whose home-currency value is uncertain.

It's the most concrete of the three and the one companies most often [hedge actively](https://gravam.com/blog/fx-hedging-strategy), because it's genuine cash and it's measurable: you know the amount, the currency and (roughly) the timing. Once the receivable is booked, the same exposure sits on the balance sheet as a monetary item, which is what [balance sheet FX hedging](https://gravam.com/blog/balance-sheet-fx-hedging) covers.

## Translation exposure

**The accounting effect of consolidating foreign operations.** When a group with a foreign subsidiary prepares consolidated accounts, that subsidiary's balance sheet and results — kept in its local currency — are _translated_ into the group's reporting currency. The rate used affects the reported figures (equity, assets, reported earnings), even though, in many cases, **no cash actually moves.**

> The key question for any FX exposure: _does cash actually change hands?_ Transaction exposure is real cash at a real rate. Translation exposure is usually an accounting restatement with no cash flow. That difference is why hedging translation with cash instruments is contentious — you'd be spending real cash to stabilise a number that isn't itself a cash flow.

## Economic exposure

**The longer-term effect of currency moves on competitiveness and future cash flows.** Even a purely domestic company can have economic exposure: if your currency strengthens, your foreign competitors' products get cheaper in your market, and your future sales suffer — no foreign-currency invoice anywhere in sight. It's the broadest, most strategic and hardest-to-measure exposure, because it's about future, uncommitted flows and competitive dynamics rather than a specific amount on a specific date.

## The three at a glance

|  | Transaction | Translation | Economic |
| --- | --- | --- | --- |
| **About** | Committed FC cash flows | Consolidating foreign units | Competitive/future effect |
| **Hits** | Cash | The reported accounts | Long-term value & cash flows |
| **Cash moves?** | Yes | Usually no | Eventually, indirectly |
| **Measurability** | High (known amount) | Medium | Low (strategic) |
| **Typically managed by** | Active hedging | Often left unhedged, or hedged carefully | Operational choices |

## One group, all three exposures

To make the taxonomy concrete, take an illustrative EUR-reporting group with a US operating subsidiary and export sales into the US. The _same_ dollar shows up as three different risks — each managed differently:

| Exposure in this group | What it is here | Realistically hedgeable? |
| --- | --- | --- |
| **Transaction** | The USD export receivables due in 90 days | Yes — forwards/options on the known amounts |
| **Translation** | Consolidating the US subsidiary's USD balance sheet into EUR | Rarely with cash instruments; usually accepted |
| **Economic** | US rivals get cheaper at home if the EUR strengthens | Not financially — operationally (match cost & revenue) |

Same currency, three exposures, three different answers. Hedge the transaction receivables and you've protected real cash; "hedge" the translation with a cash forward and you've spent real money to smooth an accounting line. The classification _is_ the decision.

## Why classification matters

Each type wants a different response. Transaction exposure is real cash risk that's routinely hedged. Translation exposure is an accounting effect that many companies deliberately _don't_ hedge with cash instruments — because protecting a non-cash number with a cash hedge can introduce genuine cash risk. Economic exposure is usually addressed _operationally_ — diversifying markets, matching costs and revenues by currency — rather than with financial hedges. Mislabel the exposure and you apply the wrong tool: the classic error is hedging "exposure" that's really translation as though it were transaction cash.

## How exposures arise — and net

Exposures accumulate across a group, and many _offset_: one entity's dollar receivable against another's dollar payable. Identifying and **netting** exposures across the group before hedging means you hedge only the true net position — the same logic as [intercompany netting](https://gravam.com/blog/intercompany-netting) applied to risk. Hedging gross, exposure by exposure, means paying to hedge risks the group already cancels internally.

## The hedging mistakes I keep seeing

- **Hedging translation as if it were cash.** Spending real cash to stabilise an accounting number, and creating cash risk in the process.
- **Missing exposures.** Not [identifying](https://gravam.com/blog/what-is-treasury-risk-management) all of them — the unmanaged exposure that surprises you. Usually a symptom of weak [exposure data quality](https://gravam.com/blog/treasury-exposure-data-quality) upstream, not of anyone forgetting to look.
- **Hedging gross, not net.** Ignoring the offsets across the group and over-hedging.
- **Ignoring economic exposure.** Focusing only on the visible invoice-level risk and missing the strategic competitive one.
- **Over-hedging.** Hedging forecast flows so aggressively that if they don't materialise, the hedge itself becomes a speculative position.

Classify each exposure as transaction, translation or economic; net across the group; and match the response to the type — and FX risk management stops being a scramble to hedge everything that moves and becomes a deliberate, right-sized discipline. It all starts with the question the whole field turns on: _what exposure is this, really?_ — which is exactly where [treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management) begins.

***

_See also [what is treasury risk management](https://gravam.com/blog/what-is-treasury-risk-management) and [intercompany netting](https://gravam.com/blog/intercompany-netting)._

## Questions this article answers

**Q: What are the three types of FX exposure?**

The three types of foreign exchange exposure are: transaction exposure, the risk on specific committed cash flows denominated in a foreign currency (like a foreign-currency receivable or payable); translation exposure, the accounting effect of consolidating foreign subsidiaries' financial statements into the group's reporting currency; and economic exposure, the longer-term effect of currency movements on the company's competitive position and future cash flows. Each arises differently and is managed differently.

**Q: What is the difference between transaction and translation exposure?**

Transaction exposure is about actual cash flows: a committed foreign-currency amount you will pay or receive, where the exchange rate determines how much home-currency cash you end up with. Translation exposure is about accounting: when you consolidate a foreign subsidiary, its balance sheet and results are translated into the reporting currency, and the rate affects the reported numbers — but often no cash actually moves. Transaction exposure hits cash; translation exposure hits the reported financials. Confusing them leads to hedging the wrong thing.

**Q: Why does classifying FX exposure matter?**

Because each type is measured and managed differently, and treating one as another wastes money or leaves real risk uncovered. Transaction exposure is a genuine cash risk that companies often hedge actively; translation exposure is an accounting effect that many choose not to hedge with cash instruments because doing so can create real cash risk to protect a non-cash number; economic exposure is strategic and usually managed operationally rather than with financial hedges. Identify which exposure you actually have before deciding how to handle it.

---

# EndToEndId vs UETR: ISO 20022 Payment References

Source: https://gravam.com/blog/payment-references-endtoendid-uetr
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-10-04
Reviewed: 2026-10-04
Summary: MsgId, PmtInfId, InstrId, EndToEndId, TxId and UETR compared: who assigns each payment reference, how far it travels, and which one returns on the statement.

**An ISO 20022 payment carries six identifiers, and they differ by who assigns them and how far they travel: MsgId names a message and PmtInfId a batch inside it, InstrId covers one hop, EndToEndId is yours and is meant to cross the whole chain, TxId belongs to the first bank, and UETR is a universally unique tracking key.** Only EndToEndId is both written by you and designed to come back on the statement. The textbook stops there. In practice every one of them is optional in the statement, the party being paid does not reconcile on any of them, and the reference that matters to the creditor sits in a different block altogether — the remittance information.

Everything below is taken from the ISO 20022 message definition reports and schemas, the EPC's SEPA Credit Transfer documents and SWIFT's own UETR pages. Where I could not open a primary source, I say so.

## The six references at a glance

| Reference | Assigned by | Scope | Format | Mandatory? |
| --- | --- | --- | --- | --- |
| `MsgId` | The instructing party sending the message | One message, point to point | Up to 35 chars | `1..1` in the pain.001, pain.002 and pacs.008 group header |
| `PmtInfId` | The sending party | One batch within a pain.001 | Up to 35 chars | `1..1` in pain.001 |
| `InstrId` | The instructing party, for the instructed party | One instruction, point to point | Up to 35 chars | `0..1` in pain.001 and pacs.008 |
| `EndToEndId` | The initiating party | The entire end-to-end chain | Up to 35 chars | `1..1` in pain.001 and pacs.008 |
| `TxId` | The first instructing agent (your bank) | The entire interbank chain | Up to 35 chars | `0..1` in pacs.008 (SEPA makes it mandatory), but TxId or UETR must be present; not in pain.001 |
| `UETR` | Not stated by ISO; on SWIFT, the ordering institution | End to end, universally unique | 36 chars, UUID v4 | `0..1` in pain.001 and pacs.008 |

What comes back, and under which tag:

| Reference | In pain.002 | In camt.053 / camt.054 (`NtryDtls/TxDtls/Refs`) |
| --- | --- | --- |
| `MsgId` | `OrgnlGrpInfAndSts/OrgnlMsgId` (`1..1`) | `MsgId` (`0..1`) |
| `PmtInfId` | `OrgnlPmtInfAndSts/OrgnlPmtInfId` (`1..1`) | `PmtInfId` (`0..1`) |
| `InstrId` | `TxInfAndSts/OrgnlInstrId` (`0..1`) | `InstrId` (`0..1`) |
| `EndToEndId` | `TxInfAndSts/OrgnlEndToEndId` (`0..1`) | `EndToEndId` (`0..1`) |
| `TxId` | No element for it | `TxId` (`0..1`) |
| `UETR` | `TxInfAndSts/OrgnlUETR` (`0..1`) | `UETR` (`0..1`) |

Two things stand out. The bank adds references of its own on the way back: `AcctSvcrRef` and `ClrSysRef` exist in both the pain.002 transaction block and the statement's `Refs`, each `0..1`. And on the statement side every reference is optional in the schema — nothing in ISO forces a bank to return any of them.

## One payment, hop by hop

Follow one supplier payment. You send a [pain.001](https://gravam.com/blog/pain-001-structure-and-fields) with all the references you control:

```xml
<!-- Illustrative fragment, not a bank-ready file -->
<PmtId>
  <InstrId>ACME-20261004-0001-017</InstrId>
  <EndToEndId>INV-4711</EndToEndId>
</PmtId>
...
<RmtInf>
  <Strd>
    <CdtrRefInf>
      <Tp>
        <CdOrPrtry><Cd>SCOR</Cd></CdOrPrtry>
        <Issr>ISO</Issr>
      </Tp>
      <Ref>RF4220260004711</Ref>
    </CdtrRefInf>
  </Strd>
</RmtInf>
```

**pain.001 to your bank.** `MsgId` and `PmtInfId` have done their job once the bank has the file; they return in the [pain.002 status report](https://gravam.com/blog/pain-002-status-and-reject-codes) at group and batch level. `InstrId` is, in ISO's words, a point-to-point reference between the instructing party and the instructed party — by definition it makes no promise beyond that hop.

**Your bank to the next bank.** The bank builds a pacs.008 — the interbank credit transfer — with a new `MsgId` of its own. The payment identification now looks like this:

```xml
<!-- Illustrative fragment, not a real interbank message -->
<PmtId>
  <InstrId>BANKA-HOP1-000981</InstrId>
  <EndToEndId>INV-4711</EndToEndId>
  <TxId>BANKA-2026100400042</TxId>
  <UETR>7a562c67-ca16-48ba-b074-65581be6f011</UETR>
</PmtId>
```

`EndToEndId` is copied: ISO defines it as "passed on, unchanged, throughout the entire end-to-end chain", and the pacs.008 definition adds that where technical limitations prevent passing multiple references, the end-to-end identification is the one that must be passed on. `TxId` is new — assigned by the first instructing agent and passed unchanged through the interbank chain. The pacs.008 carries a rule that TxId or UETR must be present; both may be.

**To the beneficiary's bank and account.** The remittance information travels alongside the references. In SEPA, the rulebook requires it to be forwarded "in full and without alteration" by every institution in the chain and delivered the same way to the beneficiary.

**Back to you.** Your debit appears in the [camt.054 notification](https://gravam.com/blog/camt-054-notification-explained) and on the [camt.053 statement](https://gravam.com/blog/camt-053-structure-and-fields), where the transaction details can carry `EndToEndId`, `PmtInfId`, `InstrId`, `UETR` and `TxId` next to the bank's `AcctSvcrRef`. The creditor's statement has the same structure, with the same optionality, plus the remittance information.

## EndToEndId vs UETR

**EndToEndId** guarantees one thing by definition: whatever the initiating party wrote is meant to arrive unchanged at every party in the chain. It guarantees nothing about uniqueness beyond your own discipline. It is 35 characters of free text, and two companies can use the same value on the same day.

**UETR** is the opposite trade. It says nothing about your business — it is 36 characters in a fixed pattern that the schemas name `UUIDv4Identifier` — but it is universally unique, so any bank in the chain can find the payment by it. On the SWIFT MT side it sits in field 121, in block 3 of the message, and since 18 November 2018 every SWIFT user originating an MT 103, MT 103 STP, MT 103 REMIT, MT 202, MT 205, MT 202 COV or MT 205 COV must provide one. SWIFT's instruction is that the ordering institution generates it, intermediaries pass it on rather than generating a new one, and a cover payment carries a copy of the original. That is the mechanism behind [SWIFT gpi tracking](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments), and why the [MT 103 and MT 202 COV](https://gravam.com/blog/mt101-vs-mt103-vs-mt202) of one payment share a key.

Note who is missing from that list: the corporate. In pain.001.001.09 and .10, `UETR` is an optional element you may fill; in pain.001.001.03 the element does not exist — its payment identification holds only `InstrId` and `EndToEndId`. On a .03 file the UETR is something the bank creates, not something you issue. As MT messages give way to MX in the [ISO 20022 migration](https://gravam.com/blog/iso-20022-migration-mt-to-mx), the element simply becomes native. Whether CBPR+ makes UETR mandatory in pacs.008 is a question for SWIFT's usage guidelines, which I could not open for this page; the base ISO schema keeps it `0..1`.

**When EndToEndId is not provided.** The element is `1..1` in pain.001, so a file without it fails validation. Payments that start elsewhere — with no originator reference at all — still need a value between banks. The SEPA rulebook gives the originator's reference the default value "Not provided", and the EPC inter-PSP guidelines turn that into a literal: in the event that no reference was given, `NOTPROVIDED` must be used. The string is not in the ISO message definition reports; it is a scheme convention. A statement line that shows `NOTPROVIDED` means the bank that built the interbank message had no reference to pass on — either none was assigned, or it did not survive an earlier leg. Check which before blaming the bank.

## Remittance information is not a reference

The six identifiers describe the payment. Remittance information describes what the payment is _for_, and it is the creditor's data, not yours. ISO defines `RmtInf` as information supplied to enable the matching of an entry with the items the transfer is intended to settle.

- **Unstructured, `<Ustrd>`** — free text, up to 140 characters per occurrence. ISO allows repetition; SEPA allows one occurrence.
- **Structured, `<Strd>`** — typed fields, including referred documents and the **creditor reference** in `CdtrRefInf`: a type code and a `Ref` of up to 35 characters, defined as a unique reference assigned by the creditor. SEPA allows either structured or unstructured, in a single occurrence, accepts `SCOR` as the only type code, and caps the structured block at 140 characters counting the tags inside it.

The **ISO 11649 creditor reference** is the standardised form of that `Ref`. Its structure, as Finance Finland's guideline describes it: the identifier `RF`, two check digits calculated with the same algorithm as IBAN check digits, then up to 21 alphanumeric characters formed freely by the creditor. `RF4220260004711` in the fragment above is a valid one. In SEPA, the issuer element is mandatory for such a reference and the guidelines say `ISO` should be stated — conversely, if the issuer is `ISO`, the reference must be an RF reference — and the receiving bank is not required to validate the check digits. The EPC recommends it as the preferred convention for a payment that settles a single invoice. I did not open the ISO 11649 standard text itself.

This is why the two sides of a payment reconcile on different fields. The debtor matches on `EndToEndId` because the debtor wrote it. The creditor cannot: the SEPA rulebook says outright that the originator's reference "can only be expected to be meaningful to the Originator". The creditor matches on the remittance information it asked for. ISO does leave one bridge: if only one identifier can pass through the chain, the creditor's reference should be quoted in the end-to-end identification.

## Which reference to reconcile on

My working rule, by job:

- **Outgoing payments against the statement:** `EndToEndId`, with amount, date and counterparty account as the fallback when it is missing.
- **Status reports against the file:** `MsgId`, then `PmtInfId`, then `EndToEndId` — one per level of the pain.002.
- **Incoming payments against open items:** the creditor reference or remittance text. Never the payer's `EndToEndId`.
- **Duplicate detection between camt.054 and camt.053:** the bank's `AcctSvcrRef`, after testing that it is the same in both.
- **"Where is my payment?":** `UETR`. Quote it to the bank.

What I see go wrong, repeatedly:

- **EndToEndId reused or meaningless.** A payment-run number copied onto every transaction satisfies the schema and matches nothing. Make it unique per payment and resolvable to a document.
- **One reference stretched over two jobs.** The invoice number goes into `EndToEndId` and the remittance information stays empty, so your side reconciles and the supplier calls asking what was paid.
- **Batch booking hides the detail.** The statement shows one debit for the whole `PmtInfId`; the per-payment references are in the camt.054 or nowhere.
- **Match rules built on the schema.** Every statement reference is `0..1`. A rule written from the XSD and not from the bank's real files works in the test bank and fails in the next one.
- **Storing too little.** If the UETR and `AcctSvcrRef` are dropped at import, the investigation three weeks later starts with a phone call.

The matching logic itself, and where a human still has to decide, is in the [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation).

## Primary sources

Element names, definitions, multiplicities and lengths are from the ISO 20022 2019–2020 maintenance release (pain.001.001.10, pain.002.001.11, pacs.008.001.09) and the camt.053.001.09 message definition report (the draft published for evaluation in December 2020); SEPA rules are from the EPC's 2025 SEPA Credit Transfer rulebook and implementation guidelines (pain.001.001.09, pacs.008.001.08); UETR rules on the MT side are from SWIFT's own publications, read through archived copies because swift.com refuses automated requests. CBPR+ usage guidelines and the ISO 11649 standard text itself were not opened and are not relied on. Older versions differ — the pain.001.001.03 schema has no UETR element — and every bank returns a different subset, so verify against your banks' MIGs.

- ISO 20022 — Message Definition Report Part 2, Payments Initiation, Maintenance 2019–2020 (pain.001.001.10, pain.002.001.11) — copy distributed in the moov-io/iso20022 repository — accessed 2026-10-04 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/payments_initiation_11/ISO20022_MDRPart2_PaymentsInitiation_2019_2020_v1_1.pdf
- ISO 20022 — pain.002.001.11 schema (CustomerPaymentStatusReportV11) — copy distributed in the moov-io/iso20022 repository — accessed 2026-10-04 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/payments_initiation_11/pain.002.001.11.xsd
- ISO 20022 — Message Definition Report Part 2, Payments Clearing and Settlement, Maintenance 2019–2020 (pacs.008.001.09) — copy distributed in the moov-io/iso20022 repository — accessed 2026-10-04 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/payments_clearing_and_settlement_10/ISO20022_MDRPart2_PaymentsClearingAndSettlement_2019_2020_v1.pdf
- ISO 20022 — pacs.008.001.09 schema (FIToFICustomerCreditTransferV09) — copy distributed in the moov-io/iso20022 repository — accessed 2026-10-04 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/payments_clearing_and_settlement_10/pacs.008.001.09.xsd
- ISO 20022 — Message Definition Report Part 2, Bank-to-Customer Cash Management, Maintenance 2020–2021 (camt.052/053/054.001.09) — accessed 2026-10-04 — https://www.iso20022.org/sites/default/files/2020-12/ISO20022_MDRPart2_BankToCustomerCashManagement_2020_2021_v1_ForSEGReview.pdf
- ISO 20022 — pain.001.001.03 schema (CustomerCreditTransferInitiationV03), messages archive — accessed 2026-10-04 — https://www.iso20022.org/sites/default/files/documents/messages/pain/schemas/pain.001.001.03.zip
- European Payments Council — SEPA Credit Transfer Customer-to-PSP Implementation Guidelines (EPC132-08, 2025 Version 1.0) — accessed 2026-10-04 — https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC132-08%20SCT%20C2PSP%20IG%202025%20V1.0.pdf
- European Payments Council — SEPA Credit Transfer Inter-PSP Implementation Guidelines (EPC115-06, 2025 Version 1.0) — accessed 2026-10-04 — https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC115-06%20SCT%20Inter-PSP%20IG%202025%20V1.0.pdf
- European Payments Council — SEPA Credit Transfer Scheme Rulebook (EPC125-05, 2025 Version 1.0) — accessed 2026-10-04 — https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC125-05%202025%20SCT%20Rulebook%20version%201.0.pdf
- SWIFT — What are UETRs and are you ready to process them? (31 October 2018) — accessed 2026-10-04 — https://www.swift.com/news-events/news/what-are-uetrs-and-are-you-ready-process-them
- SWIFT — What is a Unique End-to-end Transaction Reference (UETR)? — accessed 2026-10-04 — https://www.swift.com/payments/what-unique-end-end-transaction-reference-uetr
- SWIFT — Why you should adopt SWIFT gpi in 2018 to future-proof your payment operations (webinar slides, 4 October 2018) — accessed 2026-10-04 — https://www.swift.com/swift-resource/184881/download
- Finance Finland — Structure of the RF Creditor Reference (ISO 11649), October 2023 — accessed 2026-10-04 — https://www.finanssiala.fi/wp-content/uploads/2024/04/structure-of-the-rf-creditor-reference-iso-11649.pdf

## Questions this article answers

**Q: What is the difference between EndToEndId and UETR?**

EndToEndId is a free-text reference of up to 35 characters that the initiating party assigns, and ISO 20022 defines it as passed on unchanged through the entire end-to-end chain. It is unique only as far as the party that wrote it made it unique. UETR is a 36-character identifier in UUID version 4 format, defined by ISO as a universally unique identifier giving an end-to-end reference of a payment transaction. On SWIFT it is generated by the ordering institution, not the corporate, and has been required on MT 103, MT 202 and MT 205 family messages since 18 November 2018. EndToEndId is the key you reconcile on; UETR is the key a bank tracks and investigates on.

**Q: Is EndToEndId mandatory in pain.001?**

Yes. In the ISO 20022 message definition for pain.001, EndToEndIdentification has multiplicity 1..1 inside PaymentIdentification, while InstructionIdentification and UETR are both 0..1. The same is true in the interbank pacs.008. Because the element cannot be omitted between banks, the EPC's SEPA Credit Transfer inter-PSP guidelines say that when no reference was given, the value NOTPROVIDED must be used. That convention is a SEPA scheme rule: the string does not appear in the ISO message definition reports themselves.

**Q: Which payment reference appears on the camt.053 bank statement?**

Potentially all of them, and none of them by guarantee. The camt.053 transaction details carry a References block with MsgId, AcctSvcrRef, PmtInfId, InstrId, EndToEndId, UETR, TxId and ClrSysRef, and every one has multiplicity 0..1. EndToEndId is the one designed to come back, because ISO defines it as passed unchanged through the whole chain, but the schema does not oblige a bank to report it. The only reference a bank fully controls is its own AcctSvcrRef. Which ones you actually receive depends on the bank, the booking arrangement and the clearing channel, so test it per bank.

**Q: What is a structured creditor reference (RF reference)?**

It is a reference the creditor assigns, usually printed on the invoice, so that an incoming payment can be matched automatically. In ISO 20022 it travels in the structured remittance information, in RmtInf/Strd/CdtrRefInf, with the type code SCOR and the reference itself in an element of up to 35 characters. The ISO 11649 form, the RF creditor reference, is the letters RF, two check digits calculated with the same algorithm as IBAN check digits, and up to 21 alphanumeric characters chosen by the creditor. In SEPA, the EPC guidelines make the issuer element mandatory for such a reference and say ISO should be stated; if the issuer is ISO, the reference must be an RF reference.

---

# Value Date vs Booking Date vs Entry Date on a Bank Statement

Source: https://gravam.com/blog/value-date-vs-booking-date-vs-entry-date
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-10-04
Reviewed: 2026-10-04
Summary: Value date, booking date and entry date on a bank statement: what each means, where it sits in camt.053, MT940 and BAI2, and which date your cash position uses.

**The booking date is when the bank posts an entry to the account on its books; the value date is when the money becomes available to you on a credit, or stops being available on a debit. "Entry date" is the MT940 name for the booking date — the optional second subfield of the `:61:` line.** The textbook version ends there: three terms, two concepts. The reality is that the three statement formats carry these dates in three different shapes — camt.053 as two optional XML elements, MT940 as two dates of unequal length fused into one string, BAI2 as a file-level date plus an optional value date buried in a composite field — and that every system downstream has to choose one of them for each purpose. Verified against ISO's Message Definition Report, BAI's specification and bank implementation guides.

## The three terms side by side

| Term | What it means | camt.053 / 052 / 054 | MT940 | BAI2 |
| --- | --- | --- | --- | --- |
| Booking date | When the entry is posted to the account on the bank's books | `<BookgDt>` on the entry, `[0..1]` | `:61:` subfield 2, "entry date" | No per-transaction field; the group's as-of-date |
| Value date | When the funds become available to the account owner (credit) or cease to be available (debit) | `<ValDt>` on the entry, `[0..1]` | `:61:` subfield 1, mandatory | Funds type `V` followed by a value date, on the 16 record |
| Entry date | MT940's term for the booking date | Not a camt term | `:61:` subfield 2, `[4!n]` MMDD, optional | Not a BAI2 term |
| Availability | When a booked amount becomes accessible, where float applies (cheques, typically US) | `<Avlbty>` on the entry, `[0..*]` | Not on the `:61:` line | Funds types `0`, `1`, `2`, `S`, `D` |

The definitions in the second column are ISO 20022's, from the Message Definition Report; MT940 and BAI2 use the same ideas with less formal wording. If you are still choosing between the formats, the [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) is the place to start.

## camt.053: BookgDt and ValDt on the entry

In ISO 20022 both dates are elements of the entry (`<Ntry>`), and both are optional. The report defines them like this:

- **BookingDate `<BookgDt>`, `[0..1]`** — "Date and time when an entry is posted to an account on the account servicer's books." The usage note adds that it is the _expected_ booking date unless the entry's status is booked, in which case it is the actual one.
- **ValueDate `<ValDt>`, `[0..1]`** — "Date and time at which assets become available to the account owner in case of a credit entry, or cease to be available to the account owner in case of a debit entry." If the entry is pending, a value date present is an expected or requested one.

Each is a choice between a plain date (`<Dt>`) and a date-time (`<DtTm>`). An illustrative entry, cut down to the relevant elements (not a complete or valid instance):

```xml
<Ntry>
  <Amt Ccy="USD">12500.00</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <Sts><Cd>BOOK</Cd></Sts>
  <BookgDt><Dt>2026-10-01</Dt></BookgDt>  <!-- posted on the bank's books -->
  <ValDt><Dt>2026-10-02</Dt></ValDt>      <!-- available to the account owner -->
</Ntry>
```

Three things to know before you map them:

- **Optional in the schema.** Nordea's camt.053.001.02 guide keeps both at `[0..1]` with a plain ISO date. Whether your bank always sends both is a question for its implementation guide; the rest of the entry is in the [camt.053 field-by-field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields).
- **The same component in all three messages.** The 2020–2021 report lists `<BookgDt>` and `<ValDt>` at the same multiplicity on the entry of camt.052, camt.053 and camt.054. What changes is the status: the statement contains booked entries only, while the [intraday camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) and the [camt.054 notification](https://gravam.com/blog/camt-054-notification-explained) may report pending items, where both dates are expectations.
- **Availability replaces value date under float.** ISO's rule: "For entries subject to availability/float and for which availability information is provided, the value date must not be used." The `<Avlbty>` block then says when the booked amount "can be accessed and starts generating interest", as a number of days or an actual date. ISO describes this as US usage tied to instruments such as cheques.

## MT940: value date first, entry date second

MT940 packs both dates into the head of the `:61:` statement line. Per Nordea's service description, subfield 1 is **Value Date**, `6!n`, YYMMDD; subfield 2 is **Entry Date**, `[4!n]`, glossed as "Booking date (MMDD)". The square brackets mean optional. The same order, illustratively:

```text
:61:2610021001C12500,00NTRFINV-4471//BANKREF123
    │     │   │
    │     │   └ C = credit
    │     └ 1001 = entry date, 1 October (MMDD — no year)
    └ 261002 = value date, 2 October 2026 (YYMMDD)
```

The traps follow directly from that layout:

- **The value date comes first.** Anyone who assumes "the first date is when it happened" reads the line backwards.
- **The entry date has no year.** Four digits, month and day. The year has to be inferred from the statement's own dates, and a line whose value date and entry date fall on opposite sides of 31 December is where a naive "same year as the value date" rule breaks.
- **The entry date may be absent.** HSBC's usage guideline shows the base message at `[0..1]` for the entry date and restricts it to `[1..1]` for HSBC's own statements. So some banks always send it and the format doesn't oblige them to. If it is missing, the format gives you no separate booking date; what your parser assumes in its place is your decision, and it should be a written one.
- **Either date can be the earlier.** Nordea's own sweep example reads `:61:0509070908D…`: value date 7 September, entry date 8 September. That is a back-valued entry. The mirror case, booked today and valued later, is a forward value.

SWIFT's own field specification sits behind the user handbook, so its formal definition of the entry date is not quoted here; the subfield positions above are the ones both bank guides print. The other seven subfields are in the [MT940 tag-by-tag guide](https://gravam.com/blog/mt940-format-tags-explained).

## BAI2: an as-of-date, and a value date through the funds type

BAI2 has no booking date on the transaction. The 16 transaction detail record carries a type code, an amount, a funds type, two references and text — no date of its own. The date lives one level up: the 02 group header carries the **as-of-date** (YYMMDD, "originator date"), and every account and transaction in the group is reported as of it.

A value date appears only through the funds type. When the funds type is `V`, the next two fields are value date (YYMMDD) and value time, and BAI defines the value date as "the date the originator makes funds available to the customer". Illustratively:

```text
02,RECEIVER,ORIGINATOR,1,261001,,USD,2/
                         └ as-of-date: 1 October 2026
16,195,1250000,V,261002,,BANKREF123,INV-4471,/
               │ └ value date: 2 October 2026 (value time defaulted)
               └ funds type V = value dated
```

Two traps:

- **At some banks, no `V` means "same day", not "unknown".** HSBC's guide says it leaves the funds type at its default when value date, posting date and reporting date are the same, and uses `V` when they differ. That is one bank's convention; the specification's default is `Z`, unknown.
- **Back-valuation is handled differently.** BAI's specification says value dates before the as-of-date "are not prohibited but are discouraged", that such records "should be processed as if the value date was equal to the As-of-Date", and that prior value dates must not be used to adjust availability. A back-valued entry that MT940 would show with its true value date is flattened here by rule.

The other funds types (`0`, `1`, `2`, `S`, `D`) express availability in days — the same float idea as ISO's `<Avlbty>`. Record layouts are in the [BAI2 file format guide](https://gravam.com/blog/bai2-file-format-explained).

## Which date to use for what

The formats define the dates. They don't tell you which one to use. That part is practice, and I mark it as such:

- **Cash position and forecast: value date (practice).** A position answers "what is available on this day", which is what the value date records. A forward-valued credit belongs in tomorrow's column of a [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position), even though it sits on today's statement.
- **Reconciliation and the ledger posting: booking date (practice).** The statement's balances move on the day the bank booked the entry, so that is the day the entry has to be matched and explained. Which date becomes the posting date in your ERP is configuration, not a property of the format.
- **Interest and overdraft: value-dated balances (practice, governed by contract).** The specifications point the same way — ISO ties availability to when money "starts generating interest", and Nordea describes the `:64:` closing available balance as "the balance subject to interest charges (if debit balance)". But the actual calculation basis is in your account agreement, not in any statement format, and I haven't verified it against one here.

One sourced SAP point. For bank statements integrated into One Exposure, SAP's S/4HANA 1610 documentation states that "the transaction date and amount are determined based on the bank statement item and bank statement value date": in its example a statement dated 24.02.2016 with an item valued 23.02.2016 produces one flow dated the 23rd (incoming bank cash) and two dated the 24th that move it to confirmed bank cash — the value date dates the bank-cash flow, the statement date the confirmation. That page describes statements integrated directly into One Exposure. How the [electronic bank statement posting rules](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) derive the document's posting date, and which fields of the statement tables hold each date, are not verified in this post.

## What goes wrong in practice

The patterns I see repeat, whatever the bank or system:

- **One "date" column.** The import maps a single transaction date and nobody recorded which one it was. Every later disagreement between the position and the ledger starts there.
- **A position that doesn't tie to the statement.** A position built on value dates will not equal the booked closing balance on any day with back- or forward-valued entries. That is correct, and it needs explaining once, in writing, before someone "fixes" it.
- **Back-valued entries landing in closed days.** A late correction with a value date last week changes a past day's value-dated balance. The interest follows it; so do [sweeps in a cash concentration structure](https://gravam.com/blog/cash-concentration-sweeping-and-zba). A report that only ever looks at today never shows it.
- **The year-end MT940 line.** Parsers that borrow the year for the entry date pass eleven months of testing and fail in the first week of January.
- **A migration that changes the meaning silently.** Moving from MT940 to camt.053, or adding a BAI2 bank, changes which dates are present and how back-valuation is represented. If the mapping document says "date → date", the difference surfaces later as a reconciliation break.

The fix is the same in each case: carry both dates through the interface under their own names, decide per use which one applies, and write the decision down where the next person will find it.

## Primary sources

BookingDate, ValueDate and Availability definitions and multiplicities verified against ISO's Message Definition Report for Bank-to-Customer Cash Management (camt.052/053/054.001.09, Maintenance 2020-2021, in the draft published for evaluation in December 2020) and Nordea's camt.053.001.02 MIG; the MT940 :61: subfields against Nordea's MT940 service description and HSBC's MT940 usage guideline (SR 2013), because SWIFT's own specification sits behind the user handbook; the BAI2 funds type and as-of-date against BAI's Version 2 specification and HSBC's BAI2 guide; the SAP statement against SAP's One Exposure documentation for S/4HANA 1610. Which date drives interest is contractual and is marked as practice, not specification.

- ISO 20022 — Message Definition Report Part 2, Bank-to-Customer Cash Management, Maintenance 2020–2021, draft for evaluation (camt.052/053/054.001.09: Entry BookingDate, ValueDate, Availability) — accessed 2026-10-04 — https://www.iso20022.org/sites/default/files/2020-12/ISO20022_MDRPart2_BankToCustomerCashManagement_2020_2021_v1_ForSEGReview.pdf
- Nordea — Corporate eGateway MIG camt.053.001.02 BankToCustomerStatementV02 (v1.9, 2023) — accessed 2026-10-04 — https://www.nordea.com/en/doc/nordea-mig-camt-053-001-02-bank-to-customer-statement.pdf
- Nordea — Account Statement Service MT940 file description — accessed 2026-10-04 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- HSBC — Usage Guideline HSBC_MT940_CustomerStatementMessage_Core (SR2013) — accessed 2026-10-04 — https://www.hsbcnet.com/-/media/hsbcnet/client-transition/mt940-ir-specs.pdf
- BAI — Cash Management Balance Reporting Specifications, Version 2 (Technical Reference Manual, 10/2005) — accessed 2026-10-04 — https://cdn.bai.org/migrated-from-www/docs/default-source/libraries/site-general-downloads/cash_management_2005.pdf
- HSBC — BAI2 Statement Message Implementation Guide, Version 1.5 — accessed 2026-10-04 — https://www.hsbcnet.com/-/media/hsbcnet/client-transition/bai2-ir-specs.pdf
- SAP Help — Integration of Bank Statements (One Exposure from Operations, SAP S/4HANA 1610) — accessed 2026-10-04 — https://help.sap.com/doc/a0a0b752bf730226e10000000a4450e5/1610%20002/en-US/0bddfa562f4fff7de10000000a441470.html

## Questions this article answers

**Q: What is the difference between value date and booking date?**

The booking date is when the bank posts the entry to the account on its own books; the value date is when the money becomes available to the account owner on a credit, or stops being available on a debit. Those are ISO 20022's definitions of BookingDate and ValueDate on a statement entry. The two are often the same day, but an entry can be booked today with a value date in the past (back-valued) or in the future (forward-valued), and when they differ the booked balance and the value-dated balance of the account differ too.

**Q: What is the entry date on a bank statement?**

Entry date is the MT940 name for the booking date. In the :61: statement line it is subfield 2, four digits in MMDD form, placed directly after the six-digit value date; Nordea's MT940 description glosses it as 'Booking date (MMDD)'. It is optional in the base format and carries no year, so a parser has to infer the year from the statement's own dates. camt.053 calls the same thing BookingDate, and BAI2 has no per-transaction equivalent at all.

**Q: Which date should a cash position use, value date or booking date?**

Value date, by established treasury practice, because a position answers what cash is available on a given day, and availability is what the value date records. Booking date answers a different question: which day's statement an entry belongs to, and therefore what you reconcile against the ledger. The formats define the dates; they do not prescribe which one your position uses, so this is a design decision to make explicitly rather than inherit from a field mapping.

**Q: Which date does SAP use for the cash position?**

For bank statement items integrated into One Exposure, SAP's documentation for S/4HANA 1610 says the transaction date and amount are determined from the bank statement item and its value date, and its example creates a bank-cash flow on the item's value date and, on the statement date, the flows that convert it to confirmed bank cash. That page covers statements integrated directly into One Exposure; how posted statement items reach the position through accounting documents, and the field-level mapping in the bank statement tables, are not verified in this post.

---

# ACH Return Codes: NACHA File Format and R01–R85 List

Source: https://gravam.com/blog/nacha-ach-file-format-and-return-codes
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: Every NACHA ACH return code from R01 to R85 with its official title, and the file behind it: record types 1–9, key fields, SEC codes and return time frames.

**ACH return codes are the three-character reason codes — R01 to R85, 70 of them in force — that a receiving bank puts on an ACH entry it sends back, and they travel inside the same fixed-width NACHA file format that carried the payment out.** The format is six record types in nested envelopes; the return is an entry detail record plus an addenda record carrying the code. Read the file and the code list together and a bounced US payment stops being a bank phone call.

Nacha publishes the rulebook and its return-code appendix as paid products, so this post works the way the [pain.002 reject codes post](https://gravam.com/blog/pain-002-status-and-reject-codes) does: Nacha's own public rule pages and its [ACH Guide for Developers](https://achdevguide.nacha.org/ach-file-details) for structure and rule changes, cross-checked against the Federal Reserve's FedACH forms and bank-published code cards for the titles.

## The file: six record types, 94 characters each

Every record is exactly 94 characters, and the file is blocked in tens: if the record count isn't a multiple of ten, the file is padded with lines of 9s. The first character of each line is the record type:

| Record | Name | What it carries |
| --- | --- | --- |
| 1 | File header | Immediate destination and origin, creation date and time, file ID modifier, record size 094, blocking factor 10 |
| 5 | Batch header | Service class, company name and identification, SEC code, entry description, effective entry date |
| 6 | Entry detail | Transaction code, receiving bank routing, account number, amount, receiver name, trace number |
| 7 | Addenda | Remittance data, or the return / notification-of-change detail |
| 8 | Batch control | Entry/addenda count, entry hash, total debits and credits for the batch |
| 9 | File control | Batch count, block count, entry/addenda count, entry hash and totals for the file |

A file holds one or more batches (5 … 8), a batch holds one or more entries (6), and each entry may carry addenda (7). That nesting is the same idea as [BAI2's 01–99 envelopes](https://gravam.com/blog/bai2-file-format-explained) — header, content, trailer with checkable totals — just on the outbound side.

## The fields that decide whether it posts

**File header.** The immediate destination is a space followed by the nine-digit routing number of the bank receiving the file; the file ID modifier (a capital letter or digit) tells apart two files created on the same day.

**Batch header.** The **service class code** declares the batch's direction: 200 mixed debits and credits, 220 credits only, 225 debits only (a debits-only batch is the ACH counterpart of a [pain.008 direct debit initiation](https://gravam.com/blog/pain-008-direct-debit-initiation) file). The **company identification** identifies you as the originator. The **company entry description** is the ten characters that often appear on the receiver's statement — and since 20 March 2026 two values are mandated: `PAYROLL` for PPD credits paying wages and similar compensation, and `PURCHASE` for consumer debits authorising online purchases, per Nacha's [company entry description rule](https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions). The **effective entry date** is the date you want the entries to settle; the **settlement date** is left blank because the ACH Operator fills it in. The originating DFI identification is the first eight digits of your bank's routing number.

**Entry detail.** The receiving DFI identification is the first eight digits of the receiver's routing number, with the ninth — the check digit — in its own field. The account number field is 17 characters, the amount is in cents with no decimal point, and the addenda record indicator (0 or 1) says whether a 7 record follows. The **trace number** is 15 digits: your bank's eight-digit routing prefix plus a sequence number, ascending within the batch. Every return and every notification of change quotes it back, so it is the key your reconciliation should hold on to — the ACH equivalent of the pain.001 `EndToEndId`.

The **transaction code** is the first data field and decides debit versus credit and checking versus savings:

| Code | Meaning |
| --- | --- |
| **22** | Checking (demand) account credit |
| **23** | Prenotification of checking credit |
| **27** | Checking (demand) account debit |
| **28** | Prenotification of checking debit |
| **32** | Savings account credit |
| **33** | Prenotification of savings credit |
| **37** | Savings account debit |
| **38** | Prenotification of savings debit |

A prenote is a zero-dollar entry that tests the routing and account number before the first live payment. It proves the account exists and can take entries; it does not prove it belongs to the payee you think it does.

**Controls.** The batch and file control records repeat counts and totals, plus an **entry hash**: the sum of the eight-digit receiving DFI identifications of every entry, truncated to the rightmost ten digits. Entry and addenda records both count; headers and controls don't. The totals exist so that a truncated or altered file cannot balance — the same checkable arithmetic BAI2 trailers hand you on the way back.

## SEC codes: what kind of payment the batch is

The **Standard Entry Class** code in the batch header tells every bank in the chain which rules apply — authorisation requirements, return windows, which addenda are allowed. The ones a corporate treasury originates or receives:

| Code | Name | Used for |
| --- | --- | --- |
| **PPD** | Prearranged Payment and Deposit | Consumer accounts on a standing or single authorization: payroll, consumer direct debits |
| **CCD** | Corporate Credit or Debit | Business-to-business payments and collections; zero or one addenda record |
| **CTX** | Corporate Trade Exchange | B2B payments carrying full remittance: up to 9,999 addenda records per entry |
| **WEB** | Internet-Initiated/Mobile Entry | Consumer payments authorised through a website or mobile app |
| **TEL** | Telephone-Initiated Entry | Consumer debits authorised by telephone |
| **IAT** | International ACH Transaction | Entries with a cross-border leg, carrying a mandatory set of IAT addenda |

Others matter mostly because return codes refer to them: ARC, BOC and POP convert paper checks into ACH debits, RCK re-presents a returned check, XCK replaces a destroyed check, and ENR is the automated enrollment federal agencies use for direct deposit. On the SAP side, the payment medium workbench format `ACH` carries CCD, CTX and PPD as format supplements; how the format tree maps F110 data into those fields is in the [DMEE post](https://gravam.com/blog/sap-dmee-payment-file-format-tree).

## How a return comes back

A return is an ordinary entry detail record in a file from your bank, followed by a **type 99 addenda record**: the return reason code in positions 04–06, the original entry trace number in 07–21, a date of death for R14/R15, and the original receiving DFI identification.

The clocks matter as much as the codes. The receiving bank (RDFI) has **two banking days** after settlement for most returns. **Unauthorized consumer returns — R05, R07, R10, R11 — get 60 calendar days.** R29, the corporate version, stays on two banking days. If your bank (the ODFI) thinks a return is itself wrong, it can **dishonor** it within five banking days of the return's settlement, and the RDFI can **contest** that dishonor within two banking days; after that the dispute leaves the network.

A **notification of change** is different: a zero-dollar COR entry with a **type 98 addenda**, carrying a C code (C01 incorrect account number, C02 incorrect routing number, C05 incorrect transaction code) and the corrected value. The payment posted; your master data didn't match. The NOC tells you exactly which field to change on the vendor or customer record before the next run.

## ACH return reason codes: the full list

Titles below are Nacha's, condensed where the official wording runs to a paragraph.

### R01–R33: the returns an originator sees

| Code | Nacha title |
| --- | --- |
| **R01** | Insufficient Funds |
| **R02** | Account Closed |
| **R03** | No Account/Unable to Locate Account |
| **R04** | Invalid Account Number Structure |
| **R05** | Unauthorized Debit to Consumer Account Using Corporate SEC Code |
| **R06** | Returned per ODFI's Request |
| **R07** | Authorization Revoked by Customer |
| **R08** | Payment Stopped |
| **R09** | Uncollected Funds |
| **R10** | Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver's Account |
| **R11** | Customer Advises Entry Not in Accordance with the Terms of the Authorization |
| **R12** | Account Sold to Another DFI |
| **R13** | Invalid ACH Routing Number |
| **R14** | Representative Payee Deceased or Unable to Continue in That Capacity |
| **R15** | Beneficiary or Account Holder (Other Than a Representative Payee) Deceased |
| **R16** | Account Frozen/Entry Returned per OFAC Instruction |
| **R17** | File Record Edit Criteria/Entry with Invalid Account Number Initiated Under Questionable Circumstances/Return of Improperly-Initiated Reversal |
| **R18** | Improper Effective Entry Date |
| **R19** | Amount Field Error |
| **R20** | Non-Transaction Account |
| **R21** | Invalid Company Identification |
| **R22** | Invalid Individual ID Number |
| **R23** | Credit Entry Refused by Receiver |
| **R24** | Duplicate Entry |
| **R25** | Addenda Error |
| **R26** | Mandatory Field Error |
| **R27** | Trace Number Error |
| **R28** | Routing Number Check Digit Error |
| **R29** | Corporate Customer Advises Not Authorized |
| **R30** | RDFI Not Participant in Check Truncation Program |
| **R31** | Permissible Return Entry (CCD and CTX only) |
| **R32** | RDFI Non-Settlement |
| **R33** | Return of XCK Entry |

### R34–R39: limited participation and converted checks

| Code | Nacha title |
| --- | --- |
| **R34** | Limited Participation DFI |
| **R35** | Return of Improper Debit Entry |
| **R36** | Return of Improper Credit Entry |
| **R37** | Source Document Presented for Payment |
| **R38** | Stop Payment on Source Document |
| **R39** | Improper Source Document/Source Document Presented for Payment |

### R40–R47: automated enrollment (ENR) only

| Code | Nacha title |
| --- | --- |
| **R40** | Return of ENR Entry by Federal Government Agency |
| **R41** | Invalid Transaction Code |
| **R42** | Routing Number/Check Digit Error |
| **R43** | Invalid DFI Account Number |
| **R44** | Invalid Individual ID Number/Identification Number |
| **R45** | Invalid Individual Name/Company Name |
| **R46** | Invalid Representative Payee Indicator |
| **R47** | Duplicate Enrollment |

### R50–R53: re-presented checks (RCK) only

| Code | Nacha title |
| --- | --- |
| **R50** | State Law Affecting RCK Acceptance |
| **R51** | Item Related to RCK Entry is Ineligible or RCK Entry is Improper |
| **R52** | Stop Payment on Item Related to RCK Entry |
| **R53** | Item and RCK Entry Presented for Payment |

### R61–R77: dishonored and contested dishonored returns

R61–R70 are sent by the ODFI dishonoring a return; R71–R77 by the RDFI contesting that dishonor.

| Code | Nacha title |
| --- | --- |
| **R61** | Misrouted Return |
| **R62** | Return of Erroneous or Reversing Debit |
| **R67** | Duplicate Return |
| **R68** | Untimely Return |
| **R69** | Field Error(s) |
| **R70** | Permissible Return Entry Not Accepted/Return Not Requested by ODFI |
| **R71** | Misrouted Dishonored Return |
| **R72** | Untimely Dishonored Return |
| **R73** | Timely Original Return |
| **R74** | Corrected Return |
| **R75** | Return Not a Duplicate |
| **R76** | No Errors Found |
| **R77** | Non-Acceptance of R62 Dishonored Return |

### R80–R85: international (IAT) entries

| Code | Nacha title |
| --- | --- |
| **R80** | IAT Entry Coding Error |
| **R81** | Non-Participant in IAT Program |
| **R82** | Invalid Foreign Receiving DFI Identification |
| **R83** | Foreign Receiving DFI Unable to Settle |
| **R84** | Entry Not Processed by Gateway |
| **R85** | Incorrectly Coded Outbound International Payment |

**The gaps are real.** R48–R49, R54–R60, R63–R66 and R78–R79 are not assigned. Lists that still show R63–R66 ("incorrect dollar amount", "incorrect transaction code" and so on) are describing field errors that the current rules carry inside an **R69** dishonored return, as field codes 01–07 in the addenda. A code table built from one of those lists will map codes your bank never sends. All 70 codes above are current: Nacha's recent changes repurposed codes rather than retiring them (next section). R30 and R33 belong to check-truncation and destroyed-check programmes a corporate originator will rarely touch.

## The codes whose meaning moved

Three rule changes decide how you read a code, and a code table older than the first two will misroute returns today:

- **R10 and R11, April 2020.** Nacha [split the unauthorized reasons](https://www.nacha.org/rules/differentiating-unauthorized-return-reasons): R10 now means no relationship or no authorization at all; R11 was repurposed to mean an authorization exists but the entry broke its terms — wrong amount, debited early, or part of an incomplete transaction. R11 counts as an unauthorized return for return-rate purposes, and since April 2021 it also carries the unauthorized entry fee.
- **R06 and R17, 1 October 2024.** An ODFI may now [request a return for any reason](https://www.nacha.org/rules/risk-management-topics-october-1-2024) (R06; the RDFI's compliance is optional). And an RDFI may use R17 to return an entry it believes was [initiated under questionable circumstances](https://www.nacha.org/rules/return-questionable-transaction) — account takeover, business email compromise, payee impersonation — with `QUESTIONABLE` in the addenda information.
- **R16 and R90, 17 March 2028.** A new [R90, "Entry Returned Due to RDFI's Sanctions Compliance Obligations"](https://www.nacha.org/rules/new-return-reason-code-sanctions-compliance-obligations), takes over sanctions returns, and R16 narrows to frozen accounts. Approved, not yet live — which is why it sits outside the list above.

> An R17 with QUESTIONABLE in the addenda is not a data error to fix and resend. It is the receiving bank telling you the payment was probably induced by someone other than your real counterparty.

That matters for [payment fraud controls](https://gravam.com/blog/payment-fraud-prevention-in-treasury): an R17 QUESTIONABLE on a vendor payment is the signature of an invoice-redirection fraud that already got past your beneficiary checks, and it belongs in the fraud queue, not the repair queue.

## The return rates Nacha watches

Returns are also a scorecard. Nacha's [risk and enforcement rules](https://www.nacha.org/rules/ach-network-risk-and-enforcement-topics) set an **unauthorized return rate threshold of 0.5%** (R05, R07, R10, R11, R29, R51), an **administrative return rate level of 3.0%** (R02, R03, R04) and an **overall return rate level of 15.0%** for debits. The threshold is a limit the originator has to get back under; a level is the point at which Nacha may open a preliminary inquiry into the origination practices behind it. If you collect by ACH, those three numbers belong on the same dashboard as your DSO.

## Where returns meet your treasury system

You rarely read the raw return file. Returns reach treasury through the bank's reporting: a BAI2 detail record, or a camt.053/[camt.054](https://gravam.com/blog/camt-054-notification-explained) entry — Nacha publishes an [ISO 20022 guide](https://www.nacha.org/system/files/2023-08/NACHA_ISO20022_Guide_camt.053_returns%2008-09-23.pdf) to carrying the ACH return data in camt.053. From there the [EBS posting rules](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) have to recognise the line as a return, find the original by trace number, and reverse the clearing. What I would build: keep the R code as data on the reversal, and route by family — R02/R03/R04/C-codes to master-data repair, R01/R09 to cash and collections, R05/R07/R10/R11/R29 to the customer and mandate owner, R17 QUESTIONABLE to fraud. And key the table by code set: an ACH **return** and an ISO 20022 **reject** are different lists, exactly as [pain.002 rejects and SEPA returns](https://gravam.com/blog/pain-002-status-and-reject-codes) are.

Same Day ACH is about to carry bigger payments: its per-payment limit rises from $1 million to [$10 million on 17 September 2027](https://www.nacha.org/news/same-day-ach-payment-limit-increase-10-million). A mishandled return on a single $10 million payment is a cash-positioning problem, not a back-office one.

***

_See also the [BAI2 file format walkthrough](https://gravam.com/blog/bai2-file-format-explained), [bank statement formats: MT940 vs camt.053 vs BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), [pain.002 status and reject codes](https://gravam.com/blog/pain-002-status-and-reject-codes), and [payment fraud prevention in treasury](https://gravam.com/blog/payment-fraud-prevention-in-treasury)._

## Primary sources

Nacha Operating Rules as in force on 2026-09-25 (2026 edition, including the October 2024 R06/R17 amendments, the March and June 2026 fraud-monitoring phases and the 18 September 2026 IAT definition rule); R90 and the $10 million Same Day ACH limit are approved but not yet effective. Nacha's rulebook and its return-code appendix are paid publications and nacha.org could not be fetched directly, so every code title, field rule and date was checked on 2026-09-25 through cross-checked excerpts of the listed sources: Nacha's own rule pages and developer guide, the Federal Reserve's FedACH forms, and bank-published code cards. Your ODFI's origination guide is the contract for what it accepts.

- Nacha — ACH Guide for Developers: ACH File Details — accessed 2026-09-25 — https://achdevguide.nacha.org/ach-file-details
- Nacha — Differentiating Unauthorized Return Reasons (R10/R11) — accessed 2026-09-25 — https://www.nacha.org/rules/differentiating-unauthorized-return-reasons
- Nacha — Risk Management Topics, October 1, 2024 (R06 and R17) — accessed 2026-09-25 — https://www.nacha.org/rules/risk-management-topics-october-1-2024
- Nacha — Return for Questionable Transaction — accessed 2026-09-25 — https://www.nacha.org/rules/return-questionable-transaction
- Nacha — ACH Network Risk and Enforcement Topics (return rate threshold and levels) — accessed 2026-09-25 — https://www.nacha.org/rules/ach-network-risk-and-enforcement-topics
- Nacha — New Return Reason Code for Sanctions Compliance Obligations (R90) — accessed 2026-09-25 — https://www.nacha.org/rules/new-return-reason-code-sanctions-compliance-obligations
- Nacha — Risk Management Topics: Company Entry Descriptions — accessed 2026-09-25 — https://www.nacha.org/rules/risk-management-topics-company-entry-descriptions
- Nacha — Same Day ACH Per Payment Limit to Increase to $10 Million — accessed 2026-09-25 — https://www.nacha.org/news/same-day-ach-payment-limit-increase-10-million
- Nacha — ISO 20022 Guide to Mapping U.S. ACH Returns (camt.053) — accessed 2026-09-25 — https://www.nacha.org/system/files/2023-08/NACHA_ISO20022_Guide_camt.053_returns%2008-09-23.pdf
- Federal Reserve Financial Services — FedACH Contested Dishonored Return Item instructions — accessed 2026-09-25 — https://www.frbservices.org/binaries/content/assets/crsocms/forms/ach/contested-dishonor-instructions.pdf
- Commerce Bank — ACH Return, NOC and Transaction Codes card — accessed 2026-09-25 — https://www.commercebank.com/-/media/cb/pdf/business/commerce-connections/noccodes.pdf

## Questions this article answers

**Q: What is the difference between ACH return codes R10 and R11?**

Since Nacha's rule change of 1 April 2020, R10 means the customer says the originator is not known to them or is not authorized to debit the account at all — there is no authorization relationship. R11 means there is a relationship and an authorization exists, but the entry does not match its terms: a different amount than authorized, a debit settled earlier than authorized, or a debit that is part of an incomplete transaction. Both are consumer unauthorized returns with the 60-day window, but R10 tells you to stop debiting that account, while R11 tells you to fix how you debit it.

**Q: How long does a bank have to return an ACH payment?**

The default is two banking days after the settlement date of the original entry, which covers the administrative returns like R01 insufficient funds, R02 account closed, R03 no account and R04 invalid account number. Unauthorized returns on consumer accounts — R05, R07, R10 and R11 — have an extended window of 60 calendar days after settlement. A corporate account's unauthorized claim, R29, stays on the two-banking-day clock. Past those windows the RDFI can no longer use the ACH return, and the dispute moves outside the network.

**Q: What does R17 QUESTIONABLE mean on an ACH return?**

Since 1 October 2024, a receiving bank may use R17 to return an entry it believes was initiated under questionable circumstances, such as account takeover, business email compromise or payee impersonation, and it marks that use with the word QUESTIONABLE in the addenda information of the return. Using R17 this way is optional for the bank. For an originator it is a fraud signal rather than a data error: the payment was probably induced by someone other than your genuine counterparty, so the right response is an investigation, not a resend.

**Q: What is the difference between an ACH return and a notification of change?**

A return sends the money back: the entry did not post, it comes back with an R code in a type 99 addenda record, and you have to act before paying or collecting again. A notification of change is a zero-dollar COR entry that says the entry posted but some of your data is wrong, with a C code such as C01 incorrect account number or C02 incorrect routing number in a type 98 addenda. The payment went through; the NOC asks you to correct the master data before the next one.

---

# camt.052 vs MT942: The Intraday Report, Field by Field

Source: https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-09-04
Reviewed: 2026-09-04
Summary: camt.052 and MT942 side by side: what each intraday report carries, the balances camt.052 may omit, MT942's floor limit and totals, and where banks diverge.

**camt.052 is the ISO 20022 BankToCustomerAccountReport and MT942 is the SWIFT Interim Transaction Report — the two intraday messages a bank sends between statements — and the whole difference between them and their end-of-day siblings is that neither is a statement: MT942 carries no balances, camt.052 may carry none, and camt.052 may include pending items as well as booked ones.** The end-of-day trio is covered elsewhere — the [camt.053 field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields), the [MT940 tag walkthrough](https://gravam.com/blog/mt940-format-tags-explained), the [BAI2 record walkthrough](https://gravam.com/blog/bai2-file-format-explained) — and the [camt.054 notification](https://gravam.com/blog/camt-054-notification-explained) is the third member of the camt family. This post is for the day an intraday feed is on the table: what each message actually holds, where the two are structurally different, and the places two banks' published guides show them diverging from the standard.

The usual reason to care is an intraday cash position or same-day reconciliation. Both messages exist so the treasury does not wait for the statement; both are routinely fed into the same importer as the statement; and both are wrong to treat as one. The [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) explains the family choice; here the question is what the intraday message is.

## What ISO says camt.052 is for

The Message Definition Report is unusually direct. The BankToCustomerAccountReport "is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time." The usage section lists what it can be used for — "report pending and booked items; provide balance information" — and closes with the sentence that decides most design arguments: "For a statement, the Bank-to-Customer Account Statement message should be used."

Three things in that scope drive everything below. _Reported_ entries, not booked ones. _And/or_ balance information — a report is allowed to be one or the other. And _pending_ items are in scope, which no statement carries.

Payments Canada's usage guideline for camt.052.001.08 restates the same scope and usage text verbatim and restricts the base message for its own community — which is what a usage guideline is, and what your bank's version of it will do too.

## The skeleton, and where it differs from camt.053

camt.052 has three building blocks — GroupHeader, Report, SupplementaryData — mirroring camt.053's GroupHeader, Statement, SupplementaryData. Inside `<Rpt>` the shape is the one a camt.053 reader already knows: identification, an optional pagination block, sequence numbers, a creation timestamp, an optional from-to period, the account, then balances and entries.

| Element | camt.052 `<Rpt>` | camt.053 `<Stmt>` | Why it matters |
| --- | --- | --- | --- |
| `<RptPgntn>` / `<StmtPgntn>` | `[0..1]` | `[0..1]` | A long report can be paged; message-level and report-level pagination may not both be present (rule C16 in the MDR) |
| `<ElctrncSeqNb>` | `[0..1]` | `[0..1]` | Gap check between reports — but intraday sequences reset per bank policy, so the check needs the bank's guide |
| `<LglSeqNb>` | `[0..1]` | `[0..1]` | The legal sequence belongs to the statement; on a report it is rarely populated |
| `<FrToDt>` | `[0..1]` | `[0..1]` | The period the report covers — on an intraday report, the window since the last one |
| `<CpyDplctInd>` | `[0..1]` | `[0..1]` | Whether this is a copy or a duplicate; an importer that ignores it books the same report twice |
| **`<Bal>`** | **`[0..*]`** | **`[1..*]`** | **The structural difference.** A statement must carry at least one balance; a report may carry none |
| `<Ntry>` | `[0..*]` | `[0..*]` | Same entry type; on a report the status may be pending |

The multiplicities come straight from the MDR's element tables for camt.052.001.08 and camt.053.001.08. The one worth writing on the wall is the balance: **`[0..*]` on the report, `[1..*]` on the statement.** Every camt.053 importer I have seen assumes a balance exists. Point it at a camt.052 feed and the first report with movements and no `<Bal>` block is a null reference in the cash position at 11:20.

## Entry status: the field that makes it a report

Each `<Ntry>` carries a mandatory `<Sts>`, and in the .08 message it is an external code set (ExternalEntryStatus1Code) rather than an enumeration baked into the schema. The published list distinguishes booked from pending from future and information-only, and an intraday report is where the non-booked values actually appear — a statement contains booked entries only, so a camt.053 parser can get away with never reading the status. A camt.052 parser cannot: a pending entry applied to the position and then booked in the next report is a double count, and a pending entry that is later rejected never becomes a booking at all.

Two rules that survive contact with real feeds:

- **Position from booked, exposure from pending.** Apply booked entries to the running balance; show pending ones as expected movements, never as cash.
- **Key on the bank's entry reference, not on amount and date.** The same booking can appear as pending in one report, booked in a later one, and again in the statement. The reference is what lets you recognise it; amount-and-date matching will happily count it three times.

## Balances on an intraday report

When a bank does send balances on a camt.052, the types come from the same external code set the statement uses (ExternalBalanceType1Code). A statement leans on the opening and closing booked and available types; an intraday report typically leans on the interim types — **ITBD**, interim booked, and **ITAV**, interim available — which say "this is where the account stands at the time in `<CreDtTm>`, not at end of day". Which of these your bank populates, and whether the interim balance includes or excludes pending items, is not in the standard; it is in the bank's guide, and it is the first question to ask before building anything on it.

> Neither intraday message is a statement. MT942 has no balances; camt.052 is allowed to have none. Design the position as movements applied to the last statement, not as a reading of the report.

## MT942: the whole message in eleven tags

MT942 predates all of this and is correspondingly compact. HSBC's usage guideline describes the message as eleven building blocks; Rabobank's format description says what it is for in one sentence — the report "reports debits or credits to the account since the last account statement was made available. Only intraday transactions are reported." The chain, with the multiplicities both guides give:

| Tag | Name | Mult. | Format | What it holds |
| --- | --- | --- | --- | --- |
| `:20:` | Transaction Reference Number | `[1..1]` | `16x` | The sender's reference for this message |
| `:21:` | Related Reference | `[0..1]` | `16x` | Rarely used; Rabobank never provides it |
| `:25:` | Account Identification | `[1..1]` | `35x` | The account reported |
| `:28C:` | Statement Number/Sequence Number | `[1..1]` | `5n[/5n]` | Report number and optional page — see the deviations below |
| `:34F:` | Debit/(Debit and Credit) Floor Limit Indicator | `[1..1]` | `3!a[1!a]15d` | Currency, optional D/C mark, amount: the threshold below which entries are not reported individually |
| `:34F:` | Credit Floor Limit Indicator | `[0..1]` | `3!a[1!a]15d` | A separate credit floor, when the bank reports one |
| `:13D:` | Date/Time Indication | `[1..1]` | `YYMMDDHHMM±HHMM` | When the report was produced, with a UTC offset — the intraday timestamp the position is "as of" |
| `:61:` | Statement Line | `[0..n]` | as in MT940 | One booked movement, same nine subfields as the [MT940 :61: line](https://gravam.com/blog/mt940-format-tags-explained) |
| `:86:` | Information to Account Owner | `[0..1]` | `6*65x` | Under its :61:, bank-specific like the MT940's — HSBC states it carries unstructured transaction description |
| `:90D:` | Number and Sum of Entries (debits) | `[0..1]` | `5n3!a15d` | Count, currency and total of the debit entries in the report |
| `:90C:` | Number and Sum of Entries (credits) | `[0..1]` | `5n3!a15d` | Count, currency and total of the credit entries in the report |

What is absent is the point: there is no `:60a:` opening balance and no `:62a:` closing balance. The `:90D:`/`:90C:` totals are the only arithmetic the message offers, and they check the report against itself — the count and sum of the `:61:` lines above them — not against a balance. An MT942 importer therefore has exactly one integrity test, and it is worth running — with one condition. When the floor limit in `:34F:` is zero, as Rabobank fixes it, every debit is itemised and the sum of debit `:61:` lines must equal `:90D:`; a mismatch means the file is truncated or the parser is wrong. When the floor limit is above zero, entries below it are deliberately absent from `:61:` while the guides define `:90D:`/`:90C:` only as the number and sum of debit and credit entries, so the totals may legitimately exceed the lines — read `:34F:` before trusting the test.

`:13D:` deserves a sentence. It is the only timestamp in the message and it carries a sign and offset, so two banks reporting "as of 14:30" can mean different instants. A position that merges intraday reports from several banks needs to normalise this field to one clock before comparing anything.

## Where the two banks diverge from the standard

This is the part no standard tells you and both guides do.

Rabobank's format description is explicit that its MT942 export "is not completely according to SWIFT format", and lists the deviations: `:28C:` is a fixed `1/1`; `:34F:` is present twice with fixed values `<currency>C0,00` and `<currency>D0,00`; `:90C:` and `:90D:` omit the number of entries between the tag and the currency, "deviating from the SWIFT standard"; the transaction type code in `:61:` is a fixed `NMSC` for Rabo accounts; and the whole message can exceed 2,000 characters. Two of those — the missing count in `:90C:`/`:90D:` and the message length — break a parser written from the field formats above; the fixed `:28C:`, the zero floor limit and the constant `NMSC` are format-valid and break the checks built on top instead (sequence gaps, floor-limit logic, transaction-type routing).

HSBC's guideline keeps the standard formats but states its own conventions: `:28C:` is always padded to five digits (`:28C:00235/0001`), the account in `:25:` is reported without hyphens, and `:86:` is "populated with unstructured information of transaction description downloaded from the bank", with content that "depends on the nature of the underlying transaction/practice of the country".

Two banks, two different things done to the same tag. The lesson is the one every post in this cluster ends on: the bank's guide is the contract, and an intraday feed needs one parser profile per bank exactly as the statement does.

## camt.052 or MT942: which one to ask for

If the bank offers both, the answer is usually the ISO message, for three reasons that are about the data rather than the format war.

- **Structure.** camt.052 carries the entry status, typed balances, the bank transaction code and structured references. MT942 carries a `:61:` line and whatever the bank put in `:86:`.
- **Pending items.** camt.052 can say an item is pending. MT942 has no status at all — everything in it is presented as booked.
- **Pagination and duplicates.** camt.052 has `<RptPgntn>` and `<CpyDplctInd>`; MT942 has `:28C:` and the bank's discipline.

Ask for MT942 when the receiving system only parses FIN, when the bank's camt.052 is a thin wrapper that carries no more than its MT942 does (compare the two guides — it happens), or when the intraday feed is a stopgap on the way to a [migration that is already scheduled](https://gravam.com/blog/iso-20022-migration-mt-to-mx).

## Where intraday positions get corrupted

- **Feeding the intraday message into the statement importer.** It parses — the shapes are similar enough — and then a report with no balance, or a pending entry, silently corrupts the position. Route intraday messages to a path that expects both.
- **Anchoring on the report.** The position is the last statement's closing balance plus booked intraday movements, reset when the next statement lands. An interim balance in a camt.052 is a cross-check, not the anchor.
- **Matching on amount and date.** Pending, then booked, then on the statement: the same movement three times. Key on the bank's entry reference.
- **Ignoring `:34F:`.** A non-zero floor limit means small movements are deliberately missing from the report. It is a one-line check and it prevents a week of "why does intraday never reconcile".
- **Assuming one `:28C:` convention.** One bank pads, one bank fixes it at `1/1`, a third increments it. Sequence checks on MT942 have to be configured per bank, not written once.

Once the intraday feed is in, the same statement data meets the same matching problem the end-of-day one does — and that matching step is where a redesign pays off. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) splits it into what stays deterministic (amount, date, reference within tolerance), what an AI step can read (the free text in `:86:` or `<AddtlNtryInf>`), and what stays with a named human.

***

_See also the [camt.053 field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields), the [camt.054 notification](https://gravam.com/blog/camt-054-notification-explained) and the [MT940 tags line by line](https://gravam.com/blog/mt940-format-tags-explained)._

## Primary sources

camt.052 scope, usage, building blocks and element multiplicities verified against ISO's Message Definition Report Part 2 for the 2018–2019 maintenance (camt.052.001.08) and Payments Canada's camt.052.001.08 usage guideline; MT942 tags, formats and multiplicities against HSBC's MT942 usage guideline and Rabobank's MT942 format description (v2.3). SWIFT's own MT942 specification sits behind the user handbook and is not reproduced. Bank deviations are named where the two guides state them — your bank's guide is the contract.

- ISO 20022 — Message Definition Report Part 2, Bank-to-Customer Cash Management, Maintenance 2018–2019 (camt.052/053/054/060 scope, usage, building blocks and multiplicities) — accessed 2026-09-04 — https://www.iso20022.org/sites/default/files/documents/messages/mdr_part_2/ISO20022_MDRPart2_BankToCustomerCashManagement_2018_2019_v1_0.pdf
- Payments Canada — Usage Guideline camt.052.001.08 BankToCustomerAccountReportV08 — accessed 2026-09-04 — https://www.payments.ca/sites/default/files/BankToCustomerAccountReportV08(camt.052.001.08).pdf
- HSBC — Usage Guideline HSBC_MT942_InterimTransactionReport_Core (SR2013) — accessed 2026-09-04 — https://www.hsbcnet.com/-/media/hsbcnet/client-transition/mt942-ir-specs.pdf
- Rabobank — Format description SWIFT MT942, Rabo Cash Management, v2.3 (November 2014) — accessed 2026-09-04 — https://media.rabobank.com/m/4cd94fc41538ccc4/original/Format-description-MT942-v2-3.pdf
- ISO 20022 — External Code Sets (ExternalEntryStatus1Code, ExternalBalanceType1Code) — accessed 2026-09-04 — https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets

## Questions this article answers

**Q: What is the difference between camt.052 and camt.053?**

camt.052 is the BankToCustomerAccountReport and camt.053 is the BankToCustomerStatement. Structurally they are near-twins — one GroupHeader, then a repeating per-account block, then entries — but the ISO definition draws two lines between them. camt.053 contains booked entries only and its Balance block is mandatory (one or more), because a statement is the balance-anchored record of the day. camt.052 may report pending as well as booked items, and its Balance block is optional (zero or more), so an intraday report can legitimately arrive with movements and no balance at all. ISO's own usage note says it plainly: for a statement, use the statement message.

**Q: What is an MT942?**

MT942 is the SWIFT Interim Transaction Report: the FIN message a bank sends during the day with the debits and credits booked since the last statement or the last interim report. Its tag chain is short — :20: reference, :25: account, :28C: statement/sequence number, :34F: floor limit (once for debits, optionally again for credits), :13D: the date and time the report was produced, then :61: statement lines with optional :86: detail, and :90D:/:90C: with the number and sum of debit and credit entries. It carries no opening or closing balance; those belong to the MT940.

**Q: What does field :34F: mean in an MT942?**

Field :34F: is the floor limit indicator: a currency, an optional D or C mark, and an amount, stating the threshold below which individual entries are not reported in the message. The first :34F: is mandatory and applies to debits (or to both sides when no second :34F: follows); a second, optional :34F: gives a separate credit floor. In practice many banks set it to zero so every movement is reported — Rabobank's export, for example, fixes both at 0,00 — which makes the field boilerplate to parse and still worth reading, because a non-zero limit means the report is deliberately incomplete.

**Q: Which balances does a camt.052 intraday report carry?**

Whatever the bank chooses to send, including none. In camt.052 the Balance block is optional and repeating, unlike camt.053 where at least one balance is mandatory. When a bank does include balances on an intraday report it typically uses the interim balance types from the ISO external code set — ITBD for interim booked and ITAV for interim available — alongside or instead of the opening and closing types a statement carries. A cash position built on camt.052 therefore has to be explicit about which balance type it trusts, and about what it does when the report arrives with entries and no balance.

**Q: Can I build an intraday cash position on MT942 or camt.052 alone?**

Only as a running calculation on top of the last statement, and only if you keep the two apart. Neither message is a statement: MT942 has no balance tags at all, and camt.052 may omit balances and may include pending items. The robust pattern is the previous camt.053 or MT940 closing balance as the anchor, the intraday movements applied on top — booked entries only, unless you have decided how to treat pending ones — and a reset when the next end-of-day statement lands. Treating an interim report as a statement is how an intraday position ends up double-counting a booking that the statement then reports again.

---

# pain.008: SEPA Direct Debit Initiation Explained

Source: https://gravam.com/blog/pain-008-direct-debit-initiation
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-09-01
Reviewed: 2026-09-01
Summary: pain.008 (CustomerDirectDebitInitiation) is the ISO 20022 message a creditor sends to pull funds — mandates, FRST/RCUR sequence types, Core vs B2B, refunds.

**pain.008 — CustomerDirectDebitInitiation — is the ISO 20022 message a creditor sends to its bank to pull money from debtors' accounts.** It is the mirror image of [pain.001](https://gravam.com/blog/pain-001-structure-and-fields): same family, same layered structure, opposite direction of authority. A credit transfer moves your own money out; a direct debit reaches into someone else's account — which is why the interesting parts of pain.008 are exactly the parts pain.001 doesn't have: the mandate data, the sequence types, and the refund rules that decide when collected cash is actually yours.

## Where it sits

In SEPA, pain.008 is the customer-to-bank initiation message for both direct debit schemes — **Core** (consumer) and **B2B** — and `pain.008.001.02` is the version the SEPA implementation guidelines are built on. A creditor batches collections into the file, the creditor's bank distributes them into the clearing, and the results come back as status reports and booked entries: [pain.002](https://gravam.com/blog/pain-002-status-and-reject-codes) for rejects, [camt.053/camt.054](https://gravam.com/blog/camt-054-notification-explained) for what actually hit the account.

## The structure, and what's different from pain.001

The skeleton is family-standard — one group header, one or more payment information blocks, transactions inside them — but the roles flip:

- **The batch level belongs to the creditor.** `PmtInf` carries the creditor's account, its bank, the requested collection date and the scheme (Core or B2B, in `LclInstrm`).
- **Each transaction describes a debtor** (`DrctDbtTxInf`): who to debit, which bank, how much, and the remittance information that should let the debtor recognize the charge.
- **Every transaction carries mandate data.** That is the structural heart of the message, and it has no pain.001 equivalent.

## The mandate block is the message

A direct debit is only as valid as its mandate, and pain.008 makes the creditor restate it on every collection (`MndtRltdInf`):

- **Mandate ID** — the reference of the signed mandate this collection executes.
- **Date of signature** — when the debtor signed it.
- **Creditor identifier (CI)** — the scheme-issued identifier of the collecting creditor, stable across banks, so a debtor can recognize and block a specific creditor rather than a specific account.
- **Amendment indicator and details** — if anything about the mandate changed (creditor account, mandate ID, debtor account), the change travels inside the message.

> The mandate data isn't metadata — it is the legal basis of the collection, restated transaction by transaction. Most direct debit rejects that aren't about money are about this block.

## Sequence types — and the 2016 simplification

Each collection declares its place in the mandate's life: `FRST` (first of a recurrent series), `RCUR` (subsequent), `OOFF` (one-off), `FNAL` (final). Two things changed with the November 2016 Core rulebook (version 9.0) that older documentation still gets wrong:

- **D-1 for everything.** Any collection — first, recurrent or one-off — can be presented up to one inter-bank business day before the due date. The old five-day lead time for first collections is gone.
- **FRST is optional.** A first collection may be flagged plain `RCUR`; many creditors now never send FRST at all.

The debtor still has to know it's coming: the Core scheme requires **pre-notification** before the due date — by default 14 calendar days ahead, unless creditor and debtor have agreed a different timeline (an invoice stating the collection date counts).

## Core vs B2B: the refund line

The two schemes share the message format; they differ in what the debtor can undo:

- **Core:** the debtor can claim a **no-questions-asked refund for eight weeks** after an authorized debit, and up to **thirteen months** for an unauthorized one. Collected cash is conditional until that window closes — treat it that way in [cash positioning](https://gravam.com/blog/cash-positioning-vs-cash-flow-forecasting).
- **B2B:** **no refund right for authorized collections.** The counterweight is upfront: the debtor's bank must verify the mandate with its customer before honouring B2B collections, so a B2B mandate that isn't registered at the debtor bank is a guaranteed reject.

## What goes wrong in practice

- **Mandate data drift.** The mandate ID or signature date in the file stops matching what was actually signed — often after a system migration — and collections start rejecting on formalities.
- **Amendments not flagged.** The creditor changes account or mandate reference and sends the next collection without the amendment block.
- **B2B without registration.** The mandate exists on paper but was never confirmed at the debtor's bank.
- **Treating Core cash as final.** Revenue recognized, position closed — then the eight-week refund arrives as a debit on the [bank statement](https://gravam.com/blog/camt-054-notification-explained).
- **R-transaction blindness.** Rejects, returns and refunds each come back through different channels at different times; if [pain.002](https://gravam.com/blog/pain-002-status-and-reject-codes) and the statement feeds aren't reconciled per collection, the receivables ledger quietly diverges from the bank. (US ACH debits fail the same way; there the reasons arrive as [ACH return codes](https://gravam.com/blog/nacha-ach-file-format-and-return-codes).)

***

_See also [pain.001 structure and fields](https://gravam.com/blog/pain-001-structure-and-fields) and [ISO 20022 payments: pain.001 and pain.002](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002)._

## Primary sources

- EPC — SEPA Direct Debit Core Scheme Rulebook (EPC016-06, 2025 version 1.1) — accessed 2026-09-01 — https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.1.pdf
- EPC — SDD Core Rulebook 2017 v1.0 (the November 2016 D-1 / sequence-type simplification) — accessed 2026-09-01 — https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC016-06%20SDD%20Core%20Rulebook%202017%20version%201.0.pdf
- Nordea — MIG pain.008.001.02 SEPA Direct Debit — accessed 2026-09-01 — https://www.nordea.com/en/doc/mig-pain-008-001-02-direct-debits-sepa.pdf
- ISO 20022 — Message definitions catalogue (pain.008 CustomerDirectDebitInitiation) — accessed 2026-09-01 — https://www.iso20022.org/iso-20022-message-definitions

## Questions this article answers

**Q: What is pain.008?**

pain.008 is the ISO 20022 CustomerDirectDebitInitiation message — the file a creditor sends to its bank to collect money from debtors' accounts by direct debit. It is the mirror image of pain.001: in pain.001 the payer pushes funds out, in pain.008 the payee pulls funds in, on the strength of a mandate the debtor has signed. In SEPA it carries both Core and B2B direct debit collections, and pain.008.001.02 is the version the SEPA implementation guidelines are built on.

**Q: What is the difference between pain.001 and pain.008?**

Direction and authority. pain.001 is a credit transfer initiation — the account owner instructs their own bank to push money out, so no one else's permission is embedded in the message. pain.008 is a direct debit initiation — the creditor instructs its bank to pull money from someone else's account, so every transaction must carry the mandate data (mandate ID, date of signature, creditor identifier) that proves the debtor authorized the collection. Structurally they rhyme: group header, batch level, transaction level — but in pain.008 the batch belongs to the creditor and each transaction describes a debtor.

**Q: What are the SEPA direct debit sequence types FRST, RCUR, OOFF and FNAL?**

The SEPA direct debit sequence types tell the banks where a collection sits in a mandate's life: FRST (first of a recurrent series), RCUR (subsequent recurrent), OOFF (one-off, single-use mandate), FNAL (final collection of a series). Since the November 2016 SDD Core rulebook change (version 9.0), FRST is no longer mandatory — a first collection may be sent as RCUR — and all sequence types can be presented up to one inter-bank business day before the due date (D-1), which removed the old five-day lead time for first collections.

**Q: Can a SEPA direct debit be refunded after collection?**

Under the Core scheme, yes: the debtor can claim a no-questions-asked refund of an authorized collection for eight weeks after the debit, and up to thirteen months for an unauthorized one (no valid mandate). Under the B2B scheme there is no refund right for authorized collections — the trade-off being that the debtor's bank must verify the mandate with the debtor before paying. Creditors should treat Core collections as conditional cash until the refund window closes.

---

# camt.054: The Debit/Credit Notification and When You Need It

Source: https://gravam.com/blog/camt-054-notification-explained
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-03
Reviewed: 2026-08-03
Summary: What camt.054 is — a notification of debits and credits, not a statement — how it differs from camt.053 and camt.052, and the lump-sum breakdown it exists for.

**camt.054 is the ISO 20022 BankToCustomerDebitCreditNotification — the account servicer notifying the account owner of single or multiple debit and/or credit entries — and the single most important sentence in its ISO definition is this one: "It does not contain balance information."** It is not a statement. It doesn't compete with one. Its job is detail: telling you that specific movements happened and what is inside them — most valuably when the statement shows one lump-sum booking and the individual direct debits, giro receipts or card settlements that make it up are documented nowhere else. If you're choosing between statement formats, start with the [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2); if you're parsing statements, the [camt.053 field-by-field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields) is the sibling of this post. This one is about the message that rides alongside the statement, verified against ISO's own Message Definition Report and Nordea's camt.054 implementation guidelines.

> **Figure — One statement line, and the notification that itemises it**
>
> A camt.053 statement, with a balance above and below its entries, shows a single booking of 12,400. An arrow leads to a camt.054 notification that lists the three items inside that booking — 4,100, 5,300 and 3,000 — adding up to the same 12,400. The notification carries no balance.
>
> camt.053 confirms the cash; camt.054 explains it. The amounts are illustrative.

## camt.053 vs camt.054 vs camt.052: three messages, one family

ISO defines the three bank-to-customer cash management messages in one report, and the scope statements draw the lines precisely:

|  | camt.053 Statement | camt.052 Account Report | camt.054 Debit/Credit Notification |
| --- | --- | --- | --- |
| ISO name | BankToCustomerStatement | BankToCustomerAccountReport | BankToCustomerDebitCreditNotification |
| Entries | Booked entries only | Pending and booked items | Pending and booked items; one or more debit and/or credit entries |
| Balances | Mandatory — `<Bal>` is `[1..n]` | Optional — `<Bal>` is `[0..n]` | None — the structure has no balance element |
| Role | The record: complete account activity plus balances for a period | Interim picture of the account, typically intraday | Advice of specific entries, with their underlying transaction detail |

Two of those cells do most of the work. **camt.053 contains booked entries only, with balances the message structure won't let a bank omit** — that's what makes it the reconciliation anchor. **camt.054 has no balance element at all** — ISO's usage text says so outright — which is what makes it a notification rather than any kind of statement. camt.052 sits between them: same skeleton as the statement, but balances optional and pending items allowed, which is why it serves as the intraday refresh in a [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position).

The family resemblance is structural, not cosmetic. One level down, all three messages are a GroupHeader plus a repeating per-account block — `<Stmt>` in 053, `<Rpt>` in 052, `<Ntfctn>` in 054, each `[1..n]` with one `<Acct>` and `[0..n]` entries. The intraday member, camt.052, gets its own [field-by-field walkthrough against MT942](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942). There's even a fourth relative: camt.060, the AccountReportingRequest, is the message a customer sends to ask the bank for any of the three. Versions travel together too — as of August 2026 the ISO catalogue lists all three at version 14 (camt.054.001.14), while the archive runs from camt.054.001.01 in 2007 through .13 in 2025 — and, exactly as with the statement, what banks deliver is much older: both Nordea camt.054 MIGs implement camt.054.001.02, defined in the 2009 payments maintenance cycle.

## The skeleton: a statement minus the balances

The message root is `<BkToCstmrDbtCdtNtfctn>`. An illustrative skeleton, built from the elements in Nordea's MIGs (not a complete or valid instance):

```xml
<BkToCstmrDbtCdtNtfctn>
  <GrpHdr>
    <MsgId>…</MsgId>            <!-- bank's unique message reference -->
    <CreDtTm>…</CreDtTm>
    <AddtlInf>/CRED/</AddtlInf> <!-- Nordea: credit-only notification -->
  </GrpHdr>
  <Ntfctn>                      <!-- [1..n] one per account -->
    <Id>…</Id>
    <CreDtTm>…</CreDtTm>
    <Acct>
      <Id><IBAN>…</IBAN></Id>   <!-- or <Othr> for non-IBAN accounts -->
    </Acct>
    <Ntry>                      <!-- [0..n] the notified movements -->
      <NtryDtls>                <!-- [0..n] -->
        <TxDtls>…</TxDtls>      <!-- [0..n] the payload -->
      </NtryDtls>
    </Ntry>
  </Ntfctn>
</BkToCstmrDbtCdtNtfctn>
```

The `<Ntfctn>` block carries the same furniture as a camt.053 `<Stmt>` — identification, pagination, sequence numbers, creation time, the account, a transactions summary — with one omission: where the Statement type carries `Balance [1..n]`, the Notification type simply has no balance element. That is the entire structural difference at this level, and it's deliberate.

From the entry downward, the two messages are the _same_ structure. In the .001.02 generation, camt.053 and camt.054 both use `ReportEntry2` for the entry, `EntryDetails1` for the details container and `EntryTransaction2` for the transaction — identical types, straight from the MIGs. So everything the [camt.053 walkthrough](https://gravam.com/blog/camt-053-structure-and-fields) says about `<Amt>` and `<CdtDbtInd>`, `<Sts>`, booking versus value date, `<AcctSvcrRef>`, the Bank Transaction Code and the Entry → EntryDetails → TransactionDetails nesting applies verbatim here, and I won't repeat it. Two notification-specific observations from Nordea's implementation instead:

- **Banks often ship camt.054 as two products, not one.** ISO allows a mixed notification — debits, credits, or both. Nordea publishes separate MIGs for a credit notification and a debit notification, and flags the flavor in the GroupHeader's `<AddtlInf>`: `/CRED/` for credit-only, `/DEBT/` for debit-only. What you receive is a service decision, so an importer should key on the message content, not on an assumption that one feed carries everything.
- **The bookkeeping is thorough**: Nordea's notification `<Id>` is unique for at least 90 days (built from timestamp, currency and the last four digits of the account), `<NtryRef>` increments by one per entry, and the transaction-level `<MsgId>` in the debit MIG increments per TransactionDetails block. Free ordering and duplicate checks, if you store them.

## The reason it exists: the lump-sum breakdown

Here is the scenario camt.054 earns its keep in. The bank books **one collective entry** on your account for a whole collection — and the statement, correctly, shows one line. Nordea's credit MIG documents the mechanics under the heading "batch (lump-sum) booking": the entry-level Bank Transaction Code becomes a batch-level classification, and the individual receipts exist as `<TxDtls>` blocks with their own transaction-level codes. Concretely, from its appendix:

- A Swedish batch credit arrives as an entry classified `PMNT-RCDT-NTAV`, and inside it the details resolve to the actual instruments: SEPA credit transfers (`ESCT`), domestic transfers (`DMCT`), cross-border credits (`XBCT`), lockbox deposits (`LBOX-LBDP`).
- A Finnish SEPA Core Direct Debit collection — initiated by [pain.008](https://gravam.com/blog/pain-008-direct-debit-initiation) — arrives as an entry classified `PMNT-RDDT-ESDD` — one credit for the collection run, each collected debit a detail beneath it.
- The entry's `<Amt>` is, in the MIG's own words, "the total of one or many entry details" — which hands you the integrity check: sum the details, compare to the entry, and only then clear anything.

The reconciliation flow that falls out: **camt.053 confirms the cash; camt.054 explains it.** The statement's lump-sum entry ties out the position. The notification entry describing the same booking carries the itemisation — per-transaction remittance data (structured creditor references, `CINV` invoice numbers, RF references under `SCOR`/ISO 11649 in Nordea's implementation) — and cash application clears the individual open items against those details instead of against one opaque total.

The same logic runs on the debit side, pointed at your own payments. A [pain.001](https://gravam.com/blog/pain-001-structure-and-fields) batch that the bank books collectively is one debit on the statement — and the camt.054 debit notification is where each payment inside it reports back individually. Nordea's debit MIG returns, per TransactionDetails: `<PmtInfId>` (always present when the instruction went through their channel with a payment ID), `<InstrId>` (present if you used it), and `<EndToEndId>` ("unique reference returned if used by the ordering customer"). That is the loop closing per payment even though the account moved once.

One honest nuance from the same MIG: sometimes even the notification doesn't itemise. For card acquiring settlements in Denmark and Sweden (and BankAxept in Norway — where POS settlements are explicitly "only lump-sum information reported"), the notification carries a proprietary POS reference and the actual specification of included transactions comes from the external provider. The camt.054 then isn't the breakdown — it's the key to fetch the breakdown somewhere else. Know which of the two you've been sold.

## What camt.054 doesn't do

- **No balances, so no position.** You cannot build a cash position from notifications; there is no opening or closing figure to anchor the arithmetic, and ISO's definition rules one out by design. Positions come from [camt.053 plus intraday camt.052](https://gravam.com/blog/how-to-build-a-daily-cash-position); global [cash visibility](https://gravam.com/blog/how-to-achieve-global-cash-visibility) is built on statement coverage, not notification coverage.
- **Coverage is a service definition.** The statement reports the account's activity; the notification reports what the notification _service_ includes. Nordea's MIGs spell this out per country — the credit notification enumerates the included receipt types for Denmark, Finland, Norway and Sweden (down to items like MobilePay and Swish), and the debit notification covers transactions originating from pain.001 plus specific local flows. An entry type outside the list simply never appears in your camt.054, while it will appear on the statement.
- **Pending items are possible in the standard, not necessarily in your feed.** ISO's scope allows the notification to report pending as well as booked items; Nordea sends `<Sts>` BOOK only. Same discipline as with the statement: check what your bank sends, and filter deliberately.

## When you actually need it — and when you don't

You need a camt.054 feed when the detail you reconcile against doesn't live on the statement. The classic triggers: **direct-debit collections** you present as batches but post per customer; **giro / OCR-reference receivables** where hundreds of consumer payments settle as one credit; **card settlement** streams; **lockbox** deposits; and collectively-booked **payment runs** whose individual invoices your ERP clears one by one. In each case the statement entry is a sum, and cash application without the itemisation degenerates into re-deriving the batch by hand.

You probably don't need it when the detail already reaches you another way. If the bank books singles — or itemises the batch inside the statement's own `<TxDtls>` — the camt.053 carries everything, and a notification feed adds a second copy of the same data plus a deduplication problem. Which of those worlds you live in is the booking arrangement you negotiated with the bank, the exact point the [camt.053 post](https://gravam.com/blog/camt-053-structure-and-fields) makes about batch versus single booking: it's agreed, not discovered. And on delivery timing — how often and how promptly notifications arrive — the standard says nothing; it's a line in your service agreement, so ask, don't assume.

## Where camt.054 integrations break

- **Treating it as a statement.** No balances means no completeness anchor. The statement remains the record; the notification annotates it.
- **Double-counting.** The same booking arrives in the camt.054 and again in the camt.053. Dedupe deliberately; the natural join key is the bank's entry reference (`<AcctSvcrRef>`, "will always be reported" in Nordea's credit MIG) — but the MIGs document each message separately and don't promise the reference is identical across both, so treat cross-message matching as a test case with your bank, not an assumption.
- **Assuming one feed carries both directions.** `/CRED/` and `/DEBT/` products exist; subscribe to what you actually need and parse what you actually get.
- **Assuming full coverage.** The per-country included-transaction lists in the MIG are the contract. If a flow isn't on the list, its detail has to come from somewhere else.
- **Version drift.** The catalogue is at camt.054.001.14; production channels widely implement .001.02 from 2009. Same caution as for the statement: the bank's MIG and version are the contract, and types change shape between versions.

Once the notification has broken the lump sum into its items, the work left is matching them — and that is the step worth redesigning rather than re-keying. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) splits it into what stays deterministic (amount, date, reference within tolerance), what an AI step can read (the remittance text that never matched anything), and what stays with a named human (the write-off).

The design is coherent once you see the division of labor: one message that is complete and balance-anchored, one that is fast and balance-free, and one — this one — that carries the detail the other two book as a single line. Use the statement to prove the cash, and the notification to explain it.

***

_See also [bank statement formats: MT940 vs camt.053 vs BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), [the camt.053 field-by-field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields), [pain.001 structure and fields](https://gravam.com/blog/pain-001-structure-and-fields), [how to build a daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position), and [ACH return codes](https://gravam.com/blog/nacha-ach-file-format-and-return-codes)._

## Primary sources

Scope statements and message structures verified against ISO's Message Definition Report for Bank-to-Customer Cash Management (camt.052/053/054.001.09, Maintenance 2020-2021) and Nordea's camt.054.001.02 credit and debit notification MIGs; the ISO catalogue is at BankToCustomerDebitCreditNotificationV14. Verify against your bank's MIG and version.

- ISO 20022 — Message Definition Report Part 2, Bank-to-Customer Cash Management, Maintenance 2020–2021 (camt.052/053/054.001.09) — accessed 2026-08-03 — https://www.iso20022.org/sites/default/files/2020-12/ISO20022_MDRPart2_BankToCustomerCashManagement_2020_2021_v1_ForSEGReview.pdf
- Nordea — Corporate Access MIG camt.054.001.02 Credit Notification (v1.9, 2022) — accessed 2026-08-03 — https://www.nordea.com/en/doc/nordea-caar-camt.054.001.02-credit-notification.pdf
- Nordea — Corporate eGateway MIG camt.054.001.02 Debit Notification (v1.9, 2020) — accessed 2026-08-03 — https://www.nordea.com/en/doc/nordea-mig-camt-054-001-02-debit.pdf
- ISO 20022 — Message definitions catalogue and messages archive (camt.054 BankToCustomerDebitCreditNotification) — accessed 2026-08-03 — https://www.iso20022.org/iso-20022-message-definitions

## Questions this article answers

**Q: What is the difference between camt.053 and camt.054?**

camt.053 is the BankToCustomerStatement: booked entries only, with balance information that the message structure makes mandatory — the complete, balance-anchored record of the account for a period. camt.054 is the BankToCustomerDebitCreditNotification: it notifies single or multiple debit and/or credit entries, may include pending as well as booked items, and — in ISO's own words — does not contain balance information. In practice the statement proves the money moved; the notification itemises what moved. The pairing matters most when the statement books one lump-sum entry for a whole collection and the camt.054 carries the individual transactions inside it.

**Q: What is the difference between camt.052 and camt.054?**

camt.052 and camt.054 are both interim messages next to the end-of-period camt.053, but they answer different questions. camt.052 is the BankToCustomerAccountReport — a picture of the account that can carry entries and balance information (its Balance element is optional, 0..n), typically used intraday to refresh the cash position. camt.054 is entry-centric: it has no balance element at all and exists to notify specific debits and credits with their underlying transaction detail. Use camt.052 to know where the account stands during the day; use camt.054 to know exactly what was booked and what's inside it.

**Q: Can camt.054 replace the camt.053 statement?**

No. camt.054 carries no balances, so there is nothing to anchor a position or a completeness check against, and its coverage is a service definition, not the account's full activity — Nordea's implementation guides, for example, enumerate per country exactly which transaction types the notification includes. The statement remains the complete record you reconcile against; the notification is the detail channel that explains what individual items sit inside the statement's entries. Run both: camt.053 to prove, camt.054 to explain.

**Q: How do I reconcile a lump-sum credit on the statement using camt.054?**

Match the statement entry to the notification entry describing the same booking — amount, booking date and the bank's entry reference are the candidate keys — then run cash application against the TransactionDetails blocks inside the notification entry, each of which carries its own references and remittance information for one collected item. The notification entry's amount is defined as the total of its entry details, so detail-sum-equals-entry is the integrity check to run before clearing anything. And verify with your bank that its entry reference is stable across the two messages: the MIGs document each message separately and don't promise it.

---

# BAI2 File Format: Records, Type Codes and How to Read One

Source: https://gravam.com/blog/bai2-file-format-explained
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-03
Reviewed: 2026-08-03
Summary: Every BAI2 record explained: the 01–99 hierarchy, balance codes 010/015/040/045, credit vs debit type-code ranges, the funds-type field and control totals.

**A BAI2 file is a comma-delimited flat file of numbered records nested three envelopes deep: an 01 file header, one or more 02 group headers, an 03 account record carrying balances as three-digit type codes, 16 records for transaction detail, 88 continuations wherever a record runs long, and 49/98/99 trailers that close each envelope with a control total.** If you're choosing between statement formats, that's the [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2); if your file is tagged SWIFT text or XML, you want the [MT940 tag walkthrough](https://gravam.com/blog/mt940-format-tags-explained) or the [camt.053 field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields). This post is the third of the trio: for the day a `.bai` file from a US bank is in front of you and you need to know what each record and code holds — verified against the BAI specification itself and two banks' published implementation guides (HSBC's and SouthState Bank's), because as always the bank guide, not the standard, is the contract.

One naming point first, because the search results are a mess. "BAI2" is not a second file format that replaced a first one called BAI — it is Version 2 of BAI's _Cash Management Balance Reporting Specifications_, and the version-number field in every file header literally says `2`. The lineage since: BAI handed the copyright to Accredited Standards Committee X9 in 2008, ANSI approved the successor standard BTRS in 2012, and X9 versioned it straight to "BTR3" in 2016 precisely so the numbering would read as a continuation of BAI2. BTRS readers were designed to accept BAI2 files (with exceptions where codes were deleted or repurposed); a BAI2 reader cannot accept a BTRS file. In the field, the guides your banks publish still say BAI2, which is why this post does too.

## The shape of the file

The specification organizes data into three envelopes — **account** inside **group** inside **file**. A group holds accounts from one originator institution with one as-of-date; a file can hold many groups, which is how a concentration bank forwards other banks' data to you in a single transmission. That's a structural difference from MT940, where every message is one account's statement: a BAI2 importer must be written for the multi-account, multi-group, multi-originator case on day one.

The syntax is three rules:

- Fields are delimited by commas.
- A slash `/` ends a logical record (with a text-field exception we'll get to — it's the format's nastiest corner).
- Defaulted optional fields are shown by adjacent delimiters — `,,` mid-record, `,/` at the end.

Amounts have **no decimal point**. The currency code in force (from the 02 or 03 record) determines the implied decimals — two for most currencies, zero for some such as JPY — so `5525116638` in a USD account is $55,251,166.38. And amounts on detail and summary records are **always positive or unsigned**: direction lives in the type code, not in a sign. Only status (balance) amounts can carry a `-`.

A minimal real file, from SouthState Bank's guide:

```text
01,053200983,053200983,241210,1228,1,,,2/
02,,063114030,1,241209,,USD,2/
03,9999999999991,USD,015,69627820,0,,045,69627820,0,,100,0,0,,400,8949876,0,/
16,506,8949876,,,,TRANSFER TO COMMERCIAL ANALYSIS ACCOUNT 9999999999992/
49,157155392,3/
98,245520532,1,5/
99,245520532,1,7/
```

(Structure per SouthState's published sample, trimmed to its first account with the trailer record counts adjusted to match; the control totals are the bank's printed figures — checksums, not balances, as the trailer section below explains.)

## 01 and 02 — the headers

**01 File Header** — sender ID, receiver ID, file creation date (YYMMDD), file creation time in military format, a file identification number that must be unique per creation date, optional physical record length and block size, and the version number: `2`. Two field-level traps worth wiring in. Times run 0000–2400, and the spec itself warns that _some processors use 9999 to indicate end-of-day — be prepared to recognize it_. And the file ID is your duplicate-file detector: same sender, same date, same file ID means you've been sent the same file twice.

**02 Group Header** — optional ultimate receiver, the originator (US institutions are identified by ABA routing number, foreign ones by SWIFT BIC or another agreed identifier), a group status, the as-of-date, optional as-of-time, optional currency code (default USD — this is a US format to its bones), and an as-of-date modifier. The two enumerations:

| Field | Values |
| --- | --- |
| Group status | 1 = update, 2 = deletion, 3 = correction, 4 = test only |
| As-of-date modifier | 1 = interim previous-day, 2 = final previous-day, 3 = interim same-day, 4 = final same-day |

The modifier is how one format serves both jobs camt splits into camt.053 and [camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942): a previous-day BAI2 file (modifier 2) is your end-of-day statement, an interim same-day file (modifier 3) is your intraday feed. HSBC's implementation increments the file ID for each intraday transmission and resets it daily. And group status 3 — correction — means _replace previously sent data_; an importer that appends corrections instead of replacing them double-counts the day.

## 03 — the account record, where the balances live

The 03 record identifies the account and then carries the day's balance and summary figures as a repeating series of field groups: **type code, amount, item count, funds type** — again and again until the record (or its 88 continuations) runs out. The account number is alphanumeric, leading zeros significant. This is the record the whole cash position is built from, and here it is in HSBC's worked example:

```text
03,260093320000,USD,010,5525116638,,/
88,015,6105839257,,,040,5524958738,,,045,6105681357,,/
88,100,784117150,,,102,,18,/
88,400,203394531,,,402,,63,/
```

Read the first line with the repeating-group rule: account `260093320000`, currency USD, then type code 010 (opening ledger) with amount $55,251,166.38, item count and funds type defaulted. The continuations add 015 (closing ledger), 040/045 (opening/closing available), then the summaries — 100 total credits with 102 giving the count of credits (18), 400 total debits with 402 the count (63). Everything you need for a position and a completeness check, in four lines.

The rules attached to this record are exactly the ones parsers get wrong:

- **Status amounts may be signed negative; summary amounts may not.** An overdrawn opening ledger arrives as `010,-500000`.
- **Item count and funds type are for summary codes only** and must be defaulted (adjacent commas) after a status code.
- **Only one amount per status or summary code** may stand per account per as-of-date. Detail codes have no such limit.
- An 03 can also carry **no data at all** — `03,5765432,,,,,/` is legal, an account number serving only to anchor the 16 records that follow.

## The type-code system

Every figure in an 03 and every transaction in a 16 is classified by a three-digit **type code** from BAI's uniform list — and all three digits are significant, so a parser that strips leading zeros turns opening ledger (010) into nonsense. Codes come in three kinds: **status** (a balance at a point in time), **summary** (a total of activity, may carry an item count), and **detail** (one transaction). The ranges, from the specification:

| Range | Meaning |
| --- | --- |
| 001–099 | Account status (balances, float) |
| 100 | Total Credits summary |
| 101–399 | Credit summary and detail codes |
| 400 | Total Debits summary |
| 401–699 | Debit summary and detail codes |
| 700–799 | Loan summary and detail codes |
| 900–999 | Customized, bank-defined codes |

So **credit vs debit is a property of the code range** — the amount itself is unsigned. Two more special cases: code 890 is a non-monetary detail code whose text field carries free-form messages (`16,890,,,,,detail reports will be delayed until 11:00 AM.` is the spec's own example), and the 900 range is explicitly a free-for-all — BAI assigned nothing there, banks define their own, and HSBC's guide duly fills it with dozens of US- and UK-specific codes. If your parser meets a 9xx code, the answer is in that bank's guide and nowhere else.

The status codes you'll actually build a cash position from, per the specification's Appendix A:

| Code | Meaning | When you see it |
| --- | --- | --- |
| 010 | Opening Ledger | End-of-day and intraday |
| 015 | Closing Ledger | End-of-day |
| 030 | Current Ledger | Intraday |
| 040 | Opening Available | End-of-day and intraday |
| 045 | Closing Available | End-of-day |
| 060 | Current Available | Intraday |
| 063 | Total Float | Where the bank reports float |
| 072 | 1-Day Float | With 074 (2+ days) and 075 (3+ days) |

The end-of-day/intraday columns follow HSBC's implementation table: its previous-day files carry 010/015/040/045, its intraday files 010/030/040/060 — no closing balances, because the day isn't closed. Ledger vs available is the same booked-versus-usable distinction as MT940's :62F: against :64:, or camt.053's CLBD against CLAV, except BAI2 goes further and itemizes the float that separates them. And the code lists are genuinely bank-specific in the small print: SouthState labels 010/015 "Starting Balance" and "Ending Balance" — same codes, its own names — and reports a fixed subset of about thirty detail codes, while HSBC publishes hundreds, with per-country reinterpretations (115 is a lockbox deposit in the US and an India lockbox deposit in its India implementation). Print the code, then look it up in _that bank's_ guide.

When the transaction behind a detail record is a bounced ACH payment, the reason for the bounce comes from yet another list — Nacha's R01–R85 return codes, set out with the outbound file layout in [the NACHA ACH file format and return codes post](https://gravam.com/blog/nacha-ach-file-format-and-return-codes).

## 16 — the transaction detail record

One booked transaction per record, six fields: **type code, amount, funds type, bank reference number, customer reference number, text.** From SouthState's guide:

```text
16,475,119480,,910211979,35705,Check Paid/
```

Type code 475 is Check Paid — a 4xx code, so a debit — for $1,194.80; funds type defaulted; the bank's reference is 910211979; and the customer reference is 35705, which for code 475 is the check number. That last mapping is in the specification itself: for detail codes 474, 475 and 395, the customer reference number carries the check number. For payments you originated, the customer reference is where your own reference comes back — BAI2's version of the reconciliation round trip that MT940 runs through :61: subfield 7 and camt.053 through `EndToEndId`. HSBC populates `NONREF` when it has nothing, same convention as SWIFT.

The **text** field is the format's free-text tail — the counterparty names and descriptions that don't fit anywhere structured — and it comes with the file format's sharpest edge: text **must not begin with a slash but may contain slashes and commas after the first character**, and per the specification the end of a text field is marked not by a `/` but by _the beginning of the next record_. HSBC's guide states it flatly: the `/` is not used when the record ends in text. SouthState's examples, as printed above, _do_ end text with a slash. Both banks publish BAI2; a parser that hard-codes either convention breaks on the other. Split the file on line boundaries and record codes, treat everything after the fifth comma as text, and treat a trailing slash as content you may need to trim per bank.

## 88 — continuation, the record that isn't one

An 88 record continues the previous record — any type, including another 88 — in exactly the same format, picking up at the field where the previous physical line stopped. Three rules from the specification: a non-text field may never be split across records; a record about to be continued ends in `/` (not `,/`); and a text field _can_ split anywhere — HSBC's example wraps a counterparty name mid-word, `…POWER CONVERSION PRAVITE LIMITE` continued by `88,D`. So an 88 is not a data record at all: your parser's first pass should splice 88s onto their parents to rebuild logical records, and only then parse fields. Most real-world balance records arrive as an 03 plus two or three 88s — the HSBC example above is the normal case, not the exception.

## 49, 98, 99 — trailers and the arithmetic they hand you

Each envelope closes with a trailer, and each trailer carries a control total and a record count:

- **49 Account Trailer** — the algebraic sum of _every amount field_ in the preceding 03 and its 16/88 records, plus a count of records including the 03 and the 49 itself.
- **98 Group Trailer** — sum of the account control totals; number of accounts (03 records); number of records in the group.
- **99 File Trailer** — sum of the group control totals; number of groups; number of records in the file.

Note what the account control total is: balances _and_ transactions summed together — opening ledger plus closing ledger plus total credits plus each detail amount, one number. It is meaningless as money, and that's fine; it's a checksum, not a balance. Two things are excluded: amounts inside funds-type availability fields, and item counts. Recompute all three levels on import and reject the file on mismatch — this is BAI2's equivalent of the MT940 balance-chain check, and it catches truncation before the truncation becomes a wrong cash position. The balance continuity check (previous 015 equals today's 010) isn't a stated rule of the format the way :60a:/:62a: chaining is in MT940, but it's the same free detector, and I'd wire it in regardless.

## The funds-type field

The odd one out among the fields, because it's **composite** — one field that can expand into several, changing the record's field count. It reports availability of the amount it follows:

| Code | Meaning | What follows |
| --- | --- | --- |
| Z | Unknown (default) | Nothing |
| 0, 1, 2 | Whole amount available in 0 / 1 / 2+ days | Nothing |
| V | Value dated | Value date (YYMMDD), then optional value time |
| S | Distributed availability | Three amounts: immediate, one-day, two-or-more-days |
| D | Distributed availability | A count, then that many day/amount pairs |

So `16,115,10000000,S,5000000,4000000,1000000/` is a $100,000 lockbox deposit of which $50,000 is available now, $40,000 tomorrow and $10,000 in two or more days — and the record is suddenly three fields longer than the plain-vanilla case. `V` with a date is how [value-dated entries](https://gravam.com/blog/value-date-vs-booking-date-vs-entry-date) arrive (`…,V,040701,1300,…` in the spec's example). A fixed-position parser dies here; the funds-type code must drive how many fields you consume next. Availability amounts can be signed (float adjustments), are excluded from control totals, and — the spec is explicit — may not sum to the amount they describe. Whether the field is used at all is bank policy: SouthState doesn't populate it; HSBC uses `V` when value, posting and reporting dates differ.

## Reading one end to end

The reading algorithm that falls out of all this: split on record codes; splice 88s onto parents; walk 01 → 02 → 03 → 16s → 49, maintaining the envelope stack; apply implied decimals from the currency in scope; take direction from the type-code range, never from a sign; expand funds-type fields by their own code; verify all three trailer totals. When an [electronic bank statement run in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) imports a BAI2 file, the type code is the external transaction code its posting rules key on — the same job MT940's :61: transaction type and camt.053's Bank Transaction Code do — so the per-bank code list isn't trivia, it's the input to your posting-rule design.

## Common BAI2 parsing mistakes

- **Parsing amounts as signed decimals.** No decimal points (implied by currency), no signs on detail amounts. Direction is the type-code range: 100–399 credit, 400–699 debit.
- **Treating 88 as a record type.** It's a continuation. Splice first, parse second — and expect text to split mid-word.
- **Hard-coding the text terminator.** The spec ends text at the next record boundary; HSBC omits the trailing slash, SouthState prints one. Per-bank tolerance, not one rule.
- **Fixed field positions through funds type.** `S`, `D` and `V` change the field count. The composite must drive the cursor.
- **Skipping the trailer arithmetic.** Three levels of control totals are sitting there; recompute them or ship truncated files into your cash position.
- **Stripping leading zeros from type codes.** 010 is a code, 10 is not. Same for account numbers — leading zeros are significant.
- **Assuming one bank's code list.** The 900 range is bank-defined by design, and even uniform codes get bank-specific names and per-country meanings. One code map per bank, from that bank's guide.

Past the parser, the file feeds a matching step, and that step is the one worth redesigning. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) splits it into what stays deterministic (type code, amount, bank reference within tolerance), what an AI step can read (the 88-record text that never matched), and what stays with a named human (the write-off).

The format is older than almost everything that parses it, and its US home means most treasuries meet it only on the American accounts in an otherwise MT940/camt landscape — the [comparison post](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) covers when you'd choose it. But the engineering habit is the same one the whole statement trio teaches: the standard gives you the skeleton and the integrity checks for free, and every hard part — code lists, text conventions, which optional fields arrive — is written down in a per-bank guide that you should read before the first production file, not after.

***

_See also [bank statement formats: MT940 vs camt.053 vs BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), [the MT940 tag walkthrough](https://gravam.com/blog/mt940-format-tags-explained), [the camt.053 field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields), and [electronic bank statement processing in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms)._

## Primary sources

Record layouts, field rules, type-code ranges and the printed codes verified against BAI's Cash Management Balance Reporting Specifications v2 (2005 Technical Reference Manual) and the published BAI2 implementation guides of HSBC and SouthState Bank; the BAI1/BAI2/BTRS history against ASC X9's BTR3 format guide. Bank code lists diverge — your bank's guide is the contract.

- BAI — Cash Management Balance Reporting Specifications, Version 2 (Technical Reference Manual, 10/2005) — accessed 2026-08-03 — https://cdn.bai.org/migrated-from-www/docs/default-source/libraries/site-general-downloads/cash_management_2005.pdf
- HSBC — BAI2 Statement Message Implementation Guide, Version 1.5 — accessed 2026-08-03 — https://www.hsbcnet.com/-/media/hsbcnet/client-transition/bai2-ir-specs.pdf
- SouthState Bank — BAI-2 Format: Cash Management Balance Reporting Specifications User Guide (January 2025) — accessed 2026-08-03 — https://prd.ssbcdn.com/ssbweb/media/pdf/ssb-bai2-format-v3-jan-2025-rev.pdf
- ASC X9 — ANSI X9.121-201 (BTR3) Balance and Transaction Reporting Standard, Format Guide Version 3 (2016) — accessed 2026-08-03 — https://x9.org/wp-content/uploads/2013/10/ANSI-X9-121201-BTRS-Format-Guide-Version-3.pdf

## Questions this article answers

**Q: What are the record types in a BAI2 file?**

Eight, arranged as nested envelopes. An 01 file header opens the file and a 99 file trailer closes it with a control total. Inside, one or more groups each open with an 02 group header (one originator, one as-of-date) and close with a 98 group trailer. Inside a group, each account opens with an 03 account identifier record carrying the balance and summary data, is followed by zero or more 16 transaction detail records, and closes with a 49 account trailer. An 88 continuation record can follow any record type — including another 88 — and carries the overflow in the same format. Every trailer's control total and record count is checkable arithmetic, which is the format's built-in integrity test.

**Q: What do BAI2 type codes 010, 015, 040 and 045 mean?**

In BAI2, 010, 015, 040 and 045 are account status codes from BAI's uniform type-code list, reported on the 03 record (or its 88 continuations): 010 is the opening ledger balance, 015 the closing ledger, 040 the opening available and 045 the closing available. Ledger is what the books say; available is what the funds-availability rules let you use. Intraday files use different codes for the same idea — 030 current ledger and 060 current available; in HSBC's implementation, for example, an end-of-day file carries 010/015/040/045 while an intraday file carries 010/030/040/060 and omits the closing balances, because the day isn't closed yet. Status amounts may be signed negative, and each status code may appear only once per account per as-of-date.

**Q: How does a BAI2 file distinguish debits from credits?**

By the type code on each record, not by a sign — detail and summary amounts are always positive or unsigned. Codes 100–399 are the credit family (100 itself is the Total Credits summary) and 400–699 are the debit family (400 is Total Debits), with 700–799 reserved for loan reporting and 900–999 for codes each bank defines itself. So a 16 record with code 475 (Check Paid) is a debit and one with 142 (ACH Credit Received) is a credit, and the amount field looks identical on both. A parser that expects signed amounts, or that ignores the code and guesses direction some other way, will book half the statement backwards.

**Q: What is the difference between BAI and BAI2?**

Versions of the same specification. The Bank Administration Institute's Cash Management Balance Reporting Specifications went through a Version 1 (retroactively 'BAI1') and a Version 2 — and BAI2 is simply that second version, the one the industry standardized on; the version-number field every file header carries is 2. In 2008 BAI transferred the copyright to Accredited Standards Committee X9, and in 2012 ANSI approved the Balance and Transaction Reporting Standard (BTRS) as its successor — versioned straight to BTR3 in 2016 so the numbering would continue from BAI2. BTRS was built so a BAI2 file could be read by a BTRS reader (with exceptions for deleted or repurposed codes), but not the reverse, and in practice banks' guides still say BAI2.

---

# MT940 Format: The Tags, Line by Line

Source: https://gravam.com/blog/mt940-format-tags-explained
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-03
Updated: 2026-09-03
Reviewed: 2026-09-03
Summary: Every MT940 tag explained: :20:, :25:, :28C:, the :61: statement line subfield by subfield, the bank-specific :86:, and the :62a:/:64:/:65: balances.

**MT940 is the SWIFT Customer Statement Message — the tagged flat-file end-of-day statement — and the whole format is a short chain of tags: a message reference (:20:), the account (:25:), a statement number (:28C:), an opening balance (:60a:), one :61: statement line per booked entry with an optional :86: information block under it, and the closing balances (:62a:, :64:, :65:).** If you're choosing between statement formats, that's the [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2); if your file is XML, you want the [camt.053 field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields); if it's a US flat file, the [BAI2 record walkthrough](https://gravam.com/blog/bai2-file-format-explained); if it arrives during the day rather than after it, the [MT942 and camt.052 intraday pair](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942). This post is for the day an MT940 is in front of you and you need to know what each tag and subfield actually holds — verified against a bank's published implementation (Nordea's MT940 service description), because SWIFT's own specification sits behind the user handbook login.

And no, this isn't archaeology. The CBPR+ interbank coexistence period ended in November 2025, but the corporate-to-bank space runs on its own clock: SWIFT's SCORE participants can continue exchanging MTs like MT940 after the cutover, and, as of August 2026, migration is not yet mandatory for corporates — the [MT retirement timeline post](https://gravam.com/blog/mt101-vs-mt103-vs-mt202) untangles the different clocks. MT940s keep landing in import folders every morning, which is why the tag-level detail still earns its keep.

## The shape of the message

An MT940 is a SWIFT FIN message: blocks delimited by curly braces, with the statement data living in block 4 as a sequence of tags, each on its own line, each starting with a colon-wrapped tag number. The character set is deliberately narrow — SWIFT's `x` set: letters, digits, and a short list of punctuation (`/ - ? : ( ) . , ' +` plus space and line breaks). No accents, no symbols beyond that list. The standard itself permits lowercase; the shouting beneficiary names in statement archives come from the banks, most of which — the Nordea guide cited below included — emit uppercase only, so a parser should accept both cases and never depend on either.

The tag sequence:

```text
:20:   transaction reference number   mandatory   16x
:21:   related reference              optional    16x
:25:   account identification         mandatory   35x
:28C:  statement/sequence number      mandatory   5n[/5n]
:60a:  opening balance (F or M)       mandatory   1!a6!n3!a15d
:61:   statement line                 repeating, one per entry
:86:   information to account owner   optional, follows its :61:
:62a:  closing balance (F or M)       mandatory   1!a6!n3!a15d
:64:   closing available balance      optional    1!a6!n3!a15d
:65:   forward available balance      optional    1!a6!n3!a15d
```

The format notation is SWIFT's own shorthand, and you only need four readings of it here: `6!n` is exactly six digits, `16x` is up to sixteen characters, `15d` is a decimal amount whose decimal comma is mandatory, and `6*65x` (coming up in :86:) is up to six lines of 65 characters. Square brackets mean optional.

## :20:, :21:, :25:, :28C: — the header tags

**:20: Transaction Reference Number** (16x, mandatory) is the reference assigned by the sender to unambiguously identify the _message_ — not the statement, the message. One statement split across three messages has three different :20: values. Store it for support calls; don't key on it.

**:21: Related Reference** (16x, optional) — rarely interesting on a statement; present in the structure.

**:25: Account Identification** (35x, mandatory) is the account for which the statement is sent. The format is generous on purpose: banks put IBANs, domestic account numbers, sometimes BIC-prefixed constructions in here. Your importer's account-matching logic should treat it as an opaque string mapped per bank, not parse it.

**:28C: Statement Number/Sequence Number** (5n/5n, mandatory) is the sequential number of the statement, optionally followed by the sequence number of the message within that statement when one statement spans several messages: `28C:235/1`, then `28C:235/2`. Two operational facts from Nordea's description worth wiring into an importer. First, the statement number resets to 1 on 1 January each year — so a gap check must tolerate the year-end wrap, or it will page someone every New Year's morning. Second, when downloading files, the sequence numbers will not necessarily arrive sorted — reassemble on :28C:, never on arrival order. This is MT940's version of the gap check I recommend on camt.053's `ElctrncSeqNb`: a missed statement is a silently wrong cash position, and the statement number is the free detector.

## :60a: — opening balance

Format `1!a6!n3!a15d`, mandatory, and the little `a` in :60a: means the tag comes in two variants — :60F: (first opening balance) and :60M: (intermediate opening balance, for multi-message statements; more below). The subfields, in order:

| Subfield | Format | Content |
| --- | --- | --- |
| D/C mark | 1!a | D or C — which side the balance sits |
| Date | 6!n | YYMMDD |
| Currency | 3!a | ISO 4217 code |
| Amount | 15d | Decimal comma mandatory |

The rule that matters: **:60a: must always equal field :62a: of the previous customer statement message for this account.** That's the integrity check the format hands you for free — previous closing equals current opening, and opening plus the signed sum of :61: lines equals closing. When either fails you have a missing statement or a broken file, and you want the importer to say so before the cash position ships.

## :61: — the statement line, subfield by subfield

This is the tag the whole format exists for: one :61: per booked entry, everything packed into a single line with almost no delimiters. The format string, exactly as specified:

```text
6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x]
```

Nine subfields, in fixed order:

| # | Subfield | Format | What it holds |
| --- | --- | --- | --- |
| 1 | Value date | 6!n | YYMMDD — the date that drives position and interest |
| 2 | Entry date | 4!n | Booking date, MMDD — optional, and note: no year |
| 3 | Debit/credit mark | 2a | D, C, RC or RD (see below) |
| 4 | Funds code | 1!a | Optional third character of the currency code |
| 5 | Amount | 15d | Decimal comma mandatory |
| 6 | Transaction type ID code | 1!a3!c | S/N/F family plus three characters (see below) |
| 7 | Reference for account owner | 16x | The customer-side reference; NONREF when none is available |
| 8 | Account servicer's reference | //16x | The bank's own reference, after a double slash; may be omitted for bank-initiated transactions |
| 9 | Supplementary details | 34x | Free text; when subfield 7 is NONREF the bank should provide the best available alternative here |

Three of these deserve more than a table row.

**The debit/credit mark is two characters wide for a reason.** Besides D and C there are RC — reversal of credit, which books as a debit entry — and RD, reversal of debit, which books as a credit. A parser that only knows D and C will either reject reversal lines or, worse, book them on the wrong side. Reversals are rare enough to survive testing and common enough to corrupt a live position.

**Subfield 7 is the reconciliation handle.** For debit entries its purpose is to identify, to the account owner, the instruction that caused the debit — this is where the reference you supplied with your payment comes back to you, MT940's modest ancestor of the `EndToEndId` round trip in [pain.001 and camt.053](https://gravam.com/blog/camt-053-structure-and-fields). Sixteen characters, no structure, and NONREF when the bank has nothing — at which point subfield 9's supplementary details are the consolation prize.

**The transaction type identification code** (subfield 6) is the entry's classification, and it comes in three families:

- **S** + three digits: the SWIFT message type behind the entry, 100–999.
- **N** + three characters: a code from a standard list of several dozen three-letter codes (TRF, CHG, INT, DDT, STO, MSC and their kin) for entries arising from payment and transfer instructions.
- **F** + three characters: entries originated by the account servicing institution itself.

Nordea's description then adds its own codes on top for cash-pool bookings — CMZ (zero balancing), CMS (sweeping), CMT (topping) — which is worth pausing on: even the classification code, the most machine-readable thing in the file, grows bank-specific extensions. When an [electronic bank statement run in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) picks a posting rule for an MT940 line, this code is the external transaction code it keys on. It's doing the job camt.053's Bank Transaction Code does — with four characters instead of a curated three-level taxonomy, which is a fair summary of the two formats' relationship.

Here's a real line from Nordea's sweeping example, with the packing on display:

```text
:61:0509070908D494031,34NCMZTOP/SWEEPSVERIGE GBPAX DANMARK A/S
```

Read it with the table: [value date 050907, entry date 0908](https://gravam.com/blog/value-date-vs-booking-date-vs-entry-date), D for debit, amount 494031,34, transaction type NCMZ (a zero-balancing sweep), customer reference `TOP/SWEEPSVERIGE`, and the counterparty name riding in supplementary details. No delimiters between any of them — the only way to cut that line correctly is to apply the format definition left to right.

## :86: — information to account owner, and why it's bank-specific

Format `6*65x` — up to six lines of 65 characters — optional, attached to the :61: line it follows. And here is the sentence this post exists to say plainly: **the standard defines the size of :86:, not its structure.** What goes into those 390 characters, and in what layout, is decided bank by bank. Everything below is Nordea's implementation, shown as a worked example — not "the MT940 :86: format", because there is no such thing.

Nordea structures the field as `/Code/Information` pairs, with these codes:

| Code | Content (per Nordea's service description) |
| --- | --- |
| CHGS | Currency code and "OUR" charges |
| OCMT | Original currency and amount |
| EXCH | Exchange rate |
| ORDP | Ordering party |
| BENM | Beneficiary party |
| TRMT | Amount to beneficiary |
| RATE | Exchange rate |
| REMI | Remittance information |

For its sweeping services the first :86: line switches to a fixed layout instead — transaction code (CMZ, CMS or CMT), account number, customer reference, beneficiary or payer name:

```text
:86:CMZ/20496116759120/TOP/SWEEPSVERIGE/GBPAX DANMARK A/S
```

Two implementations inside one bank's :86:, and neither is portable. Another bank will use different codes, a different sub-structure, or plain prose. This is the concrete mechanism behind the [format comparison's](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) verdict that MT940's weakness is structure: the remittance information, counterparty names and FX details that camt.053 carries in typed XML elements live here in a free-text field whose layout is a per-bank convention. Every MT940 auto-matching rate I've seen quoted is really a statement about how well someone reverse-engineered each bank's :86: — so treat that parser as per-bank deliverable work, written from the bank's implementation guide and tested against production statements, never copied from the last project.

## :62a:, :64:, :65: — the closing balances

**:62a: Closing balance** — mandatory, same `1!a6!n3!a15d` structure as :60a:, same F/M split: :62F: is the final closing balance, :62M: an intermediate one. The chaining rule from the opening balance, stated from the other end: the content of this field will be repeated in field :60a: of the subsequent customer statement message for this account.

**:64: Closing available balance** — optional. The definition has more teeth than "available": funds which are available to the account owner if the balance is credit, _or the balance which is subject to interest charges_ if it is debit. Booked versus available is the difference between what the ledger says and what you can actually spend today — same distinction camt.053 makes with its CLBD/CLAV balance codes.

**:65: Forward available balance** — optional. Funds available to the account owner (credit or debit balance) for a specified forward value date — a small forward-looking window in an end-of-day format.

Both availability tags are optional, and whether a given bank sends them is an implementation fact, not a standard one. If your cash position needs available figures, confirm per bank before you design for them.

## Multi-message statements: how F and M chain

A busy account outgrows one message, and the format's answer is mechanical. The statement number stays fixed while the :28C: sequence number increments, and the balance variants mark the pieces:

- **First message:** opens :60F:, closes :62M:
- **Intermediate messages:** :60M: … :62M:
- **Final message:** :60M: … :62F: — the last message of the statement must contain :62F:

The statement and sequence numbers are what let the receiver put the messages back into sequence and form the complete statement — remembering the earlier warning that downloaded files won't necessarily arrive in sequence order. An importer that treats every message as a self-contained statement will double-count balances on the first busy day; key the reassembly on :28C: and only trust :62F: as the day's closing figure.

## Where MT940 parsers break in production

- **Treating :86: as standard.** It's bank-specific by construction. One parser per bank, written from that bank's guide, tested on that bank's production files.
- **Only handling D and C.** RC and RD exist, and each books on the opposite side of its name. Reversals in the debit/credit mark are the classic year-two production incident.
- **Skipping the balance chain check.** Previous :62a: must equal current :60a:, and :60a: plus the signed :61: lines must equal :62a:. Two comparisons, and they catch missing statements and truncated files before the position is wrong.
- **A gap check that forgets 1 January.** The statement number resets to 1 at the start of the year (in Nordea's implementation) — build the wrap into the check.
- **Parsing amounts with a decimal point.** The `15d` format's decimal comma is mandatory. `494031,34` is the format; a locale-naive `parseFloat` reads it as something else entirely.
- **Trusting arrival order.** Sequence numbers in downloaded files aren't necessarily sorted. Reassemble multi-message statements on :28C:.

Everything above ends up in a matching engine, and that engine is where a redesign earns its keep. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) takes a statement like this apart into what stays deterministic (`:61:` amounts, dates and references within tolerance), what an AI step can read (the bank-specific free text in `:86:`), and what stays with a named human (the write-off and the break nobody can explain).

The tags themselves have been stable for decades — that stability is exactly why MT940 still flows in the corporate-to-bank space while the interbank world has moved on. The craft, as with [camt.053](https://gravam.com/blog/camt-053-structure-and-fields), is never in the standard's skeleton; it's in the bank-specific corners — :86: layouts, code extensions, which optional tags actually arrive — and all of that is written down per bank. Get each bank's MT940 description, diff it against what your importer consumes, and the format holds few surprises after that.

***

_See also [bank statement formats: MT940 vs camt.053 vs BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), [the camt.053 field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields), [electronic bank statement processing in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms), and [MT101 vs MT103 vs MT202](https://gravam.com/blog/mt101-vs-mt103-vs-mt202)._

## Primary sources

Tag formats, subfields and codes verified against Nordea's published MT940 service description; SWIFT's own MT940 specification sits behind the user handbook and is not reproduced here. The :86: layout and several code sets are bank-specific — your bank's implementation guide is the contract.

- Nordea — Account Statement Service MT940 file description — accessed 2026-08-03 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- SWIFT — ISO 20022: Corporates (FAQ) — accessed 2026-08-03 — https://www.swift.com/standards/iso-20022/iso-20022-faqs/corporates

## Questions this article answers

**Q: What do the subfields in the MT940 :61: statement line mean?**

A :61: line packs up to nine subfields into one string, in fixed order: value date (six digits, YYMMDD), an optional entry date (four digits, MMDD, no year), the debit/credit mark (D, C, RC or RD), an optional funds code (the third character of the currency code), the amount (decimal comma, no thousands separators), the transaction type identification code (a letter S, N or F plus three characters), the reference for the account owner (up to 16 characters, or NONREF when the bank has none), then optionally the bank's own reference after a double slash, and up to 34 characters of supplementary details. Everything runs together with no separators except the // before the bank reference, so a parser has to work from the format definition, not from delimiters.

**Q: Is the MT940 :86: field standardized?**

Only its size: up to six lines of 65 characters of 'information to account owner', attached to the :61: line above it. How that space is structured is a bank-by-bank decision. Nordea, for example, populates it with /Code/Information pairs using codes like ORDP (ordering party), BENM (beneficiary party), OCMT (original currency and amount) and REMI (remittance information), and uses a different fixed layout for cash-pool sweeping entries. Another bank will structure it differently, or not at all. Any parser or reconciliation rule that reads :86: is bank-specific work, and each bank's implementation guide is the only reliable description of what will be in it.

**Q: What is the difference between :60F: and :60M: in MT940?**

The letter marks the message's place in a multi-part statement. When one statement is too long for a single message, it is split, and the balance tags chain the parts: the first message opens with :60F: (first opening balance) and closes with :62M: (intermediate closing balance), middle messages use :60M: and :62M:, and the final message uses :60M: and closes with :62F: (final closing balance). The :28C: statement and sequence numbers tell you which part you are holding. A single-message statement simply uses :60F: and :62F:.

**Q: What are fields :64: and :65: in an MT940?**

In an MT940, :64: and :65: are the available-balance tags, both optional and both in the same format as the booked balances. :64: is the closing available balance — per Nordea's service description, the funds available to the account owner if the balance is credit, or the balance subject to interest charges if it is debit. :65: is the forward available balance: the funds available to the account owner for a specified forward value date. Whether you receive them at all depends on the bank, so a cash position that needs available rather than booked figures has to be confirmed against each bank's implementation, not assumed from the standard.

---

# pain.002 Status and Reject Codes: Reading the Bank's Reply

Source: https://gravam.com/blog/pain-002-status-and-reject-codes
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-03
Reviewed: 2026-08-03
Summary: How to read a pain.002 status report: group, payment and transaction level, the ACTC/ACCP/ACSC status codes, and reject reasons like AC01, AC04 and AM04.

**A pain.002 answers your pain.001 at up to three levels — the whole file, each payment batch, each transaction — and every answer is a four-letter status code plus, when the status is RJCT, a reason code that tells you why.** The status codes and the reason codes come from two different lists, live at different depths of the message, and are the difference between "the bank said no" and knowing at 9:05 that one supplier IBAN is dead while the other 199 salaries are fine. This is the response-side companion to the [pain.001 field walkthrough](https://gravam.com/blog/pain-001-structure-and-fields): that post builds the instruction, this one decodes the reply. As there, I'll keep two sources open side by side — the official ISO 20022 External Code Sets, which own the code meanings, and a real bank's pain.002 implementation guide (Nordea's, again one of the few public ones), which shows how much of the standard a bank actually sends.

## Three levels of answer

The message is `CustomerPaymentStatusReport` — root element `<CstmrPmtStsRpt>`. Its shape mirrors the pain.001 it answers:

- **GroupHeader `<GrpHdr>`** — the bank's own envelope: its MsgId, its CreationDateTime. Nothing about your payments yet.
- **OriginalGroupInformationAndStatus `<OrgnlGrpInfAndSts>`** — the verdict on your _message_: `<OrgnlMsgId>` echoes the MsgId of your pain.001, `<OrgnlMsgNmId>` names the message type it's answering, and `<GrpSts>` carries the group status.
- **OriginalPaymentInformationAndStatus `<OrgnlPmtInfAndSts>`** — the verdict on each _batch_: `<OrgnlPmtInfId>` echoes your PmtInfId, `<PmtInfSts>` carries the payment-level status. Inside it, **TransactionInformationAndStatus `<TxInfAndSts>`** answers each _payment_: `<OrgnlInstrId>` and `<OrgnlEndToEndId>` echo your references, `<TxSts>` carries the transaction status, and `<StsRsnInf>` carries the reason.

This is the payoff of the identifier discipline from the pain.001 side: [MsgId, PmtInfId and EndToEndId](https://gravam.com/blog/payment-references-endtoendid-uetr) each come back at exactly one level of the pain.002 — Nordea's guide maps them index by index — so a status finds its payment without any matching heuristics. If your EndToEndIds are lazy, this is the message where you pay for it.

An illustrative skeleton — real tag names from Nordea's pain.002.001.03 guide, not a bank-ready file — answering the pain.001 from the sibling post, with one transaction bounced:

```xml
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
  <CstmrPmtStsRpt>
    <GrpHdr>
      <MsgId>BANK-STATUS-20260803-42</MsgId>
      <CreDtTm>2026-08-03T10:12:00Z</CreDtTm>
    </GrpHdr>
    <OrgnlGrpInfAndSts>
      <OrgnlMsgId>ACME-20260802-0001</OrgnlMsgId>
      <OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>
    </OrgnlGrpInfAndSts>
    <OrgnlPmtInfAndSts>
      <OrgnlPmtInfId>ACME-20260802-0001-01</OrgnlPmtInfId>
      <PmtInfSts>PART</PmtInfSts>
      <TxInfAndSts>
        <OrgnlInstrId>INV-4711-P2P</OrgnlInstrId>
        <OrgnlEndToEndId>INV-4711</OrgnlEndToEndId>
        <TxSts>RJCT</TxSts>
        <StsRsnInf>
          <Rsn><Cd>AC04</Cd></Rsn>
          <AddtlInf>ISO Account number specified has been closed</AddtlInf>
        </StsRsnInf>
      </TxInfAndSts>
    </OrgnlPmtInfAndSts>
  </CstmrPmtStsRpt>
</Document>
```

One rule saves a lot of confused parsing: **check the group level first**. Nordea's guide states it plainly — a group-level `RJCT` means the whole file is rejected and will not be processed, while a group-level `ACTC` means technical validation passed and content validation follows. If the file died at the gate, no payment- or transaction-level statuses are coming, ever, and your monitor shouldn't sit waiting for them.

## The status codes: a lifecycle, not a list

The official meanings live in ISO's External Code Sets — `ExternalPaymentGroupStatus1Code` for the group level (13 codes in the 1Q2026 edition) and `ExternalPaymentTransactionStatus1Code` for transactions (25 codes). In older message versions like the .03 that Nordea implements, the same codes sit as embedded schema enumerations (typed `TransactionGroupStatus3Code` and `TransactionIndividualStatus3Code` in its guide); the external list is where ISO maintains the definitions now. Read in order, the core codes are a pipeline:

| Code | Official meaning (condensed from the ISO external code sets) |
| --- | --- |
| **RCVD** | Payment initiation has been received by the receiving agent. |
| **ACTC** | Authentication and syntactical and semantical validation are successful. |
| **ACCP** | Preceding check of technical validation was successful; customer profile check was also successful. |
| **ACSP** | All preceding checks such as technical validation and customer profile were successful; accepted for execution. |
| **ACSC** | Settlement on the debtor's account has been completed (group set); settlement completed (transaction set). |
| **ACCC** | Settlement on the creditor's account has been completed. |
| **ACWC** | Instruction is accepted but a change will be made, such as date or remittance not sent. |
| **PART** | A number of transactions have been accepted, whereas another number have not yet achieved 'accepted' status. |
| **PDNG** | Payment instruction is pending; further checks and status update will be performed. |
| **RJCT** | Payment instruction has been rejected. |

The A-codes are stages, not synonyms: ACTC says the file _parsed_, ACCP says the bank also recognises _you_, ACSP says it's going to _execute_, and only ACSC/ACCC talk about _settlement_ — the ISO set even flags ACSC as usable only under bilateral agreement, because settlement confirmation is what your [statement](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) is for. A payment can die after any of them. Treat every A-status short of settlement as "so far, so good", not as "done".

Three codes deserve a closer look than their four letters suggest. **ACWC** means the bank changed something and processed anyway — date shifted past a cut-off, remittance dropped — and if you file it under "accepted" without reading the change, your books and the bank's diverge silently. **PART** at payment level is the one that should page someone: some transactions in the batch made it, some didn't, so a blanket retry re-pays the successful ones. **PDNG** means the story isn't over; another pain.002 follows.

The transaction set has a longer tail — ACFC (funds check passed), ACWP (accepted without posting to the creditor's account yet), BLCK (a previously-ACWP payment is now blocked in both directions), PATC (multi-authorisation flows where some approvals are still outstanding), CANC (cancelled — the set marks it for API contexts), even CPUC for cash physically picked up. The newest additions are the RCVC/RVCM/RVNC family for Verification of Payee outcomes — the code list is a living document, and the quarterly external-set publication is where it lives. You will not meet most of these; Nordea's guide, for instance, sends exactly two codes at group level (ACTC, RJCT) and five at payment level (ACCP, ACWC, PART, PDNG, RJCT). Same pattern as on the pain.001 side: **the standard defines the vocabulary, the MIG tells you which words the bank actually speaks.**

## When it's RJCT: the reason codes

RJCT alone tells you nothing actionable. The _why_ sits in `<StsRsnInf>` — a `<Rsn><Cd>` holding a code from **`ExternalStatusReason1Code`**, plus optional `<AddtlInf>` free text. This is the list behind every "sepa reject reason code" search: 302 codes in the 1Q2026 edition, of which a corporate treasury meets perhaps twenty-five. What follows is that curated subset with the official meanings, condensed from the ISO external code sets — for anything rarer, go to [the official list](https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets) rather than a forum thread.

**Account codes — the wrong-IBAN family:**

| Code | Official meaning |
| --- | --- |
| **AC01** | Account number is invalid or missing. |
| **AC02** | Debtor account number invalid or missing. |
| **AC03** | Creditor account number invalid or missing. |
| **AC04** | Account number specified has been closed on the bank of account's books. |
| **AC06** | Account specified is blocked, prohibiting posting of transactions against it. |

AC01 vs AC04 is the distinction worth automating: AC01 is bad master data you can fix today; AC04 means the account existed and is gone — you need a new IBAN from the beneficiary, and retrying is pointless.

**Funds and amount codes:**

| Code | Official meaning |
| --- | --- |
| **AM01** | Specified message amount is equal to zero. |
| **AM02** | Specific transaction/message amount is greater than allowed maximum. |
| **AM04** | Amount of funds available to cover specified message amount is insufficient. |
| **AM05** | Duplication. |

AM04 is the insufficient-funds code — on the initiation side that's _your_ account short, which makes it a [cash positioning](https://gravam.com/blog/how-to-build-a-daily-cash-position) failure wearing a format costume. AM02 usually means you tripped a limit in the bank agreement, not the scheme.

**Routing and agent codes:**

| Code | Official meaning |
| --- | --- |
| **RC01** | Bank identifier code specified in the message has an incorrect format. |
| **RC02** | Bank identifier is invalid or missing. |
| **AGNT** | Agent in the payment workflow is incorrect. |
| **CNOR** | Creditor bank is not registered under this BIC in the CSM. |
| **DNOR** | Debtor bank is not registered under this BIC in the CSM. |

**File, date and timing codes — the ones test phases are made of:**

| Code | Official meaning |
| --- | --- |
| **FF01** | File format incomplete or invalid. |
| **DT01** | Invalid date (e.g. wrong or missing settlement date). |
| **DT02** | Invalid creation date and time in Group Header (e.g. historic date). |
| **CH03** | Value in Requested Execution Date is too far in the future. |
| **CH04** | Value in Requested Execution Date is too far in the past. |
| **TM01** | Message, payment information block or transaction received after agreed processing cut-off time. |
| **DUPL** | Payment or charge is a duplicate of another payment or charge. |
| **RF01** | Transaction reference is not unique within the message. |

If the [pain.001 walkthrough](https://gravam.com/blog/pain-001-structure-and-fields) is the instruction manual, this table is its error page: the stale CreationDateTime, the reused MsgId, the execution date outside the window — each has its own code, and each is fixable on your side without calling anyone.

**Party and regulatory codes:**

| Code | Official meaning |
| --- | --- |
| **BE01** | Identification of end customer is not consistent with associated account number. |
| **BE04** | Specification of creditor's address, required for payment, is missing or not correct. |
| **MD07** | End customer is deceased. |
| **RR01** | Regulatory: debtor account or unique identification insufficient or missing. |
| **RR02** | Regulatory: debtor name and/or address insufficient or missing. |
| **RR03** | Regulatory: creditor name and/or address insufficient or missing. |
| **RR04** | Regulatory reason. |
| **AM07** | Amount specified in message has been blocked by regulatory authorities. |
| **CURR** | Currency of the payment is incorrect. |

BE04 and the RR-family are the structured-address era in code form: address data that used to be tolerated as missing is increasingly a hard reject.

**The catch-alls — where the code stops helping:**

| Code | Official meaning |
| --- | --- |
| **CUST** | Cancellation requested by the Debtor. |
| **MS02** | Reason has not been specified by end customer. |
| **MS03** | Reason has not been specified by agent. |
| **NARR** | Reason is provided as narrative information in the additional reason information. |

Two of these are traps. **CUST** gets glossed in the wild as "customer error" or "customer decision"; the official definition in the status-reason list is narrower — a cancellation the debtor asked for. And **MS03** is the bank formally declining to give you a coded reason — often because a sanctions or fraud screen is involved and the bank won't say so. When your reject feed is dominated by MS03 and NARR, the information you need is in `<AddtlInf>` or on the phone, not in the code — Nordea's guide, for instance, commits to filling AdditionalInformation for every non-ACCP status, prefixing it `ISO` when the text comes from the external code list and `CAP` when it's the bank's own commentary. And banks repurpose codes too, documented in plain sight: the same guide uses **MS02** with an ACWC status to signal a _changed creditor account_ in Finland — a meaning you would never derive from the official definition. When bank usage and the official list disagree, print the official meaning and read the MIG for the local dialect.

## A reject is not a return

One distinction keeps reconciliation honest: pain.002 RJCT happens **before** your money moves — validation or execution failed and nothing settled. When a payment settles and then comes back (beneficiary account closed at the far end, funds recalled), that's a **return**, and it reaches you through your statement and reporting flow, carrying reason codes from a _sibling_ list, `ExternalReturnReason1Code`. The two lists overlap heavily — AC04, AM04, MD07 appear in both with essentially the same meanings — but not perfectly, and the wording is set-specific: AC01 officially means "Account number is invalid or missing" as a status reason but "Format of the account number specified is not correct" as a return reason. Practical consequence: don't build one lookup table for "SEPA reject codes" and feed it both message families; key your code tables by code set, not by four letters — and if you also run US ACH, the [Nacha return codes](https://gravam.com/blog/nacha-ach-file-format-and-return-codes) are a third list again.

## Misreading pain.002 status codes

- **Treating pain.002 as optional.** The [overview post](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) makes this point strategically; here's the operational version: a payment run without status handling means your first reject notification is an angry supplier.
- **Waiting for transaction statuses after a group-level RJCT.** The file is dead; nothing below the group level will arrive. Check `<GrpSts>` first.
- **Mapping every A-status to "paid".** ACTC, ACCP and ACSP are checkpoints. Settlement is ACSC/ACCC at best, and your statement in practice.
- **Blanket-retrying a PART batch.** Some of those payments went through. Retry the RJCT transactions by EndToEndId, or pay people twice.
- **One reason-code table for rejects and returns.** Same letters, different code sets, set-specific wording. Key by set.
- **Ignoring `<AddtlInf>`.** For MS03 and NARR it's the only content you get; for bank-specific dialects (Nordea's `CAP`-prefixed lines) it's where the real explanation lives.

> Build your reject handling as triage buckets keyed on reason-code families, not individual codes: data errors you can fix and resend (AC01, RC01, DT01, CH03/CH04, RF01), funds problems for cash management (AM04), beneficiary problems needing outreach (AC04, AC06, MD07, BE04), and opaque rejects for a human queue (MS03, NARR, RR04). New codes then land in a bucket by prefix instead of in an unhandled-exception log.

Rejects and the statement lines they never became meet in reconciliation, and that is the step worth redesigning rather than staffing up. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) splits it into what stays deterministic (the reason code, the amount, the reference), what an AI step can read (the free-text `<AddtlInf>` a bank puts beside a code), and what stays with a named human (the decision to repair, re-route or write off).

The reply side of the payment conversation is smaller than the instruction side — three levels, one status vocabulary, one reason-code list — but it's the half that runs at 2 a.m. when nobody's watching. Wire the codes to actions once, against the official list, and a bounced payment becomes a work item instead of an investigation.

***

_See also the [pain.001 field walkthrough](https://gravam.com/blog/pain-001-structure-and-fields), the [pain.008 direct debit walkthrough](https://gravam.com/blog/pain-008-direct-debit-initiation), the [ISO 20022 message catalogue](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and the [camt.053 statement walkthrough](https://gravam.com/blog/camt-053-structure-and-fields)._

## Primary sources

Status and reason code usage is version- and bank-specific: the official code meanings below come from the ISO 20022 External Code Sets (1Q2026 edition, which lists 302 status reason codes), and the bank behaviour follows a pain.002.001.03 implementation guide (Nordea, CGI aligned), while the ISO catalogue is at CustomerPaymentStatusReportV15. Verify which statuses and reasons your banks actually send against their own MIGs.

- ISO 20022 — External Code Sets (1Q2026) — accessed 2026-08-03 — https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets
- Nordea — Message Implementation Guidelines, pain.002.001.03 (Corporate Access Payables, MIG v1.6) — accessed 2026-08-03 — https://www.nordea.com/en/doc/mig-cap-pain002-001-03-status-v1-6.pdf
- ISO 20022 — Message definitions catalogue (Payments Initiation) — accessed 2026-08-03 — https://www.iso20022.org/iso-20022-message-definitions

## Questions this article answers

**Q: What is the difference between ACTC, ACCP and ACSP in pain.002?**

ACTC, ACCP and ACSP are successive acceptance stages, each defined in the ISO 20022 external status code sets. ACTC means authentication and syntactical and semantical validation succeeded — the file parsed and passed schema-level checks. ACCP adds that the customer profile check also passed — the bank recognises the account and agreement behind the payment. ACSP means all preceding checks succeeded and the instruction has been accepted for execution. A payment can die after any of them, so none of the three means 'paid' — for settlement you're waiting for ACSC or ACCC, or in practice for the account statement.

**Q: What does reject reason code AC01 mean?**

In the ISO 20022 ExternalStatusReason1Code list — the code set pain.002 reason codes come from — AC01 officially means 'Account number is invalid or missing'. In practice it's the classic wrong-IBAN reject: the account number failed validation. One subtlety: the sibling return-reason code set defines AC01 as 'Format of the account number specified is not correct', so the same four letters carry set-specific wording depending on whether you're reading a reject or a return. Related codes: AC02 and AC03 pin the invalid account to the debtor or creditor side, and AC04 means the account has been closed.

**Q: Can a pain.002 reject a whole file?**

Yes. A pain.002 can answer at group level via GroupStatus in OriginalGroupInformationAndStatus, and a group-level RJCT kills the entire original message. Nordea's pain.002 implementation guide is explicit: when it sends RJCT as the group status, the whole file is rejected and will not be processed, whereas ACTC at group level means technical validation passed and content validation continues in the back end. That's why status handling has to check the group level first — if the file died there, no payment or transaction level statuses are coming.

**Q: What do MS03 and NARR mean in a payment rejection?**

MS03 and NARR both come from the ISO external status reason code list and both are catch-alls. MS03 officially means 'Reason has not been specified by agent' — the bank rejected the payment and is not telling you why in coded form; its sibling MS02 is the same with the end customer as the silent party. NARR means the reason is provided as narrative information in the additional reason information — free text instead of a code, so your automation has to surface the AdditionalInformation element to a human. If your rejects are dominated by MS03 and NARR, the useful detail is usually in AdditionalInformation or in a phone call, not in the code.

---

# camt.053 Structure: Reading the Statement Field by Field

Source: https://gravam.com/blog/camt-053-structure-and-fields
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-02
Reviewed: 2026-08-02
Summary: The camt.053 statement field by field: GroupHeader to TransactionDetails, OPBD/CLBD balance codes, the Bank Transaction Code, and where bank files diverge.

**camt.053 is the ISO 20022 BankToCustomerStatement — the end-of-day statement the account-servicing bank sends the account owner — and structurally it is one GroupHeader plus one or more Statement blocks, each carrying the account, a set of typed Balances, and the booked Entries, with the transaction detail nested two levels further down.** If you're deciding between statement formats, that's the [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2); this post is for the day you've already received a camt.053 and have to make reconciliation work against it. Field by field, with the multiplicities that bite, verified against a real bank implementation guideline (Nordea's camt.053.001.02 MIG) and ISO's own code lists.

## The skeleton

The message root is `<BkToCstmrStmt>`. Inside it, exactly one `<GrpHdr>` (GroupHeader) and one or more `<Stmt>` (Statement) blocks — `[1..n]`, and that multiplicity is the first practical fact: **one file can carry statements for many accounts.** An importer that assumes one account per file works until the bank consolidates delivery, then silently drops accounts.

Here's the shape, as an illustrative skeleton built from the elements in Nordea's MIG (not a complete or valid instance):

```xml
<BkToCstmrStmt>
  <GrpHdr>
    <MsgId>…</MsgId>          <!-- bank's unique message reference -->
    <CreDtTm>…</CreDtTm>
  </GrpHdr>
  <Stmt>                      <!-- [1..n] one per account statement -->
    <Id>…</Id>
    <ElctrncSeqNb>…</ElctrncSeqNb>
    <Acct>
      <Id><IBAN>…</IBAN></Id> <!-- or <Othr> for non-IBAN accounts -->
    </Acct>
    <Bal>…</Bal>              <!-- [1..n] typed balances -->
    <Ntry>                    <!-- [0..n] booked entries -->
      <NtryDtls>              <!-- [0..n] -->
        <TxDtls>…</TxDtls>    <!-- [0..n] underlying transactions -->
      </NtryDtls>
    </Ntry>
  </Stmt>
</BkToCstmrStmt>
```

The GroupHeader is thin on purpose: a `<MsgId>` the bank generates uniquely, a creation timestamp, optionally a message recipient. Everything that matters lives per statement. Within `<Stmt>`, the `<ElctrncSeqNb>` (electronic sequence number) increments with each statement sent — which gives you a free gap check: if today's number isn't yesterday's plus one, you missed a statement, and a missed statement is a silently wrong cash position. The `<Acct>` block identifies the account as an IBAN or, through the `<Othr>` branch, a domestic account number, plus currency and servicer BIC.

One more structural observation worth a sentence: the ISO type names are version-suffixed — in camt.053.001.02 the statement is an `AccountStatement2`, an entry is a `ReportEntry2`, a balance a `CashBalance3`. Those numbers climb with each message version, which is the concrete reason camt versions are not drop-in compatible: the types themselves change shape.

## Balances: typed, repeating, and bank-dependent

`<Bal>` is `[1..n]` — a statement carries a _list_ of balances, each one typed by a code under `<Tp><CdOrPrtry><Cd>`. The ISO external code set defines ten balance types:

| Code | Meaning (per the ISO external code set) |
| --- | --- |
| OPBD | Opening booked — book balance at the start of the reporting period; always equals the previous closing booked balance |
| CLBD | Closing booked — opening booked plus all entries booked in the period |
| OPAV | Opening available — what was at the owner's disposal at the start |
| CLAV | Closing available — what is at the owner's disposal at the end |
| ITBD | Interim booked — calculated during the business day, subject to change |
| ITAV | Interim available — the available equivalent, also intraday |
| FWAV | Forward available — funds at the owner's disposal on a specified future date |
| PRCD | Previously closed booked — the prior period's closing balance, restated |
| XPCD | Expected — booked entries plus known pending items, projecting the end-of-day balance |
| INFO | Informational only |

Each `<Bal>` then carries the amount (with a currency attribute), a `<CdtDbtInd>` of CRDT or DBIT — **the sign lives in a separate element, not in the amount** — and a date.

That's the textbook. The reality is that no bank sends you ten balances. Nordea's MIG allows exactly three: CLBD, OPBD, and CLAV "if reported by local system" — a phrase worth savoring, because it means even within one bank, whether you get an available balance depends on which country's back end produced the statement. The two checks I'd build into any importer regardless of bank: OPBD must equal the previous statement's CLBD (the code set's own definition says so), and OPBD plus the sum of signed entries must equal CLBD. When either fails, you have a missing statement or a broken file, and you want to know before the cash position goes out.

## The Entry: what the bank actually booked

Each `<Ntry>` (`[0..n]` — a no-movement day legally produces a statement with balances and no entries) is one booked movement, and its fields are the reconciliation workhorses:

- **`<Amt>` + `<CdtDbtInd>`** — the amount, always in the account currency in Nordea's implementation, and the credit/debit indicator. Same pattern as the balance: sign is separate.
- **`<Sts>`** — the entry status. Nordea sends only BOOK (booked). If a bank sends you other statuses in an end-of-day statement, filter deliberately: only booked entries belong in reconciliation.
- **`<BookgDt>` vs `<ValDt>`** — [booking date and value date](https://gravam.com/blog/value-date-vs-booking-date-vs-entry-date), both optional in the schema, both usually present. Position and interest care about value date; matching against the ledger cares about booking date. Pick per use, explicitly.
- **`<AcctSvcrRef>`** — the account servicer reference: the bank's own reference for the entry. When you call the bank about a statement line, this is the number their support desk can find. Store it verbatim.
- **`<NtryRef>`** — an entry reference, distinct from the above; optional.
- **`<BkTxCd>`** — mandatory, and important enough for its own section.

## BkTxCd: domain, family, subfamily

Every entry carries a Bank Transaction Code, structured as three levels:

```xml
<BkTxCd>
  <Domn>
    <Cd>PMNT</Cd>             <!-- domain: business area -->
    <Fmly>
      <Cd>RCDT</Cd>           <!-- family: received credit transfers -->
      <SubFmlyCd>ESCT</SubFmlyCd> <!-- subfamily: SEPA credit transfer -->
    </Fmly>
  </Domn>
</BkTxCd>
```

The domain is the business area — ISO's codification lists eleven: payments (PMNT), cash management (CAMT), foreign exchange (FORX), loans and deposits (LDAS), securities (SECU), derivatives (DERV), commodities (CMDT), precious metal (PMET), trade services (TRAD), account management (ACMT), and an extended domain (XTND). The family narrows within it — under PMNT you'll meet received credit transfers (RCDT), issued credit transfers (ICDT), the direct-debit pair (RDDT/IDDT), cheques, cards, counter transactions. The subfamily is the specific flavor: under PMNT/RCDT alone the list runs from ESCT (SEPA credit transfer) through DMCT (domestic credit transfer), XBCT (cross-border credit transfer), SALA (payroll), STDO (standing order) to BOOK (internal book transfer). ISO publishes the full set of permitted combinations as a spreadsheet — 1,567 rows in the 30 November 2025 codification.

Why care? Because **this is the field statement automation branches on.** When an [electronic bank statement run in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) decides which posting rule applies to a line, the external transaction code it keys on is, for a camt statement, this code. A clean BkTxCd means the entry can be interpreted without parsing text; that's most of camt.053's advantage over MT940 in practice.

Now the reality, in three parts. First, the code list includes its own escape hatches: OTHR ("other") and NTAV ("not available") exist as families _and_ subfamilies, and an entry classified PMNT/OTHR/OTHR has told you almost nothing — the classification quality you actually receive is a property of the bank's back end, not of the standard. Second, the `<Domn>` block is `[0..1]` in the schema — a structurally valid entry can arrive without the ISO code at all (the structure has room for proprietary codes instead; Nordea's MIG commits to ISO codes only, which is exactly the kind of commitment you want to see in writing). Third, two banks can classify the same economic event under different combinations. The audit step I'd never skip on a statement-onboarding project: pull a month of real statements and histogram the BkTxCd combinations per bank _before_ writing posting rules. The distribution is never what the standard suggests.

## Entry vs EntryDetails vs TransactionDetails: the batch problem

This nesting is the part of camt.053 that most reconciliation implementations get wrong first. Three levels:

- **`<Ntry>`** — what the bank booked. One amount, one line on the account.
- **`<NtryDtls>`** — `[0..n]` detail containers inside the entry.
- **`<TxDtls>`** — `[0..n]` transaction detail blocks inside each container, each with its own references (`<Refs>`), amount details (`<AmtDtls>`), related parties (`<RltdPties>`), and remittance information (`<RmtInf>`).

For a single payment booked individually, the levels collapse: one entry, one details block, one transaction, and Nordea's MIG notes the transaction amount is "same amount as on Entry level". Boring, correct, easy.

The interesting case is **batch booking**: the bank books one collective entry — say, one debit for an entire pain.001 payment run, or one credit for a bundle of incoming ACH items — and the individual payments exist only as multiple `<TxDtls>` blocks under that single entry (or arrive itemised in a separate [camt.054 notification](https://gravam.com/blog/camt-054-notification-explained)). Now the entry amount is a sum, the entry's references are batch-level, and everything you need to clear individual open items lives at transaction level. Reconciliation logic written against `<Ntry>` alone will match the happy single-payment path and fall over on the first collective booking, which in most companies is the _main_ path for payables.

Nordea's identification table makes the dependency explicit: the customer's own reference (`<InstrId>`) appears "when single booking applies", while the payment-order reference (`<PmtInfId>`) "may only appear when batch booking applies". Which references you receive, and at which level, is a function of the booking arrangement you agreed with the bank — it's negotiated, not discovered.

## References: which one comes back to you

A camt.053 carries a small zoo of references, and knowing who generated each is the whole game:

| Reference | Level | Who created it |
| --- | --- | --- |
| `<MsgId>` | GroupHeader | The bank — unique per message |
| `<AcctSvcrRef>` | Entry | The bank — its own reference for the booking |
| `<PmtInfId>` | TransactionDetails | You — the payment-information (debit batch) level of your instruction; batch booking |
| `<InstrId>` | TransactionDetails | You — your instruction reference; single booking |
| `<EndToEndId>` | TransactionDetails | You — set in [pain.001](https://gravam.com/blog/pain-001-structure-and-fields), carried through the chain |

`<EndToEndId>` deserves the emphasis. It's the reference you assigned per payment in the pain.001, and its return on the statement is what closes the loop: instruction out, statement in, matched by a key _you_ control. That's the cleanest auto-reconciliation mechanism the format offers — and it's `[0..1]` in the schema, so whether it actually survives the round trip through a given bank and clearing channel is a test case, not an assumption. Alongside the references, `<TxDtls>` carries the related parties (debtor and creditor accounts, ultimate parties) and unstructured remittance lines (`<Ustrd>`, up to 140 characters each, repeating). One detail from Nordea's MIG that belongs in a divergence museum: `<UltmtDbtr>` is in the schema with the comment "currently not supported by any countries." The element exists; the data doesn't.

## Where bank implementations diverge

Everything above sharpens into one working rule: **the ISO schema tells you what _can_ appear; the bank's MIG tells you what _will_.** The divergence shows up in predictable places:

- **Balance subset.** Ten types in the code set; two or three in a given bank's file, with availability balances often conditional on the local back end.
- **Reference population.** Which of InstrId / PmtInfId / EndToEndId you get, and at which level, depends on booking arrangements and the local clearing.
- **BkTxCd quality.** ISO combinations vs proprietary codes vs OTHR/NTAV — per bank, sometimes per country within one bank.
- **Optional elements that stay empty.** Schema-present, never populated (see UltmtDbtr above).
- **Version spread.** The ISO catalogue is at camt.053.001.14; camt.053.001.02 — defined in the 2009 payments maintenance cycle — is still widely delivered, with MIGs for it maintained as recently as 2023. Two banks on "camt.053" may be on different message versions with differently-shaped types.

This is the same conclusion the [format comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) reaches from one level up — camt.053 from Bank A and Bank B are not identical — but at field level you can see _why_, and plan for it: collect each bank's MIG, diff it against the elements your importer and matching logic actually consume, and test with production statements per bank before go-live. On the SAP side, where the imported statement lands in the FEBKO/FEBEP tables, the [treasury tables reference](https://gravam.com/blog/sap-treasury-tables) covers what the import writes and where to look when a line misbehaves.

## Where camt.053 reconciliation breaks

- **Reconciling at entry level.** Works for single bookings, breaks on the first batch. Write matching against TxDtls, and treat the entry as the sum it is.
- **Assuming one account per file.** `<Stmt>` is `[1..n]`. Loop.
- **Ignoring the sequence number.** ElctrncSeqNb gaps are missed statements — and missed statements are invisible until the position is wrong.
- **Trusting EndToEndId without testing it.** Optional in the schema; verify each bank returns it before your match rules depend on it.
- **Writing posting rules from the standard instead of the data.** Histogram real BkTxCd values per bank first; the standard's 1,567 combinations are the menu, not the meal.

The matching that consumes all of this is where a redesign pays for itself. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) takes the same statement apart into what stays deterministic (amounts, dates, references, tolerances — everything above), what an AI step can read (the free-text residue in `<AddtlNtryInf>` and `<RmtInf>`), and what stays with a named human (the write-off and the unresolved break).

The structure itself is genuinely good — typed balances, a mandatory classification code, references at the level they belong. The craft is in the gap between the schema and each bank's file, and that gap is documented: it's called the MIG, and reading it is the cheapest reconciliation improvement you'll ever make.

***

_See also [bank statement formats: MT940 vs camt.053 vs BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), [electronic bank statement processing in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms), and [the ISO 20022 migration from MT to MX](https://gravam.com/blog/iso-20022-migration-mt-to-mx)._

## Primary sources

Element names, XML tags and multiplicities verified against a camt.053.001.02 implementation guideline; the ISO catalogue is at BankToCustomerStatementV14. Later versions rename types and restructure some blocks — verify against your bank's MIG and version.

- Nordea — Corporate eGateway MIG camt.053.001.02 BankToCustomerStatementV02 (v1.9, 2023) — accessed 2026-08-02 — https://www.nordea.com/en/doc/nordea-mig-camt-053-001-02-bank-to-customer-statement.pdf
- ISO 20022 — External Code Sets (ExternalBalanceType1Code and BTC code sets) — accessed 2026-08-02 — https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets
- ISO 20022 — Bank Transaction Code combinations (codification, 30 Nov 2025) — accessed 2026-08-02 — https://www.iso20022.org/sites/default/files/media/file/BTC_Codification_30Nov2025.xlsx
- ISO 20022 — Message definitions catalogue (camt.053 BankToCustomerStatement) — accessed 2026-08-02 — https://www.iso20022.org/iso-20022-message-definitions

## Questions this article answers

**Q: What is the difference between Entry, EntryDetails and TransactionDetails in camt.053?**

An Entry (Ntry) is one booked movement on the account — one line the bank actually posted, with its own amount, status, dates and Bank Transaction Code. EntryDetails (NtryDtls) sits inside an entry and holds one or more TransactionDetails (TxDtls) blocks, each describing an underlying transaction with its references, parties and remittance information. For a single payment there is one of each. For a batch — one collective debit covering many payments — there is one entry and many TransactionDetails, which is why reconciliation logic must be written against the detail level, not just the entry level.

**Q: What do the balance codes OPBD, CLBD and CLAV mean on a camt.053 statement?**

OPBD, CLBD and CLAV are ISO 20022 balance type codes. OPBD is the opening booked balance — the book balance at the start of the reporting period, which always equals the previous statement's closing book balance. CLBD is the closing booked balance — the opening booked balance plus everything booked during the period. CLAV is the closing available balance — what is actually at the account owner's disposal on that date, which can differ from the booked figure. The external code set defines ten balance types in total, but each bank sends only the subset its systems support, so check the bank's implementation guide rather than the standard.

**Q: What is the Bank Transaction Code (BkTxCd) in camt.053?**

BkTxCd is the mandatory classification on every statement entry, structured as domain, family and subfamily. The domain is the business area (PMNT for payments, FORX for foreign exchange, and nine others), the family narrows it (RCDT is received credit transfers), and the subfamily is specific (ESCT is a SEPA credit transfer). ISO publishes the permitted combinations as an external code list — about 1,500 of them. It's the field statement-driven automation keys on: posting rules and reconciliation logic branch on the code, so an entry classified OTHR or NTAV ('other', 'not available') is an entry your automation can't do much with.

**Q: Which version of camt.053 do banks actually send?**

Older than you'd expect. The ISO catalogue currently lists camt.053.001.14, but camt.053.001.02 — defined back in the 2009 payments maintenance cycle — is still what many bank channels deliver; Nordea's implementation guideline for it was still being maintained in 2023. Versions are not drop-in replacements: type names and structures change between them, so an importer built for one version needs checking against another. Ask each bank which version and which implementation guide applies to your channel, and treat that document as the contract.

---

# pain.001 Structure: The Fields That Actually Matter

Source: https://gravam.com/blog/pain-001-structure-and-fields
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-02
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Inside the pain.001 file: GroupHeader, PaymentInformation and the transaction level — which fields treasury maps, and where bank implementations differ.

**A pain.001 file has exactly three levels — a GroupHeader that identifies the message, one or more PaymentInformation blocks that carry the debit side, and inside each of those one or more credit transfer transactions that carry the credit side — and once that shape clicks, most of the mapping work becomes deciding which level each piece of your payment data belongs to.** This is the field-level companion to the [ISO 20022 message catalogue](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002): that post maps which messages exist and who sends them; this one opens the file. I've mapped this format against enough bank implementation guides to know that the ISO definition is the easy half — so alongside the standard structure I'll show where a real bank guide (Nordea's, one of the few you can actually read without an NDA) narrows, repurposes or rejects what the schema allows.

## The three levels

The message is `CustomerCreditTransferInitiation` — root element `<CstmrCdtTrfInitn>`. Nordea's implementation guide describes the shape exactly as the standard has it: one message per file, built from three blocks.

- **GroupHeader `<GrpHdr>`** — occurs once (`1..1`). Identifies the message as a whole: who sent it, when, how many transactions, checksum.
- **PaymentInformation `<PmtInf>`** — occurs one or more times (`1..n`). The **debit side**: which account pays, at which bank, on which date, by which method. Everything shared by a group of payments lives here.
- **CreditTransferTransactionInformation `<CdtTrfTxInf>`** — occurs one or more times (`1..n`) _inside each_ PaymentInformation. The **credit side**: who gets paid, how much, in what currency, with what reference and remittance detail.

The mental model that survives contact with real files: **the envelope, the debit, the credits**. One file can pay 3 invoices from your EUR account today and 200 salaries from your SEK account on Friday — that's one GroupHeader, two PaymentInformation blocks, 203 transactions. A message can even mix several debtors and accounts, one PmtInf each.

Here is an illustrative skeleton assembled from the elements in Nordea's pain.001.001.03 guide. It is **not a bank-ready file** — mandatory identifiers, agreement references and country rules are omitted — but every tag name is real:

```xml
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03">
  <CstmrCdtTrfInitn>
    <GrpHdr>
      <MsgId>ACME-20260802-0001</MsgId>
      <CreDtTm>2026-08-02T09:30:00+02:00</CreDtTm>
      <NbOfTxs>2</NbOfTxs>
      <CtrlSum>15000.00</CtrlSum>
      <InitgPty><Nm>ACME TREASURY</Nm></InitgPty>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>ACME-20260802-0001-01</PmtInfId>
      <PmtMtd>TRF</PmtMtd>
      <BtchBookg>true</BtchBookg>
      <ReqdExctnDt>2026-08-03</ReqdExctnDt>
      <Dbtr><Nm>ACME Oy</Nm></Dbtr>
      <DbtrAcct><Id><IBAN>FI0000000000000000</IBAN></Id></DbtrAcct>
      <DbtrAgt><FinInstnId><BIC>NDEAFIHH</BIC></FinInstnId></DbtrAgt>
      <ChrgBr>SLEV</ChrgBr>
      <CdtTrfTxInf>
        <PmtId>
          <InstrId>INV-4711-P2P</InstrId>
          <EndToEndId>INV-4711</EndToEndId>
        </PmtId>
        <Amt><InstdAmt Ccy="EUR">7500.00</InstdAmt></Amt>
        <CdtrAgt><FinInstnId><BIC>NDEADKKK</BIC></FinInstnId></CdtrAgt>
        <Cdtr><Nm>Supplier A/S</Nm></Cdtr>
        <CdtrAcct><Id><IBAN>DK0000000000000000</IBAN></Id></CdtrAcct>
        <RmtInf><Ustrd>Invoice 4711</Ustrd></RmtInf>
      </CdtTrfTxInf>
      <!-- more <CdtTrfTxInf> blocks -->
    </PmtInf>
    <!-- more <PmtInf> blocks -->
  </CstmrCdtTrfInitn>
</Document>
```

One detail worth noticing before any field: the **namespace is the version**. Nordea's guide is explicit that the `xmlns` value — `urn:iso:std:iso:20022:tech:xsd:pain.001.001.03` — is what identifies the pain.001 version of the message. If your file says one version and your mapping was built for another, nothing else on this page matters yet.

## GroupHeader: the fields banks validate first

Four elements do the work here, and they're the ones a status report will quote back at you.

- **`<MsgId>`** (MessageIdentification, `1..1`, max 35 characters) — your identifier for the whole message. Textbook: a unique reference. Reality: it's your **idempotency key**. Nordea requires it to be unique per customer for a minimum of 90 calendar days and uses it for duplicate control — send the same MsgId twice and the second file is treated as a duplicate, which is precisely the behaviour you want when a [host-to-host channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) retries an upload. Generate it from your payment run, not from a timestamp someone can regenerate.
- **`<CreDtTm>`** (CreationDateTime, `1..1`) — when the message was created, as an ISO date-time. Not free of validation either: Nordea accepts values back to current date minus 30 calendar days. A test file with last quarter's timestamp fails before anyone looks at a payment.
- **`<NbOfTxs>`** (NumberOfTransactions, `1..1`) and **`<CtrlSum>`** (ControlSum, `0..1`) — the transaction count and the hash total of the instructed amounts, irrespective of currency. The count is validated and the whole message is rejected if it's wrong; the control sum is optional, but if you send it, it's checked with the same consequence. Send it anyway. A rejected file at the gate is cheap; a half-imported one is not.
- **`<InitgPty>`** (InitiatingParty, `1..1`) — who initiated the message, which can be the debtor or a party acting on its behalf: this is where a shared-service centre or [payment factory](https://gravam.com/blog/what-is-a-payment-factory) sending on behalf of subsidiaries identifies itself. At Nordea it identifies the _signer_ of the message and comes back in the status report.

## PaymentInformation: the debit side

This level answers: from which account, at which bank, on what date, by what method — for every transaction grouped under it.

- **`<PmtInfId>`** (`1..1`, max 35) — the batch reference. Same 90-day uniqueness and duplicate control at Nordea as MsgId, and it's echoed in the pain.002 status report and — if you use the bank's reporting — on the account statement. That echo is what stitches a statement debit back to a payment run, so treat the naming scheme as reconciliation design, not as a filler field.
- **`<PmtMtd>`** (PaymentMethod, `1..1`) — `TRF` for credit transfer; Nordea also accepts `CHK` for cheque payments, with country-specific rules about when each is allowed. If you're wondering who still pays by cheque: the field exists because someone does.
- **`<BtchBookg>`** (BatchBooking, `0..1`) — `true` requests one batch booking for the transactions under this PmtInf; `false` requests single bookings. Omit it and the bank's default applies — at Nordea, batch booking for domestic payments, with the cross-border behaviour in a country appendix, and no batch booking at all for relayed Request for Transfer instructions. This single optional flag decides whether your statement shows one consolidated debit or two hundred lines, which is to say it decides how your [reconciliation](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) works. Agree it per bank, explicitly.
- **`<ReqdExctnDt>`** (RequestedExecutionDate, `1..1`) — the date the payment should be debited and processed, funds permitting. All transactions under one PmtInf share it — which is the main reason files get split into multiple PmtInf blocks in the first place.
- **`<Dbtr>` / `<DbtrAcct>` / `<DbtrAgt>`** — debtor, debtor account, debtor agent, all `1..1`. The trio looks trivial and is where the bank-specific rules cluster. Nordea requires the debtor's name but then _replaces it with the account holder name from its own records_ for payments it executes. The account is IBAN or a local format under `<Othr>` — except Finland, where only IBAN is allowed — and the account currency must be present. The debtor agent takes a BIC — except Sweden, where a clearing-system code is an alternative. Three fields, three asterisks, one bank.
- **`<ChrgBr>`** (ChargeBearer, `0..1`) — who pays the charges: `DEBT`, `SHAR` or `SLEV` in Nordea's guide (the schema also knows CRED; this guide doesn't offer it — an example of a MIG narrowing the standard). Two rules worth memorising: it belongs on either the payment level or the transaction level but not both, and within the EU/EEA only `SHAR` or `SLEV` are accepted — send `DEBT` on an intra-EU payment and it's a rejection, not a warning.

Same either-level-but-not-both logic applies to **`<PmtTpInf>`** (PaymentTypeInformation — service level, instruction priority, category purpose such as `SALA` for salaries, which at Nordea is payment-level only) and **`<UltmtDbtr>`** (UltimateDebtor — on-behalf-of payments; supplying it on both levels gets the file rejected). The pattern to internalise: anything at PaymentInformation level applies to every transaction beneath it, and banks police the redundancy.

## CreditTransferTransactionInformation: the credit side

One block per payment. The fields your accounts-payable data actually populates:

- **`<PmtId>`** with **`<InstrId>`** (`0..1`) and **`<EndToEndId>`** (`1..1`) — two references with different lifespans. InstructionIdentification is your _point-to-point_ reference to the bank. **EndToEndIdentification travels with the payment**: it comes back in the pain.002 status report, in [camt.054 debit notifications](https://gravam.com/blog/camt-054-notification-explained), and on statements — it's the single field that lets a status or a statement line find its way back to an invoice. Nordea requires it unique per customer for 90 calendar days and runs transaction-level duplicate control on it. The honest caveat, straight from the same guide: it is _not_ forwarded on every domestic or international rail, because some local clearings and SWIFT-era infrastructure can't carry it. Design your reconciliation to prefer it, not to depend on it existing everywhere.
- **`<Amt>`** (`1..1`) — one of two shapes: **`<InstdAmt Ccy="...">`**, the amount in the currency the beneficiary should receive, or **`<EqvtAmt>`** — amount plus **`<CcyOfTrf>`** — for "debit my account for the equivalent of X in transfer currency Y", which Nordea allows only for cross-currency payments. Negative amounts are rejected; decimal and digit limits vary by payment type and country. If you've never seen EquivalentAmount used, you haven't done a cross-currency payment run where the budget was fixed in the debit currency.
- **`<CdtrAgt>`** (`0..1` here — conditional, not blindly mandatory) — the beneficiary's bank, as a **`<BIC>`** or as a clearing-system code plus bank name: Nordea's list includes `USABA` (US routing number), `GBDSC` (UK sort code), `AUBSB`, `CNAPS` and others. And a rule that surprises people: for SEPA payments identified by IBAN, the creditor agent is _ignored_ — the IBAN already routes the payment.
- **`<Cdtr>` / `<CdtrAcct>`** — the beneficiary and their account. Name and country are required; cross-border payments need the town as well, and since the structured-address push you should assume address rules are tightening everywhere, not just here. The account is an **`<IBAN>`** — mandatory within the EU/EEA for cross-border and SEPA payments in Nordea's guide — or an `<Othr>` identification for local schemes, including proprietary codes like `BGNR` (Swedish bankgiro) and `OCR` (Denmark). If you thought pain.001 abolished local account formats, the schema disagrees.
- **`<RmtInf>`** (RemittanceInformation, `0..1`) — what the beneficiary sees, and the field with the widest gap between schema and reality. Structurally: **`<Ustrd>`** free text (each occurrence max 140 characters) or **`<Strd>`** with referred documents (`CINV` invoice / `CREN` credit note, with number and amount) or a **creditor reference** (`SCOR`, e.g. an ISO 11649 RF reference). The schema says `0..n` occurrences; Nordea's per-country reality says: Denmark up to 1,435 characters of free text, Norway 875, Sweden 140, international payments one occurrence of 140 — and if structured remittance is present, unstructured is dropped. Whatever your ERP exports, the rail decides what arrives. This is exactly the "richer data" that makes ISO 20022 worth adopting — [when you actually populate the structured elements](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) instead of pasting invoice lists into free text that gets truncated at the border.

## Where banks fight over the same schema

Everything above came from _one_ bank's implementation guide, and that's the point: **pain.001 is a schema, but a payable file is a schema plus a MIG**. Nordea's guide states openly that elements the service doesn't use are left out of the guide entirely, even when the ISO message definition and the CGI-MP implementation guide include them. Every bank does a version of this. The recurring fight zones, all visible in this walkthrough:

- **Identification style.** BIC vs clearing codes vs IBAN-only routing; which local account formats are allowed where.
- **Level discipline.** Charge bearer, payment type information and ultimate debtor accepted at payment level, transaction level, or either-but-not-both — with rejection as the penalty for both.
- **Defaults.** Batch booking, service levels and charge codes all have bank defaults that apply when you're silent, and they differ per bank and per country.
- **Field length and content.** Remittance limits per country; characters like `¤`, `-` and `/` that Nordea warns it will convert to spaces to avoid clearing rejections. Your reference format survives some rails and not others.
- **Regulatory add-ons.** `<RgltryRptg>` (RegulatoryReporting) is optional in the schema and mandatory at Nordea for international payments above 100,000 NOK from Norway or 150,000 SEK from Sweden. The schema can't tell you that; only the MIG can.

And it isn't only banks: schemes layer rules on top too. In SWIFT's CBPR+ Standards Release 2026, change request CR 3014 formalises a rule that the PaymentInformationIdentification must match the MessageIdentification in the GroupHeader for the interbank pain.001 relay — a constraint no schema validator would ever tell you about. CGI-MP exists precisely to shrink this variation in the corporate-to-bank space, and guides like Nordea's are written against it; it narrows the fight, it doesn't end it.

> Build your pain.001 mapping in two layers: a clean ISO 20022 layer that populates the structure correctly, and a thin per-bank layer that applies each MIG's restrictions — allowed codes, levels, lengths, defaults. When bank number four arrives, you change the thin layer, not the model.

## CGI-MP: the layer between the standard and your bank

**CGI-MP (Common Global Implementation – Market Practice) is the industry group that publishes common implementation guidelines for corporate-to-bank ISO 20022 messages, so that one pain.001 shape can work across many banks.** It sits in the middle of a four-layer stack, and knowing which layer a rule comes from tells you who can change it:

| Layer | Who publishes it | What it decides | Example from this walkthrough |
| --- | --- | --- | --- |
| ISO 20022 message definition | ISO 20022 Registration Authority | Elements, nesting, multiplicity, data types: what is _possible_ | `ChrgBr` is optional (`0..1`) at both payment and transaction level in the ISO definition (checked against V10) |
| CGI-MP guideline | CGI-MP market-practice group | A common usage of those elements for corporates and banks: what is _usual_ | Built on pain.001.001.03, the 2009 version Nordea's guide still implements |
| Scheme and market rules | Schemes, clearings, SWIFT (CBPR+) | What a rail or region accepts | `SHAR`/`SLEV` only within the EU/EEA; CBPR+ CR 3014 tying PmtInfId to MsgId in the relay |
| Bank MIG | Each bank | What that bank's service actually accepts and does: what is _payable_ | Nordea omitting unused elements, dropping `CRED`, requiring `RgltryRptg` above NOK/SEK thresholds, converting special characters |

So why do bank MIGs still differ when most claim CGI-MP alignment? Because a common guideline can only standardise what is common. Each bank's MIG also has to encode its own products and clearing reach, the country rules of every market it debits from, the defaults it applies when you are silent, and the message version its platform runs. A guideline aligned to .03 and a catalogue at V13 is a version gap no guideline can close. And whatever a guideline leaves open is, in practice, settled bank by bank in the MIG and the onboarding tests.

The useful question in bank onboarding is therefore not "do you support ISO 20022?" but "which CGI-MP guideline is your MIG aligned to, and where do you deviate from it?" A written deviation list is the cheapest artefact in a connectivity project, and it is exactly the content of the thin per-bank layer in the callout above.

## Versions, and the pain.002 echo

Two closing facts that save arguments. First, versions: Nordea's guide implements **pain.001.001.03**, the CustomerCreditTransferInitiationV03 defined in the 2009 payments maintenance that CGI-MP built its recommendations on — while the ISO 20022 catalogue is now at **pain.001.001.13** (CustomerCreditTransferInitiationV13), with older versions kept in the message archive and communities encouraged toward recent ones. In the corporate-to-bank world you will meet old versions for years; the namespace tells you which one you're holding, and your bank's MIG tells you which one to send. The interbank world moves on [its own clocks](https://gravam.com/blog/iso-20022-migration-mt-to-mx) — including the [MT101 relay's retirement into a pain.001 relay in November 2026](https://gravam.com/blog/mt101-vs-mt103-vs-mt202).

Second, [the identifiers](https://gravam.com/blog/payment-references-endtoendid-uetr) are the contract with pain.002. Nordea's reference table maps them one-to-one: MsgId, PmtInfId and EndToEndId each come back at the corresponding level of the status report, and PmtInfId and EndToEndId flow onward into camt.054 debit notifications. That's the field-level answer to "pain.001 vs pain.002": the same three references, outbound and inbound. Design them well in the pain.001 and the [status handling](https://gravam.com/blog/pain-002-status-and-reject-codes) builds itself; design them lazily and every rejection becomes a research project.

## Why banks reject a pain.001 file

- **Timestamps and counts treated as decoration.** CreationDateTime outside the accepted window, NbOfTxs off by one, a stale MsgId — all message-level rejections before a single payment is looked at.
- **Duplicated levels.** Charge bearer or ultimate debtor on both payment and transaction level; some banks reject the file for redundancy the schema happily allows.
- **Assuming EndToEndId always arrives.** It's the backbone reference, and some rails still drop it. Check per payment type, not per bank.
- **One mapping for all banks.** The schema is shared; the MIGs aren't. Budget a mapping-and-test cycle per bank, same as any [connectivity project](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics).
- **Remittance built for the schema, not the rail.** 999 structured occurrences validate beautifully and arrive as 140 truncated characters.

The structure is genuinely simple — envelope, debit, credits. The craft is in respecting what each bank's guide does to it.

It is also a useful reference point for anything that generates structured output: pain.001 works because the receiving system can reject a message that does not conform, field by field, before it does anything with it. That is the same property [an AI output contract](https://gravam.com/blog/ai-output-contracts-and-failure-handling) has to have — and the reason "the model usually returns valid JSON" is not an integration.

***

_See also the [ISO 20022 message catalogue](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), the [pain.008 direct debit walkthrough](https://gravam.com/blog/pain-008-direct-debit-initiation), the [ISO 20022 migration from MT to MX](https://gravam.com/blog/iso-20022-migration-mt-to-mx), and [MT101 vs MT103 vs MT202](https://gravam.com/blog/mt101-vs-mt103-vs-mt202)._

## Primary sources

pain.001 element usage is version- and bank-specific: the walkthrough follows a pain.001.001.03 bank implementation guide (Nordea, CGI-MP aligned), while the ISO catalogue is at CustomerCreditTransferInitiationV13 and scheme rulebooks add their own rules. Verify every field against your own banks' MIGs before build. The CGI-MP section was added and its claims checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- Nordea — Message Implementation Guidelines, pain.001.001.03 (Corporate Access Payables, MIG v2.4) — accessed 2026-08-02 — https://www.nordea.com/en/doc/nordea-message-implementation-guide-cap-pain.001.001.03.pdf
- ISO 20022 — Message definitions catalogue (Payments Initiation) — accessed 2026-08-02 — https://www.iso20022.org/iso-20022-message-definitions
- SWIFT — ISO 20022: Corporates (FAQ) — accessed 2026-08-02 — https://www.swift.com/standards/iso-20022/iso-20022-faqs/corporates
- SWIFT — ISO 20022 in bytes: Call to action for November 2026 — accessed 2026-08-02 — https://www.swift.com/standards/iso-20022/iso-20022-bytes/call-action-november-2026
- ISO 20022 — Message Definition Report Part 2, Payments Initiation, Maintenance 2019–2020 (pain.001.001.10 multiplicities) — copy distributed in the moov-io/iso20022 repository — accessed 2026-09-25 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/payments_initiation_11/ISO20022_MDRPart2_PaymentsInitiation_2019_2020_v1_1.pdf
- AFP — Global AFP Service Codes Committee Review (AFP code update made in collaboration with CGI-MP) — accessed 2026-09-25 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/global-afp-service-codes-committee-review

## Questions this article answers

**Q: What are the three levels of a pain.001 file?**

A pain.001 (CustomerCreditTransferInitiation) has three nested blocks. GroupHeader (GrpHdr) appears once and identifies the whole message: MsgId, CreationDateTime, NumberOfTransactions, ControlSum, InitiatingParty. PaymentInformation (PmtInf) repeats and carries the debit side: the debtor, debtor account and debtor agent, payment method, requested execution date. CreditTransferTransactionInformation (CdtTrfTxInf) repeats inside each PmtInf and carries the credit side: EndToEndId, amount, creditor, creditor account, creditor agent and remittance information.

**Q: What is EndToEndId used for in pain.001?**

EndToEndIdentification is the mandatory per-transaction reference the debtor assigns. It travels with the payment and comes back in the pain.002 status report and in debit notifications and statements, which is what lets you match a status or a statement line back to the exact payment you sent. Banks also use it for duplicate control — Nordea, for example, requires it to be unique per customer for at least 90 calendar days. One caveat from the same guide: some local clearings and legacy rails don't forward it all the way.

**Q: What is batch booking in pain.001?**

BatchBooking (BtchBookg) is an indicator on the PaymentInformation level that tells the bank how to book the debit side: true requests one batch booking covering the transactions grouped under that PmtInf, false requests a single booking per transaction. It changes what you reconcile on the bank statement — one consolidated debit versus one line per payment. If you omit it, the bank's default applies, and defaults differ by bank and payment type, so agree it explicitly.

**Q: Which version of pain.001 should I use?**

The one your bank's implementation guide specifies — the version is identified by the XML namespace, e.g. urn:iso:std:iso:20022:tech:xsd:pain.001.001.03. Many bank guides in the corporate-to-bank space are still written on pain.001.001.03, the version from the 2009 payments maintenance that CGI-MP built on, while the ISO 20022 catalogue has moved on to CustomerCreditTransferInitiationV13 and recommends recent versions. In practice corporates run whatever versions their banks accept, which usually means the older one.

---

# MT101 vs MT103 vs MT202: Which SWIFT Message Does What

Source: https://gravam.com/blog/mt101-vs-mt103-vs-mt202
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-08-02
Updated: 2026-09-25
Reviewed: 2026-09-26
Summary: MT101 is a corporate's payment instruction, MT103 a bank-to-bank customer transfer, MT202 an interbank transfer. How they differ and what replaced them.

**MT101 is a corporate's payment instruction to its bank, MT103 is a bank carrying a customer's payment to another bank, and MT202 is a bank moving its own funds — three SWIFT messages at three different points in the payment chain, which is exactly why people mix them up.** Since the SWIFT cross-border space [completed its ISO 20022 migration](https://gravam.com/blog/iso-20022-migration-mt-to-mx) in November 2025, two of the three survive mostly as names — pacs.008 and pacs.009 do the work now — while MT101 lives on in the corporate-to-bank space with a retirement clock of its own. The query is durable; the answer in 2026 is partly historical. Both halves are below.

## The one-line version

Ask two questions of any SWIFT payment message: **who is talking to whom**, and **whose money is it**. MT101: corporate to bank, the corporate's money. MT103: bank to bank, a customer's money. MT202: bank to bank, the banks' own money. Everything else in this post is detail on top of that.

> **Figure — MT101, MT103 and MT202 on the payment chain**
>
> A corporate sends an MT101 to a bank. That bank sends an MT103 to another bank and, separately, an MT202. The MT101 and the MT103 are marked as carrying a customer's money; the MT202 is marked as the banks' own.
>
> Who is talking to whom, and whose money is it — the two questions that separate the three.

## MT101 — the corporate's instruction

MT101 is the **Request for Transfer**. It's the odd one out: not an interbank settlement message but an _instruction_ — the ordering customer asking an account-servicing bank to debit the customer's own account there and pay someone. In the classic setup it travels by **relay**: you submit the MT101 to your main bank, which validates it and forwards it over the SWIFT network to the foreign bank that actually holds the account. Nordea's service description is a clean example of the pattern — customer file in, bank check, onward delivery via SWIFT, acknowledgement back.

That relay is what made MT101 the workhorse of remote-account control for a generation of treasuries: repatriating balances, sweeping funds to your own accounts at other banks, making local payments from an account you hold abroad — all through one [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) instead of one e-banking portal per bank. Functionally it's the ancestor of what [pain.001 does today](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002): same intent, flat tagged format instead of [structured XML](https://gravam.com/blog/pain-001-structure-and-fields).

## MT103 — the customer payment, bank to bank

MT103 is the **Single Customer Credit Transfer**: the interbank message that carries a customer payment — a named ordering customer paying a named beneficiary customer — between banks. This is the message people usually mean when they say "a SWIFT payment". In the **serial** method, one MT103 hops through the correspondent chain from the ordering bank to the beneficiary bank, information and funds travelling the same route.

Two things practitioners should hold onto. First, **corporates don't send MT103s**. Your file to the bank is a pain.001 (historically an MT101 or a proprietary format); the MT103 — today the pacs.008 — is what your bank creates from it for the interbank leg. Second, the MT103 is the artifact everyone asks for after the fact: when a beneficiary swears the money never arrived, the first request on the call is "send us the MT103 copy". That habit outlived the message — tracing is what [SWIFT gpi and the UETR](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments) were built for, and the reference travels on regardless of format.

## MT202 — banks moving their own money

MT202 is the **General Financial Institution Transfer**: both sender and receiver are banks, and the funds being moved are the institutions' own — interbank settlement, and the funding legs that sit behind customer payments. No ordering customer, no beneficiary customer; that's the point.

Its best-known variant exists because of that point. In the **cover** method, the MT103 goes straight to the beneficiary's bank as an announcement — funds are coming, for this beneficiary, via this correspondent — while a separate cover message actually moves the funds through the correspondent accounts. For years that cover leg was a plain MT202 carrying no detail about whose payment it funded, which meant intermediaries were screening a message that named no customers. **MT202 COV**, introduced in the November 2009 standards release, closed that gap: a cover message for an underlying customer credit transfer must carry the ordering and beneficiary customer details, matching the MT103 it covers, so sanctions and AML screening can see the parties at every hop.

## Side by side

|  | MT101 | MT103 | MT202 |
| --- | --- | --- | --- |
| **Full name** | Request for Transfer | Single Customer Credit Transfer | General Financial Institution Transfer |
| **Who talks** | Corporate → bank (relayed via a bank) | Bank → bank | Bank → bank |
| **Whose money** | The corporate's account at another bank | A customer's payment | The banks' own funds (incl. cover legs) |
| **Role** | Instruction | Customer payment, interbank leg | Settlement / funding |
| **ISO 20022 heir** | pain.001 | pacs.008 | pacs.009 (COV for cover) |
| **Cross-border now** | SCORE continues; relay retires Nov 2026 | Retired in CBPR+ (22 Nov 2025) | Retired in CBPR+ (22 Nov 2025) |

## What ISO 20022 did to each of them

The [CBPR+ coexistence period ended on 22 November 2025](https://gravam.com/blog/iso-20022-migration-mt-to-mx), and with it the MT 1xx, 2xx and 9xx categories stopped meeting CBPR+ requirements for cross-border payments and reporting over SWIFT. For the two interbank messages the succession is clean: **MT103 → pacs.008** (FIToFICustomerCreditTransfer), **MT202 → pacs.009** (FinancialInstitutionCreditTransfer), and **MT202 COV → pacs.009 COV** — same three-way distinction, richer structured data underneath. An MT103 or MT202 that a bank still sends interbank is converted by SWIFT's contingency processing, charged to the sender since January 2026, rather than carried as normal traffic.

MT101 is the interesting case, because it straddles the boundary. The corporate-to-bank leg is **not** part of the CBPR+ interbank cutover: SCORE users — corporates and their banks — can continue exchanging MTs like MT101, MT940 and MT942 after November 2025, and SWIFT says migration is not yet mandatory for corporates, just strongly encouraged. But the **interbank relay** — the bank-to-bank hop that made MT101 useful — has its own deadline: it retires in **November 2026** in favour of the **pain.001 relay**, with contingency processing, automatic conversion and extra fees for what's left. And individual banks are setting their own end dates for accepting MT101 at all. So "is MT101 dead?" has a precise answer: not yet, not everywhere, and the direction is pain.001 either way.

> One date does not fit all. 22 November 2025 was the CBPR+ cross-border cutover; the MT101 relay runs to November 2026; market infrastructures and domestic schemes move on their own calendars; and your banks each have their own MT101 sunset letters. When someone tells you "MT is switched off", ask which space they mean.

## Why the confusion persists

Textbook version: three cleanly separated messages, one page each in the standard. Reality: they all get called "the payment message", and the confusion shows up in real projects. I've sat in connectivity workshops where the bank's form asked which payment message we'd use and three people gave three answers — pain.001, MT101, MT103 — each describing the same flow from a different seat. All three were sort of right: the corporate sends the instruction, the bank builds the interbank leg, and the settlement may ride a message the corporate never sees.

The trap is treating them as interchangeable. Asking your bank for "the MT103" on an intercompany sweep that never generated one; expecting customer names inside a plain MT202; assuming the retirement of MT103 means your MT101 channel is dead too. The two questions from the top of the post — who is talking to whom, whose money is it — resolve almost every one of these in seconds.

## Where SWIFT message types get confused

- **Calling every SWIFT payment "an MT103."** If both parties are banks moving their own funds, it was never an MT103 — and after November 2025 the cross-border leg is a pacs message anyway.
- **Expecting customer detail in an MT202.** Only the COV variant carries the underlying parties; that was the entire reason it was created in 2009.
- **Reading "MT is retired" as one event.** The interbank cutover (2025), the MT101 relay (2026) and corporate-to-bank SCORE traffic are three different clocks. Planning on the wrong one either strands you early or strands you late.
- **Building new connectivity on MT101 in 2026.** It still works in SCORE, but the relay is closing and banks are sunsetting it individually. New pipes should be [pain.001](https://gravam.com/blog/pain-001-structure-and-fields) from day one.

Know which seat you're in — instructing, carrying, or settling — and the three messages stop being interchangeable jargon and become a map of the payment chain. That map survives the format change: the names on it just became pain.001, pacs.008 and pacs.009.

***

_See also the [ISO 20022 migration from MT to MX](https://gravam.com/blog/iso-20022-migration-mt-to-mx), [pain.001 and pain.002 explained](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and [bank statement formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2)._

## Primary sources

MT retirement is space-specific: CBPR+ interbank coexistence ended 22 November 2025, the interbank MT101 relay retires in November 2026, and corporate-to-bank SCORE usage moves on bank-specific timelines. Verify current status against SWIFT's programme documentation.

- SWIFT — ISO 20022: Corporates (FAQ) — accessed 2026-08-02 — https://www.swift.com/standards/iso-20022/iso-20022-faqs/corporates
- SWIFT — ISO 20022 FAQs: MT to ISO 20022 conversion (contingency processing) — accessed 2026-09-25 — https://www.swift.com/standards/iso-20022/iso-20022-faqs/mt-iso-20022-conversion
- SWIFT — ISO 20022 in bytes: Call to action for November 2026 — accessed 2026-08-02 — https://www.swift.com/standards/iso-20022/iso-20022-bytes/call-action-november-2026
- Nordea — Request for Transfer (MT101) service description — accessed 2026-08-02 — https://www.nordea.fi/Images/147-81975/Request%20for%20Transfer%20Service%20description%2003.2019.pdf
- ING — ISO 20022 SWIFT CBPR+ update — accessed 2026-08-02 — https://www.ingwb.com/en/service/payments-and-collections/iso20022-swift-cbpr-update
- ISO 20022 — Message definitions catalogue — accessed 2026-08-02 — https://www.iso20022.org/iso-20022-message-definitions
- Paiementor — SWIFT serial and cover payments — accessed 2026-08-02 — https://www.paiementor.com/swift-serial-and-cover-payments/
- The Global Treasurer — SWIFT message MT202 COV: background and impact — accessed 2026-08-02 — https://www.theglobaltreasurer.com/2009/05/26/swift-message-mt202-cov-what-are-the-background-and-impact-points-for-banks/

## Questions this article answers

**Q: What is the difference between MT101 and MT103?**

MT101 is the Request for Transfer — an instruction from a corporate to a bank, usually relayed through a forwarding bank, asking the account-servicing bank to debit the corporate's own account there. MT103 is the Single Customer Credit Transfer — a bank-to-bank message that carries a customer payment through the correspondent chain. Corporates sent MT101s; only banks send MT103s. Their ISO 20022 successors are pain.001 and pacs.008 respectively.

**Q: What is the difference between MT103 and MT202?**

MT103 and MT202 are both bank-to-bank messages; the difference is whose money moves. MT103 carries a customer's credit transfer — a named ordering customer paying a named beneficiary. MT202 is the General Financial Institution Transfer: banks moving their own funds, including the settlement legs behind customer payments. MT202 COV is the cover variant that must also carry the underlying ordering and beneficiary customer details. In ISO 20022 they map to pacs.008 and pacs.009 (with a COV usage).

**Q: Are MT103 and MT202 still used after the ISO 20022 migration?**

Not as the standard for cross-border payments over SWIFT. The CBPR+ coexistence period ended on 22 November 2025, and the MT 1xx, 2xx and 9xx categories no longer meet CBPR+ requirements there — pacs.008 and pacs.009 do that work now; an MT a straggler bank still sends is handled through SWIFT's contingency conversion, for a fee, not as normal traffic. The names survive in older documentation, bank contracts and everyday speech (people still ask for 'the MT103 copy'), and other market infrastructures run their own migration timelines, but for the SWIFT cross-border space they are legacy.

**Q: Is MT101 still supported?**

In the corporate-to-bank space, yes for now: SWIFT's SCORE users — corporates and their banks — can continue to exchange MTs such as MT101, MT940 and MT942 after November 2025, and migration is not yet mandatory for corporates, though SWIFT strongly encourages moving. The interbank MT101 relay is different: it retires in November 2026 in favour of the pain.001 relay, with contingency conversion and fees for stragglers. Either way the direction of travel is pain.001.

---

# Treasury Data Lineage: Source to Reported Number

Source: https://gravam.com/blog/treasury-data-lineage
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Answer 'where did this number come from?' in minutes, not days: trace any treasury figure from source transaction to reported number — and who owns each hop.

**Every treasury report makes a promise: this number is real. Data lineage is how you keep it.** A cash position, a liquidity forecast, an exposure figure, a covenant ratio — each is the end of a chain that started as a source transaction and passed through mappings, enrichments and aggregations to reach the report. When someone asks "where did this come from?" — an auditor, a CFO, you at close — lineage is the difference between a confident, traceable answer and an uncomfortable "the system produced it." This is how you build the chain, and own it.

## What lineage actually traces

Lineage isn't a diagram you draw once and frame. It's the answer to a specific, repeatable question: for _this_ reported number, what is the exact path back to source, and who is accountable at each hop? A treasury figure typically travels through the same stages:

```text
Source transaction        e.g. an FI document, a treasury deal, a bank statement item
      │  (capture)
      ▼
Transformation            derive cash relevance, value date, direction, amount in currency
      │
      ▼
Enrichment                add house bank / account, counterparty, GL mapping
      │
      ▼
Liquidity-item mapping    classify the flow into the reporting taxonomy
      │
      ▼
Aggregation               roll up by account, entity, currency, horizon
      │
      ▼
Semantic / reporting layer   the model the report reads: named measures, hierarchies
      │
      ▼
Reported number           the figure a human sees and decides on
```

Each arrow is a _transformation with an owner_. The reported number is only as trustworthy as the least-understood hop in that chain — and the hops people understand least are usually the mapping and the semantic layer, where business meaning gets attached and quietly encoded.

## The lineage record: what to capture per hop

For lineage to be usable — in an audit, in an incident, in a redesign — each hop needs the same handful of facts recorded. This is the artefact, and it's deliberately boring:

| Hop | Input | Transformation / rule | Output | Owner |
| --- | --- | --- | --- | --- |
| Capture | Source document | What makes it treasury-relevant | A raw flow | Source system owner |
| Transformation | Raw flow | Date, direction, currency logic | A normalised flow | Treasury systems |
| Enrichment | Normalised flow | Bank/account, counterparty, GL mapping | Enriched flow | Master data owner |
| Liquidity-item mapping | Enriched flow | Classification rule → reporting taxonomy | Classified flow | Reporting/data owner |
| Aggregation | Classified flows | Roll-up dimensions and rules | Aggregates | Reporting owner |
| Semantic layer | Aggregates | Named measures, hierarchies, filters | Report-ready model | Reporting owner |

The value isn't the table — it's the two columns people skip: **transformation rule** and **owner**. A lineage with boxes and arrows but no rules is a picture; a lineage with rules but no owners is a document nobody maintains. Both columns, or it won't survive contact with a real question.

## Lineage and the system of record are a pair

Lineage doesn't replace the [system-of-record discipline](https://gravam.com/blog/treasury-system-of-record) — it depends on it. The system of record names the single owning source for each data domain; lineage is the owned path _from_ that source to the report. If two systems both claim to own "cash balances," lineage forks and every downstream number inherits the ambiguity. So the sequence is: **name one owner per domain first, then trace the lineage from it.** The free [System-of-Record Map](https://gravam.com/tools/system-of-record-map) is built for that first step. One without the other leaks — a clear owner with an untraced path, or a documented path from a source nobody agreed was authoritative.

> The system of record tells you where the truth starts. Lineage tells you what happens to it on the way to the report. A number you can't trace to a single owned source isn't a fact — it's an assertion.

## Reconciliation evidence falls out of good lineage

Here's the payoff most teams miss: **you don't reconcile a well-traced number — you _reproduce_ it.** When every hop has a rule and an owner, reconciliation stops being a search for where two numbers diverged and becomes a walk down a known path: this source produced these flows, this mapping classified them, this aggregation rolled them up, and the report shows the result. A discrepancy points at a _specific_ hop.

That's the same method that debugs [cash flows in FQM_FLOW](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting) and [postings in TRM](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture): localise the stage, then the rule, then the cause — never "correct" the output. Lineage is what makes that method possible across the whole reporting chain, not just inside one module.

## Where lineage breaks

The failure modes are consistent, and all of them are ownership failures wearing a technical disguise:

- **The unmapped hop.** A transformation everyone relies on and nobody owns — usually a spreadsheet or a mapping table maintained by one person who's since moved on.
- **The silent taxonomy.** Liquidity-item or classification rules that encode business meaning with no documentation, so the _why_ behind a number lives only in someone's head.
- **The forked source.** Two systems claiming the same domain, so lineage can't resolve to one origin.
- **The opaque semantic layer.** A report model with derived measures whose formulas aren't traceable back through the aggregation to source.
- **Lineage as a one-off.** Drawn for a go-live, never maintained, wrong within a quarter. Lineage is a living record or it's decoration.

## What good looks like

- **Every reported number traces to a single owned source**, through hops that each have a documented rule and a named owner.
- **The taxonomy is explicit.** Liquidity-item and classification rules are written down, not folklore.
- **Reconciliation is reproduction.** You can walk any figure back to source on demand — for an auditor, a CFO, or yourself.
- **Lineage is maintained**, versioned alongside the reporting model, and updated when a rule changes — not redrawn in a panic before an audit.

Treasury spends enormous effort producing numbers and comparatively little proving they're real. Data lineage closes that gap: it turns "the system says so" into "here's the path, hop by hop, owner by owner." Build it once as a living artefact and every downstream question — audit, incident, redesign — gets easier. Skip it, and you'll rebuild the chain from memory every time someone asks the one question that matters: _where did this number come from?_

***

_See also [the treasury system of record](https://gravam.com/blog/treasury-system-of-record) and [treasury reporting & analytics architecture](https://gravam.com/blog/treasury-reporting-and-analytics-architecture)._

## Questions this article answers

**Q: What is treasury data lineage?**

Treasury data lineage is the documented path a treasury figure takes from its source transaction to the number that appears in a report — every transformation, enrichment, mapping and aggregation in between, and who owns each step. It answers the question that stalls audits and management reviews: 'where did this number come from, and can we prove it?' Lineage isn't a diagram for its own sake; it's the evidence that a reported figure is derived, consistently and reproducibly, from real source data — and the map you follow when a number looks wrong.

**Q: Why does treasury data lineage matter?**

Because treasury reports drive decisions and face auditors, and 'the system says so' is not an answer. Without lineage, a wrong number is unexplainable — you can't say which source, which mapping or which aggregation produced it, so you can't fix the cause or defend the figure. With lineage, every number is traceable to its source and every transformation is owned, so reconciliation is evidence rather than a hunt, audits are answerable, and a discrepancy is a lookup instead of an investigation. It's the difference between a reporting layer you trust and one you argue with.

**Q: How is data lineage different from a system of record?**

A system of record names the single owning source for a data domain — the authoritative place a piece of data lives. Data lineage is the path _between_ systems: how data flows from that source of record, through transformations and mappings, to the reported number. They're complementary: the system of record tells you where truth originates for each domain; lineage tells you what happens to that truth on its way to a report. You need both — a clear owner per domain, and a documented, owned path from owner to output.

---

# Bank Connectivity Security: Keys, Certificates and Controls

Source: https://gravam.com/blog/bank-connectivity-security
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: The security layer under treasury bank connectivity: certificate and key lifecycle, mTLS, OAuth, key rotation, HSM, SWIFT CSP, and who owns the technical user.

**A payment file is only as trustworthy as the weakest control between your treasury system and the bank — and that's a stack, not a switch.** Most treasury architectures describe the _channels_ well: SWIFT, [host-to-host, EBICS and bank APIs](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics). Far fewer describe the security _under_ them with the same rigour — the certificates, keys, signing, rotation and ownership that decide whether a payment instruction can be trusted. That gap is where operational risk concentrates: an expired certificate that stops a payment run, a signing key nobody owns, a technical user with standing access and no monitoring. This is the layer, made explicit.

## Security is layered — name the layers

The mistake is treating connectivity security as "we use TLS." Real assurance comes from distinct layers, each answering a different question. When one fails, the others should still hold.

| Layer | What it protects | The control | Fails as… |
| --- | --- | --- | --- |
| **Transport** | The channel itself | TLS / mutual TLS — both ends present certificates | Eavesdropping, impersonation of an endpoint |
| **Authentication** | Who is connecting | Client certificates, [EBICS](https://gravam.com/blog/ebics-european-bank-connectivity) keys, OAuth client credentials | An unauthorised party sending on your behalf |
| **Integrity & origin** | The message content | Digital signature over the payload | A tampered or forged payment file |
| **Confidentiality** | The content in transit/at rest | Message/file encryption | Sensitive payment data exposed |
| **Key & identity mgmt** | The credentials themselves | Key storage (incl. HSM), rotation, technical-user ownership | Stale, orphaned or leaked keys |
| **Monitoring** | The whole thing over time | Expiry alerts, anomaly detection, log review | A silent expiry or a breach nobody notices |

Two things this table makes obvious. First, **mTLS and message signing are not redundant** — mTLS secures the _pipe_ and proves the _endpoints_; the signature proves the _file_ came from you, unaltered, even if it's later stored or forwarded. Payments deserve both. (For cheques the bank-side equivalent is [positive pay](https://gravam.com/blog/positive-pay-in-sap): the bank checks each presented item against the issue file you sent.) Second, most real incidents live in the bottom two rows — key management and monitoring — not the cryptography itself. The maths rarely breaks; the _operations_ around it do.

## Certificates and keys: the lifecycle that actually causes outages

Certificates and keys are not set-and-forget. They have a lifecycle, and every stage has a failure mode that shows up as "payments stopped."

- **Issuance.** Generated and requested with the right parameters, for a named purpose and owner. A key with no owner is a future incident.
- **Storage.** Private keys protected — ideally in a **hardware security module (HSM)** for high-value channels, so the key can be _used_ without being _extractable_. A private signing key sitting in a file share is the risk in one sentence.
- **Distribution / exchange.** The initial key or certificate exchange with the bank, done through the bank's defined, verified process — the moment most vulnerable to a social-engineering or man-in-the-middle attempt.
- **Rotation.** Planned well ahead of expiry, coordinated with the bank, tested where possible. The two failures here are the _unnoticed expiry_ (silent outage) and the _stale credential_ that outlives its person or purpose.
- **Revocation.** A fast, rehearsed path to revoke and replace a compromised or orphaned credential — before you need it in anger.

> Cryptography almost never fails. Certificate expiry, orphaned keys and unrehearsed revocation fail constantly. Treat key _operations_ as the real control, and the crypto takes care of itself.

## Authentication for APIs: OAuth client credentials

As banks expose APIs, connectivity increasingly authenticates with **OAuth client-credentials**: the treasury system exchanges a client ID and secret (or, better, a certificate-bound credential) for a short-lived access token, and calls the API with that token. The security properties differ from certificate-based file channels and deserve their own handling:

- **Short-lived tokens** limit the blast radius of a leak — but the underlying client secret / key still needs the same lifecycle discipline as any credential.
- **Scope the credential** to exactly what it may do (which accounts, which operations) — least privilege at the API level.
- **Bind and store the secret** as carefully as a private key; an OAuth client secret in source control or a config file is the API-era equivalent of a key on a file share.

The channel is newer; the discipline is identical.

## The technical user: the control everyone forgets

Behind every automated bank connection is a **technical (service) user** — the non-human identity the treasury system uses to connect. It's the most over-privileged, under-owned object in many landscapes:

- **Ownership.** A named human owns it — not "the treasury team." Ownership means someone is accountable for its credentials, its access and its rotation.
- **Least privilege.** It can do exactly what the integration needs and nothing more. A technical user with broad standing rights is a standing risk.
- **Segregation.** The identity that _connects_ is separate from the identity that _approves_ — the automation must not also hold the authority to release payments unchecked. This is the connectivity face of the [payment approval controls](https://gravam.com/blog/what-is-a-payment-factory) treasury already runs.
- **Monitoring.** Its activity is logged and reviewed; anomalous use is alertable.

## SWIFT CSP: a baseline worth borrowing

If you're on SWIFT, the **Customer Security Programme (CSP)** isn't optional: it's a mandatory programme to protect your SWIFT-related infrastructure, built around the **Customer Security Controls Framework (CSCF)** — a baseline of _mandatory_ controls every in-scope user implements and _advisory_ controls that are recommended (and can become mandatory over time). Users **attest annually**, and the controls map to recognised standards (ISO 27002, PCI DSS, SOC 2, NIST CSF).

Even off SWIFT, borrow the shape of it: segregation of the SWIFT/connectivity environment, least-privilege access, integrity of the operator flow, and monitoring. CSP formalises for SWIFT what every bank channel needs anyway — which is why it's a sound checklist for host-to-host, EBICS and API connections too.

## A connectivity-security checklist

Run this against every bank channel you operate:

- [ ] Every certificate and key is **inventoried** with its expiry, owner and channel.
- [ ] **Expiry monitoring** alerts weeks ahead — no channel relies on someone remembering.
- [ ] Private keys are **protected appropriately** (HSM for high-value channels), never extractable from a file share.
- [ ] **mTLS** for the transport _and_ **signing** for the payload on payment channels — not one or the other.
- [ ] OAuth client secrets are **scoped, bound and stored** like private keys.
- [ ] Each **technical user is owned** by a named person, least-privileged, and segregated from approval authority.
- [ ] A **rehearsed revocation/rotation** path exists — tested, not theoretical.
- [ ] If on SWIFT, **CSP attestation** is current and mandatory controls are met.

## Where this sits in the architecture

Connectivity security is the bridge between [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) and [operational resilience](https://gravam.com/blog/disaster-recovery-business-continuity-treasury): it's an architectural concern (how systems connect), a controls concern (who can do what), and an operations concern (keeping it alive over time). Design it as one layered stack — transport, authentication, integrity, confidentiality, key management, monitoring — assign every key and technical user an owner, and automate expiry alerting, and the channel stops being the fragile, invisible part of the landscape. Leave it implicit, and you'll discover it exactly once: the morning a certificate expires and a payment run doesn't go out.

***

_See also [treasury bank connectivity: SWIFT, host-to-host, API and EBICS](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) and [the reference architecture for corporate treasury](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._

## Primary sources

Vendor- and channel-neutral. Specific requirements depend on your channel (SWIFT, EBICS, host-to-host, API) and bank; SWIFT CSP applies to SWIFT users and its controls are versioned annually — verify against the current framework.

- SWIFT — Customer Security Programme (CSP) — accessed 2026-07-28 — https://www.swift.com/myswift/customer-security-programme
- SWIFT — Customer Security Controls Framework (CSCF) — accessed 2026-07-28 — https://www.swift.com/myswift/customer-security-programme-csp/security-controls

## Questions this article answers

**Q: What secures a treasury bank connection?**

Layered controls, not one setting. Transport is secured with TLS — often mutual TLS (mTLS), where both the client and the bank present certificates — so each end proves who it is and the channel is encrypted. Messages are additionally signed (proving origin and integrity) and often encrypted (protecting content), so a payment file is trustworthy even independent of the pipe it travelled through. Access is authorised: client certificates, EBICS keys, or OAuth client credentials for APIs. And all of it rests on identity and key management — whose keys, stored where, rotated when — plus monitoring so an expiry or anomaly is caught before it stops payments.

**Q: What is SWIFT CSP and is it mandatory?**

The SWIFT Customer Security Programme (CSP) is a mandatory programme for SWIFT users to protect their SWIFT-related infrastructure against cyber threats. Its core is the Customer Security Controls Framework (CSCF), which defines a baseline of mandatory controls (that all in-scope users must implement) and advisory controls (recommended, and some become mandatory over time). Users attest their compliance annually. The controls are aligned to recognised standards such as ISO 27002, PCI DSS, SOC 2 and NIST CSF. It applies to SWIFT connectivity specifically — but its principles (segregation, least privilege, monitoring, integrity) are a sound baseline for any bank channel.

**Q: How often should bank connectivity certificates and keys be rotated?**

On a defined schedule and before expiry — never reactively after payments have already failed. Certificates and keys have finite lifetimes; the risks are an unnoticed expiry (which silently breaks a channel) and a stale credential that outlives the person or purpose it was issued for. Good practice is a tracked inventory of every certificate and key with its expiry, owner and channel; rotation planned well ahead of expiry; and automated expiry monitoring that alerts weeks in advance. Rotation itself is a coordinated change with the bank, tested in a non-production channel where possible, with a rollback path.

---

# Treasury Data Quality and Governance

Source: https://gravam.com/blog/treasury-data-quality-and-governance
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: Treasury data quality decides which numbers you can trust — cash, exposure, valuation, forecast are all computed from it, and governance keeps it clean.

**Everything treasury reports and decides — the cash position, the exposures, the valuations, the forecasts — is _computed_ from underlying data, which means data quality is the quiet ceiling on whether any of it can be trusted.** A wrong number in treasury rarely comes from a wrong formula; the formulas are old and well understood. It comes from wrong data flowing through a correct formula, and the result still looks like a number. This article is about the _quality_ of the data the [treasury data model](https://gravam.com/blog/treasury-data-model) describes, and the _governance_ that keeps it clean. Across SAP FI/TRM and treasury systems, it is the least visible discipline in the landscape — and the one that most often explains the reconciliation that never quite closes.

## Why data quality is the whole game

A treasury system does not store its answers. It stores data and derives them: balances and flows become the cash position, deals and market data become valuations and exposures. Every output is downstream of data you fed in earlier, often by someone who has since moved on.

So if the data is right, correct logic produces correct numbers; if the data is wrong, that same logic produces wrong numbers _confidently_ — no error, no red flag, just a figure that is off, right up until every number is suspect at once.

## The dimensions of data quality

"Quality" sounds vague until you break it into the dimensions that actually fail. Five carry most of the weight in treasury:

- **Accuracy** — the data reflects reality. A bank account number that is wrong by one digit is inaccurate, and it does not throw an error; it routes a real payment to the wrong place.
- **Completeness** — nothing required is missing. A deal captured without its settlement instructions, or a counterparty without its country, is incomplete — and the gap surfaces downstream as a payment that cannot settle or an exposure that cannot be classified.
- **Consistency** — the same thing is defined the same way everywhere. If "counterparty exposure" or a currency's rounding is defined one way in the ERP and another in the TMS, the two systems disagree by design, and nothing reconciles.
- **Timeliness** — the data is current when it is used. Valuing today's positions on yesterday's FX rates, or building a cash position on a statement that has not yet arrived, gives a stale answer that looks perfectly live.
- **Uniqueness** — no duplicates. The same real-world counterparty entered twice fragments your view of exposure to that name: you look within limit on each record and are over it in reality.

Each of these fails silently. That is the common thread — none of them announces itself as a data problem. They announce themselves as a wrong position, a stuck payment, a broken reconciliation, weeks later and hard to trace back.

## Turning dimensions into checks

A dimension you can't check is a dimension you can't govern. Each one maps to a concrete, automatable rule — and to the specific incident that rule heads off before it reaches a report:

| Dimension | An automated check | The incident it prevents |
| --- | --- | --- |
| **Accuracy** | Bank account passes IBAN / checksum validation | A real payment routed to a wrong account |
| **Completeness** | Every deal has settlement instructions before it posts | A trade that can't settle |
| **Consistency** | One agreed definition of each metric across ERP and TMS | Two systems that never reconcile |
| **Timeliness** | Rate / statement is dated _today_ before it's used | Valuing today's positions on yesterday's rates |
| **Uniqueness** | No duplicate counterparty / account records | Exposure understated across records that never aggregate |

This is what "monitoring" concretely means: the checks in the middle column run continuously, so a data problem is caught by a control instead of surfacing weeks later as a wrong number no one can trace. And when one does slip through, [data lineage](https://gravam.com/blog/treasury-data-lineage) — knowing every hop from source transaction to reported figure — is what makes the trace possible at all.

## Master data: the highest-stakes case

Not all data carries equal risk, and [master data](https://gravam.com/blog/treasury-master-data-management) carries the most. It — banks, accounts, counterparties, instruments, settlement instructions — is stable but _shared by everything_, so a single wrong record does not corrupt one transaction; it corrupts _every_ transaction that references it, for as long as it stands.

> Bad transactional data is one wrong number. Bad master data is every number that touched it.

A wrong bank account is not a data-quality footnote — it is a payment incident waiting for a payment run. A duplicated counterparty is an exposure understated across two records that never aggregate. This is where the model and data quality meet: the model says which data is shared and authoritative; quality determines whether that authoritative data is actually right. Get master data wrong and the coherence of the model cannot save you — the whole structure is built on a value that lies.

## Governance: keeping it clean is a discipline, not an event

Data quality does not stay high on its own. Left alone it decays — accounts go stale, definitions drift, duplicates creep in as people onboard the same entity twice. Governance is the standing discipline that resists that decay, with four moving parts:

- **Ownership.** Each data domain has a _named_ owner — a person or role accountable for it — not a vague sense that "someone in treasury looks after banks." Data with no owner is data no one keeps clean.
- **Standards and definitions.** The same thing means the same thing everywhere: an agreed definition per field and per metric, so consistency is designed in rather than negotiated after every disagreement.
- **Maintenance workflow with controls.** Changes flow through a defined path with the right approvals — four-eyes on the changes that move money, following the [system-of-record](https://gravam.com/blog/treasury-system-of-record) rule that a field is edited only in its owning system and copied everywhere else.
- **Monitoring and quality checks.** Automated checks that catch drift — duplicates, missing required fields, values outside plausible ranges, stale records — _before_ they become a wrong number, so problems are found by a control and not by an incident.

None of this is a one-off. It is an operating responsibility that runs for as long as the landscape does.

## Migration and steady state: two very different battles

Data quality has to be won twice, and the second win is the harder one.

At **migration**, before go-live, there is focus, budget and a deadline. Everyone accepts that legacy data must be cleaned, deduplicated and validated before it moves, and the work gets done because a bad go-live is a failure nobody will own.

At **steady state**, the pressure is off. The project team has disbanded, and the data that was pristine on day one starts to drift: new accounts added under time pressure without full validation, duplicates slipping in, promised reviews quietly stopping. This is the gap governance exists to close — keeping data clean _after_ the launch adrenaline is gone, when it is nobody's obvious job and no deadline forces the issue.

## Docs-vs-reality: the discipline nobody wants to fund

Here is the pattern I keep meeting. Data quality is invisible when good and catastrophic when bad, so it is chronically under-funded. Everyone wants the [dashboard and the analytics](https://gravam.com/blog/treasury-reporting-and-analytics-architecture); almost no one wants to own the reference data those reports silently inherit. The money goes to the front end and the foundation gets whatever is left.

The bill still arrives — just later, and disguised. The reconciliation that never closes, the exposure figure two people cannot agree on, the payment that went somewhere it should not have: run any of them to ground and the cause is almost always here — a duplicate, a stale rate, a definition that meant two things, an account maintained in two places. On paper, data quality is a setup task you finish before go-live. In reality it is a live control surface, and usually the least-owned one in the landscape.

Name an owner for every domain, agree the definitions, control the changes, monitor for drift, and treat the work as continuous rather than a one-time cleanse — and treasury data becomes the dependable foundation every number quietly stands on. Skip it, and you build ever more sophisticated reporting on data you cannot trust: a fast, expensive way to be precisely wrong. The domain where this bites hardest and shows up soonest is exposures, where a bad definition becomes a mis-sized hedge — covered on its own in [exposure data quality](https://gravam.com/blog/treasury-exposure-data-quality).

***

_See also [the treasury data model](https://gravam.com/blog/treasury-data-model) and [treasury master data management](https://gravam.com/blog/treasury-master-data-management)._

## Questions this article answers

**Q: Why does treasury data quality matter?**

Because everything treasury reports and decides is computed from underlying data, not conjured from nowhere. The cash position, exposures, valuations and forecasts are all derived figures, so their trustworthiness is capped by the quality of the data underneath them. A wrong number in treasury almost never comes from a wrong formula — the formulas are stable and well understood — it comes from wrong, missing, stale or duplicated data feeding a correct formula. Data quality is therefore the quiet determinant of whether any treasury output can be relied on at all.

**Q: What are the dimensions of data quality?**

The standard dimensions are accuracy (the data reflects reality — the account number is the real one), completeness (nothing required is missing — every deal has its settlement instructions), consistency (the same thing is defined the same way everywhere — one counterparty, one definition, across systems), timeliness (the data is current when it is used — today's rates for today's valuation, not yesterday's), and uniqueness (no duplicates — one record per real-world counterparty or account). A failure in any one of them produces outputs that look right and are wrong.

**Q: What is data governance in treasury?**

Data governance is the ongoing discipline that keeps treasury data fit to rely on: a named owner for each data domain, agreed standards and definitions so the same thing means the same thing everywhere, a controlled maintenance workflow with the right approvals, and monitoring and quality checks that catch drift before it becomes a wrong number. It is not a one-off cleanse before go-live; it is a continuous operating responsibility. Governance is what turns data quality from a project milestone into a property the landscape keeps over time.

---

# EBICS Explained: European Bank Connectivity

Source: https://gravam.com/blog/ebics-european-bank-connectivity
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: What EBICS is — an internet-based European standard for exchanging payment and statement files with banks — and where it fits alongside SWIFT and host-to-host.

**EBICS is an internet-based standard for exchanging payment and statement files between a company and its banks, used mainly in parts of Europe.** It is strong in Germany and France and also used in Switzerland and Austria, and where your banks support it, one standardized channel reaches many of them. If you have read the [bank connectivity options overview](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), EBICS is one of the four channels there; this is the deep dive on what it actually is and when I reach for it.

## What EBICS is

EBICS stands for the Electronic Banking Internet Communication Standard. Strip away the acronym and it is a **secure way to move files between a corporate and its banks over the internet** — payment instructions going out, account statements coming back. It originated in Germany, evolved from the earlier German banking-communication lineage that predated it, and was then adopted in France; those two markets are where you meet it most, with Switzerland and Austria also using it.

EBICS is one of those standards that is simply a fact of life if your bank landscape sits in its home markets. You do not choose it in the abstract — you choose it because your German or French banks speak it, and speaking it well is cheaper than building something bespoke to each.

## How it works, conceptually

At the level that matters for architecture, EBICS is straightforward. There is a **secure HTTPS connection** between your systems (or your connectivity layer) and the bank. Over that connection you **upload and download structured files** — typically [ISO 20022 XML](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002): `pain` messages for payments going out, `camt` for [statements coming back](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2). The transport carries the file; the file carries the content. Those are two separate concerns, and keeping them separate in your head saves a lot of confusion.

The part I find genuinely useful is the **authorisation model**. EBICS uses electronic signatures to authorise orders, and it supports a **distributed electronic signature** — several authorised people can sign off an order independently, from wherever they are. That is not a cosmetic feature. It means the standard has segregation of duties built into the channel itself: the person who prepares a payment run does not have to be the person who releases it, and you can require two approvers on a high-value file without inventing a workflow around the bank connection. For payments, where the whole point is that no single hand moves the money alone, that is a real advantage. Those signatures rest on keys and certificates that have to be initialised, stored and rotated properly — the [security layer under bank connectivity](https://gravam.com/blog/bank-connectivity-security) is its own discipline, whatever the channel.

> EBICS carries the file; the file carries the content. Keep the channel and the format separate in your head and half the confusion disappears.

> **Figure — EBICS as one channel between a company and its banks**
>
> You on the left, your banks on the right, and one secured channel labelled EBICS between them. A pain file travels from you to the banks, and a camt file travels back.
>
> EBICS carries the file; the file carries the content — pain going out, camt coming back.

## Where it fits versus SWIFT and host-to-host

The three channels are easiest to place by their footprint.

- **SWIFT** is the global network — one standardized connection that reaches banks across the world. Its strength is breadth across regions.
- **Host-to-host** is a bilateral, direct file link to one specific bank — efficient for a few strategic, high-volume relationships, but every link is its own setup.
- **EBICS** sits in between for its region: a **standardized protocol that many European banks support**, so one channel reaches many banks without building a bespoke link to each. That is its whole appeal — the standardisation of host-to-host-style file exchange, but shared across the banks in its markets rather than negotiated one relationship at a time.

The [connectivity options overview](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) has the fuller side-by-side on reach, cost and real-time capability. The short version: EBICS is the natural in-region channel where your banks support it, and it coexists happily with SWIFT for anything outside its footprint.

## Why a corporate would choose it

Three reasons come up again and again.

- **Regional bank coverage.** In Germany and France especially, EBICS is a mainstream corporate channel. If that is where your banks are, the coverage is already there — you are joining an established standard, not pioneering.
- **Standardisation.** One protocol across many banks beats a separate bespoke arrangement per bank. It reduces the variation you have to manage.
- **Native fit with modern formats and approval.** EBICS pairs naturally with ISO 20022 files and has multi-signer approval built in. If your target state is `pain`/`camt` with proper segregation of duties, the channel is already aligned with that.

## The caveats

None of that makes it a universal answer, and I would be doing you a disservice to pretend otherwise.

- **It is regional.** EBICS is excellent in-region and largely irrelevant outside it. It is not a global connectivity strategy on its own — pair it with SWIFT or another channel for banks beyond its markets.
- **National variants have differed.** Historically the German and French flavours were not identical. Later versions of the standard — EBICS 3.0 among them — aimed to harmonise the national variants, and I would treat that as a direction of travel rather than a finished, uniform reality. Check what version and variant each bank actually supports.
- **Every bank still onboards its own way.** The standard narrows the variation; it does not erase it. Each bank has its own onboarding, its own set of supported order types, its own quirks in what it will and will not accept.

## EBICS still means bank-by-bank onboarding

Here is the lesson I keep relearning. On paper, EBICS looks like _one standard_ — implement it once and you are connected to everyone. In practice you still **onboard and test bank by bank**. The signature setup, the initialisation, the exact order types, the formats each bank expects in each direction — those get agreed and proven per relationship, the same as every other channel.

That is not a criticism of EBICS. It is the universal truth of bank connectivity, and it is the same warning I give about SWIFT, host-to-host and APIs: the standard reduces the variation, it does not remove it. A standardised channel gets you most of the way, and then each bank's onboarding gets you the last mile. Plan for that last mile, budget the testing, and start early. The teams that get burned are the ones who read "standard" as "plug and play" and discover at go-live that bank number four needed a different order type than the three before it.

Treat EBICS for what it is — a genuinely useful, standardised European channel with proper multi-signer approval baked in — and it earns its place in the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury). Just hold it to the same discipline as any other connection: agree the formats, onboard bank by bank, and monitor every link.

***

_See also [bank connectivity security](https://gravam.com/blog/bank-connectivity-security) for the keys and certificates behind the channel, and [straight-through processing in treasury](https://gravam.com/blog/straight-through-processing-in-treasury) for what the channel is meant to enable._

## Primary sources

- EBICS — Electronic Banking Internet Communication Standard — accessed 2026-07-29 — https://www.ebics.org/en/home
- PPI — EBICS Compendium (history, versions, EDS) — accessed 2026-07-29 — https://www.ppi-group.eu/en/products/banking-clients/ebics-compendium.html
- SIX — EBICS: Payment Standards for Switzerland — accessed 2026-07-29 — https://www.six-group.com/en/products-services/banking-services/payment-standardization/standards/ebics.html

## Questions this article answers

**Q: What is EBICS?**

EBICS — the Electronic Banking Internet Communication Standard — is an internet-based protocol for exchanging payment and statement files between a company and its banks. It originated in Germany, was adopted in France, and is also used in Switzerland and Austria. Files (commonly ISO 20022 XML) travel over a secure HTTPS connection, and electronic signatures authorise the orders, including a distributed-signature capability where several people can approve independently.

**Q: How is EBICS different from SWIFT?**

SWIFT is the global bank-messaging network — one standardized connection that reaches many banks worldwide. EBICS is a mainly European protocol: where your banks support it, one channel reaches many of them without a bespoke link each, but its relevance is regional rather than global. Many European treasuries use EBICS in-region and SWIFT for broader reach. They solve the same problem — moving statements in and payments out — in different footprints.

**Q: Which countries use EBICS?**

EBICS is strongest in Germany and France, where it is a mainstream corporate channel, and is also used in Switzerland and Austria. It grew out of Germany's earlier banking-communication lineage and was adopted in France, which is why those two markets dominate. Outside its European home markets it is generally not the channel you would reach for.

---

# Disaster Recovery and Business Continuity for Treasury

Source: https://gravam.com/blog/disaster-recovery-business-continuity-treasury
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Keeping treasury running through an outage: how RTO and RPO drive the design, and why the manual fallback is the plan that actually saves the payment.

**Disaster recovery restores the treasury systems; business continuity keeps the treasury _function_ running while they're down — and in treasury the second one is what actually matters.** Most functions can absorb a day's outage as an inconvenience. Treasury can't, because it carries hard, time-bound obligations that don't wait for a system to come back. The design that keeps you safe isn't a bigger backup regime; it's two honest numbers, a manual fallback for the critical few, and a test that proves both work before the day you need them.

## Why treasury is special

Most systems, if they go down for a day, cost you productivity. Treasury systems, if they go down on the wrong day, cost you a missed payment — and treasury's payments have deadlines that are external and unforgiving. Payroll runs on a date. A debt repayment or coupon is due on a date, and being late is a default event, not a late fee. A margin call has to be met within hours. None of these wait politely while IT restores a database.

That's why continuity planning for treasury is a different exercise from continuity planning for the intranet. The question isn't "how do we get the system back?" It's "what must we still be able to do while it's gone?" It sits on the same [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) as everything else, but asks a harder question of it: what happens when a layer disappears?

## RTO and RPO, plainly

Two numbers drive the entire design.

- **Recovery Time Objective (RTO)** — how fast you must be back: the maximum time the treasury system can be unavailable before the outage causes real damage.
- **Recovery Point Objective (RPO)** — how much data you can afford to lose: the maximum gap between your last recoverable state and the moment of failure. An RPO of four hours means accepting the loss of up to four hours of captured deals and payments.

Everything else — backup frequency, replication, failover architecture, cost — falls out of these two numbers. And here is the point most plans get backwards: **RTO and RPO must be set by the business obligation, not by IT convenience.** If a payment run has to go out by 2pm, the RTO for the payment path is dictated by that deadline, full stop — not by whatever recovery window the infrastructure team finds comfortable to promise.

> RTO and RPO are business decisions wearing technical clothing. If the payment is due at 2pm, no amount of "24 hours is our standard" changes what the business actually needs. Set the numbers from the obligation, then make the architecture meet them.

## DR is not BC

These get used interchangeably and they shouldn't. **Disaster recovery** is recovering the systems and infrastructure — restore the database, fail over to the secondary site, rebuild the connectivity. **Business continuity** is keeping the treasury _function_ going whatever state the systems are in, including operating in a degraded or fully manual mode. DR is a technology problem; BC is an operational one, and it's the one that pays a supplier when the TMS is dark.

Moving to SaaS changes the shape of this but not the accountability. A vendor-hosted TMS shifts much of the infrastructure DR onto the vendor — their replication, their failover, their RTO — which is genuinely useful, but it doesn't discharge your responsibility. You still own the _function_. Know the vendor's committed RTO and RPO (read the contract, not the sales deck), what happens when _your_ connectivity or market-data feed fails rather than theirs, and what you do while the vendor is recovering. Outsourcing the servers doesn't outsource the obligation to make payroll.

## The manual fallback

This is the uncomfortable part of the plan, and the part that earns its place. When the [straight-through flows](https://gravam.com/blog/straight-through-processing-in-treasury) stop — the automated pipelines that normally move money from initiation to settlement without a human — someone has to release the critical payments by hand. Not everything. The _critical few_.

A real fallback answers three questions before the crisis, not during it:

- **Which actions genuinely can't wait?** Payroll, a debt repayment falling due, a margin call. Draw the line deliberately; most of what treasury does _can_ wait a day.
- **How do we do them without the system?** Direct access to the relevant bank portals, the beneficiary details you'd need, and a way to approve within your control limits outside the usual workflow.
- **Who is authorised, and can they actually get in?** Named people with live credentials, tokens that exist and work, and approval authority that holds when the normal [monitored workflow](https://gravam.com/blog/interface-monitoring-and-reconciliation) isn't there to enforce it.

The manual fallback is deliberately minimal and deliberately ugly. Its job is to get the unmissable payments out while DR does its work — nothing more.

## Backups, failover, and the thing that separates real plans from paper ones

The technical building blocks are well understood: regular backups tested for _restore_ and not just for completion, replication or failover to a secondary environment, and a defined sequence for bringing systems back in the right order. None of that is exotic.

What separates a real plan from a filed one is **testing**. An untested DR plan is not a plan; it's a hypothesis. Until you've restored the treasury database into a clean environment and confirmed it comes up consistent, you don't know your backups are recoverable — you know they _completed_, which is not the same thing. Test the restore and test the fallback, on a realistic scenario, on a schedule.

## Recovering the TMS alone isn't recovery

A treasury system that's back up but can't reach the banks still can't pay. Recovery has to include the [dependencies](https://gravam.com/blog/treasury-system-of-record): bank connectivity (SWIFT, host-to-host, EBICS or API channels, and the certificates and tokens they rely on), market-data feeds, and the interfaces to and from the ERP. Each has its own recovery path and its own failure modes, and a plan that recovers the core application while ignoring them has recovered a box that can't do its job. Map the full dependency chain and give each link a recovery plan.

## Docs-vs-reality

Continuity plans have a characteristic failure: they're written for the audit, approved, filed, and never opened again — a document that exists to answer "do you have a BCP?" with "yes." It ticks the box and has never met a real outage.

Every time I've seen a treasury continuity plan actually tested against a realistic scenario, the test found something the document couldn't. The manual fallback assumed a bank token nobody could locate. It named an authoriser who had left eighteen months earlier and whose access had been revoked. The RPO on paper was four hours; the actual backup job had been failing silently for weeks. The plan wasn't wrong when it was written — it rotted, quietly, because nothing ever exercised it.

That's the entire argument for testing, and it's why continuity for treasury can't be a document exercise. The obligations are real, dated, and external. The plan that protects you isn't the one that reads best in the audit binder — it's the one that has been run, broken, and fixed, so that on the day the system is down you already know the fallback works and the token is where the plan says it is.

***

_See also [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury) and [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation)._

## Questions this article answers

**Q: What is disaster recovery for a treasury system?**

Disaster recovery is the plan and capability to restore the treasury systems and infrastructure after a serious outage — a data-centre failure, a corrupted database, a ransomware event, a failed upgrade. In treasury it's inseparable from business continuity, because the system exists to meet hard, time-bound obligations: payroll, debt repayments, margin calls, settlement. Recovery means being able to make those payments again, not just bringing a server back online.

**Q: What are RTO and RPO?**

RTO, the Recovery Time Objective, is how fast you must be back — the maximum tolerable time the treasury system can be down. RPO, the Recovery Point Objective, is how much data you can afford to lose — the maximum gap between your last good backup and the moment of failure. Together they drive the whole design and its cost. Crucially, they should be set by the business obligation the system serves, not by what IT finds convenient to deliver.

**Q: How do you keep paying suppliers if the TMS is down?**

Through a manual or degraded fallback: a documented, tested way to release the critical few payments directly through the bank portals, using named authorised people and pre-agreed approval limits, without the treasury system. It won't be pretty or complete — the point is to cover the payments that genuinely cannot wait for recovery. A fallback only works if it's been tested; an untested one usually assumes a token nobody can find or a person who has left.

---

# Audit Trails and Logging in Treasury Systems

Source: https://gravam.com/blog/audit-trails-and-logging-treasury-systems
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: A treasury audit trail must capture who did what, when, and to what — the tamper-evident record that proves segregation of duties and approvals actually worked.

**A treasury audit trail is the complete, tamper-evident record of who did what, when, and to what — and in a system whose entire purpose is to move money, that record is foundational, not optional.** [Segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) and approval workflows decide who _may_ act; the audit trail is what proves those controls actually operated. Every other control in the landscape rests on it, because a control you can't evidence after the fact is a control you can't prove you had.

## Why the audit trail is foundational

A treasury system holds financial data and executes payments and trades — it moves funds out of the company. That is exactly why the other controls exist: separations, four-eyes approvals, limits. But those controls are claims. Segregation of duties says one person _couldn't_ both create and release a payment. The only way to know that claim held — for this payment, on this day — is a record of who created it and who released it. The audit trail is where control design stops being policy and becomes something you can demonstrate.

That framing matters because it tells you what to capture. You are not logging for the sake of logging; you are building the evidence that will be asked for after an incident, in an audit, or in a dispute. The question isn't "does the system log?" It's "can we prove the thing that matters?"

## What to capture

A treasury audit trail needs to cover the actions that move money or change the conditions under which money moves:

- **Transactions.** Create, change and delete of deals, payments and settlement instructions — including cancellations and reversals.
- **Static and master data.** Changes to beneficiary bank details, [standing settlement instructions](https://gravam.com/blog/reference-architecture-for-corporate-treasury), counterparties and approval limits. This is the quiet fraud path, so it needs the same rigour as payments themselves.
- **Approvals and releases.** Who approved what, at what level, and when — the record that makes the four-eyes control provable rather than assumed.
- **Access and privileged actions.** Login and access events, role changes, and administrator or "break-glass" activity, which is precisely the activity most capable of bypassing everything else.
- **System and interface events.** Feed failures, reprocessing, and reconciliation breaks, which connect to [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation) — an integration that fails silently is its own kind of unlogged event.

The distinction that separates a real audit trail from a weak one is the **before-and-after**. Knowing that a bank account was changed is nearly useless; knowing it went from _this_ IBAN to _that_ IBAN, by whom, at that time, is what lets you investigate. Log the _what changed_, not just the _that it changed_.

## The properties that matter

Capturing events is necessary but not sufficient. The trail has to hold up, and that comes down to a handful of properties:

- **Completeness.** Gaps are the finding. An audit trail that covers payments but not master-data changes has a hole exactly where fraud tends to live.
- **Immutability and tamper-evidence.** A log that the same privileged user can quietly edit or delete proves nothing. The record must be protected from the people it records — write-once, protected, or independently held.
- **Attribution to a real individual.** Every entry has to trace to a named person, which means **no shared accounts**. "Changed by SVC_TREASURY" is not attribution; it's an alibi for everyone.
- **Accurate timestamps.** Sequence and timing are half the story — an out-of-hours change, an approval that came before the request. Clocks have to be trustworthy and consistent across systems.
- **Retention.** The record must survive for the required period. The action you most need to explain is often the one furthest in the past.

> A log you can edit proves nothing, and a log under a shared account proves nothing about anyone. Completeness, immutability and attribution aren't features of the audit trail — they _are_ the audit trail.

None of these can be bolted on after an incident. Attribution depends on identity being clean in the first place, which is why the audit trail and [access management and user provisioning](https://gravam.com/blog/access-management-and-user-provisioning-treasury) are the same problem seen from two ends: you can only attribute an action to a person if each person has their own account and their access is known.

## Use it, don't just keep it

A passive log is only useful after the loss. The step that turns a record into an actual control is **monitoring and alerting** on the events that carry risk: a changed beneficiary bank account, a payment released outside business hours, a new admin role granted, a limit raised just before a large deal. These are the patterns that precede real losses, and catching them as they happen is the difference between prevention and forensics.

The audit trail nobody reads still has value as a deterrent and as evidence — but the same data, watched in near real time, stops being a post-mortem tool and starts being a control in its own right. Decide which events deserve an alert, and route them to someone who will act.

## When treasury logs fail to become evidence

On paper, every treasury system "logs everything." That belief holds right up until the first incident, when someone finally goes looking. Then the pattern repeats with grim reliability: the one action that mattered turns out to have been written to a table nobody retained past ninety days, or performed under a shared service account nobody can tie to a person, or captured only as "record updated" with no before-image of the field that was changed. The logging existed; the _evidence_ didn't.

I've watched teams discover, mid-investigation, that the control they were most confident about was the one they couldn't prove. The lesson is uncomfortable and simple: **decide what must be provable before you need to prove it.** Walk the sensitive actions — payment release, bank-detail change, limit override, privileged access — and for each one ask whether, a year from now, you could show who did it, when, and what the value was before and after. Wherever the answer is "probably not," that's not a logging gap. That's an unprovable control, and in a system that moves money, an unprovable control is the one that will be tested.

That's why [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) treats the audit trail as a first-class design concern rather than a switch you turn on at the end. It's the layer that makes every other control real. It is also, almost word for word, what Article 12 of the EU AI Act asks of a high-risk AI system — automatically generated records, at the grain of an event, kept. Which is one reason [the Act's high-risk requirements read like a control environment](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems) rather than a new discipline.

***

_See also [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury), and — when the actor is a machine — [why AI agent logs are not an audit trail](https://gravam.com/blog/ai-agent-logs-are-not-an-audit-trail)._

## Questions this article answers

**Q: What is an audit trail in a treasury system?**

An audit trail is the complete, tamper-evident record of who did what, when, and to what inside the system — every deal, payment, master-data change, approval and access event, tied to a named individual and an accurate timestamp. Because a treasury system moves money and holds financial data, that record is not a nice-to-have: it's the evidence that the other controls, such as segregation of duties and approval workflows, were actually applied. A control you can't evidence after the fact is a control you can't prove you had.

**Q: What should a treasury system log?**

At minimum: create, change and delete of deals, payments, static/master data and settlement instructions, capturing the before-and-after of each change, not just that it happened; approvals and releases, including who approved what and at what level; login, access and privileged/admin actions; and system and interface events such as failed feeds or reprocessing. The gaps are what auditors find, so the design question is which actions must be provable — decide that before you need to prove it.

**Q: Why do auditors care about the audit trail?**

Because it is the only objective evidence that controls operated. Segregation of duties and four-eyes approval are claims about who could and did do what; the audit trail is what turns those claims into something demonstrable. Auditors care most about completeness (no gaps), immutability (a log you can edit proves nothing), attribution to a real person (no shared accounts), and retention for the required period. Without those properties, the control framework is unverifiable.

---

# Access Management and User Provisioning in Treasury Systems

Source: https://gravam.com/blog/access-management-and-user-provisioning-treasury
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: A treasury system can move money, so who can do what inside it is a first-order control. Access management is the foundation segregation of duties stands on.

**In a treasury system, access management is a first-order control, not IT housekeeping.** The system exists to move money, so deciding who can do what inside it is deciding who can create, approve or release a payment, or change the bank details behind one. Get it wrong and the tidiest [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) design in the world is fiction, because it assumes roles are defined correctly and assigned to the right people — which is exactly what access management is supposed to guarantee.

## Access is the layer under everything else

Across SAP FI, treasury and risk systems, the pattern is consistent: teams design segregation of duties carefully, then treat the access model underneath it as an afterthought. That's backwards. SoD says the person who initiates a payment can't approve and release it — but that separation is only real if the system actually restricts each person to their role, and if nobody has quietly accumulated both. Access management is the mechanism that makes the separation true. Without it, SoD is a policy document, not a control — which is why this article is about the layer beneath the [companion control](https://gravam.com/blog/segregation-of-duties-in-treasury-systems): how you grant, shape and remove the rights that SoD then divides up.

## Role-based access control and least privilege

The foundation is **role-based access control (RBAC)**. Instead of switching permissions on user by user — a path that produces a landscape nobody can reason about within a year — you define **roles** that bundle the rights for a job: cash management, payment initiation, payment approval, static-data maintenance, reporting. A person is assigned the role matching what they do and inherits exactly its rights.

RBAC is paired with **least privilege**: each role carries the minimum the job needs, and nothing more. The instinct to grant a bit extra "so they're not blocked later" is how access bloat starts. If someone needs more, that's a role change with its own trail — not a quiet grant no one remembers making.

> Every access right you grant "just in case" is a control you'll have to [explain to an auditor](https://gravam.com/blog/audit-trails-and-logging-treasury-systems) later — and won't be able to.

Done well, RBAC makes access reviewable: you can look at a role and know what it permits, and look at a person and know which roles they hold. That legibility is the whole point — and it's what per-user permission grants destroy.

## The joiner–mover–leaver lifecycle

Access isn't a thing you set up once; it's a **lifecycle**, and provisioning is how you manage it. There are three moments:

- **Joiner.** Someone arrives and needs the roles for their job — granted deliberately, at least privilege, not copied wholesale from whoever sat there before.
- **Mover.** Someone changes role. This is the dangerous one. The new access gets added because the person needs it to work; the old access almost never gets removed, because nothing forces it and no one is watching. Over a few moves, a person accumulates rights they no longer need — and eventually holds a combination that breaks segregation of duties, like being able to both create and release a payment because two old roles were never revoked.
- **Leaver.** Someone departs and their access must be **promptly de-provisioned**. An account that outlives its owner is a live credential with no accountable human behind it.

Orphaned accounts from leavers and accumulated rights from movers are among the most common findings in any access audit. Both are provisioning failures, and the mover case is the quiet killer: nothing breaks when access is left behind — it just sits there until an audit or an incident makes it visible.

## Privileged and administrative access

Not all access is equal. **Privileged and administrative accounts** — the ones that can change configuration, alter roles, or reach beyond a normal user — can rewrite the rules, so they need tighter control than everything else: few, individually attributable rather than shared, granted narrowly, **logged**, and reviewed more often than ordinary access. A shared admin login "for convenience" is the fastest way to make your entire access model unprovable, because you can no longer say who did what with it.

## Periodic access recertification

Even with good provisioning, access drifts — so you check it deliberately. **Access recertification** is a periodic exercise where someone accountable — usually the manager or role owner, not IT — re-confirms who holds what and explicitly approves or revokes it, on a defined cycle, because entitlements accumulate faster than anyone notices.

The recertification has to have teeth. A review where everyone clicks "approve" to clear the queue is theatre. The value is in the revocations — the access someone looks at and says "they don't need that anymore," which is precisely the accumulated-mover access that would otherwise sit there causing a problem later.

## Authentication: the front door

Everything above governs what a user _can_ do; **authentication** governs whether the right person is behind the login at all. **Single sign-on (SSO)** centralises identity so access follows one governed source rather than a scatter of local accounts, and **multi-factor authentication (MFA)** raises the bar on a stolen or guessed password. For a system that moves money, MFA — especially on privileged access — is a baseline, part of the same [security posture](https://gravam.com/blog/payment-fraud-prevention-in-treasury) that guards against payment fraud. Strong internal roles are worth little if the front door opens to anyone with one leaked password.

## Docs–vs–reality

Here's what actually happens. At go-live, access is beautiful. Roles are defined, least privilege is honoured, SoD conflicts are checked, the [system of record](https://gravam.com/blog/treasury-system-of-record) has clear owners and the access matrix is a thing of pride. Everyone signs off.

Then time passes. Movers keep old rights alongside the new. Leavers linger for weeks because de-provisioning depends on someone remembering to raise a ticket. A "temporary" admin grant becomes permanent. The recertification goes unrun, or gets rubber-stamped. Two years in, the elegant model has quietly rotted into a mess where several people can do things the SoD design swore they couldn't — and no one notices, because nothing breaks. It just erodes, silently, until an audit surfaces it or a fraud exploits it.

The lesson I keep relearning: **provisioning is a lifecycle, not a launch task.** The go-live access model is the easy part. Keeping it true through every joiner, mover and leaver — that's the actual control, and it's the part that gets no attention until it's the finding on an audit report.

Define access through roles at least privilege; provision it across the full joiner–mover–leaver lifecycle, treating the mover case as the risk it is; hold privileged access to a higher standard; recertify on a cycle that actually revokes; and put SSO and MFA on the front door. Do that and segregation of duties has firm ground to stand on. Skip it and the whole [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)'s control layer rests on assumptions that stopped being true long ago.

***

_See also [segregation of duties in treasury systems](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) and the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._

## Questions this article answers

**Q: What is access management in a treasury system?**

Access management is the discipline of controlling who can do what inside the system — which users exist, what rights they hold, and how those rights are granted, changed and removed over time. In treasury it matters more than almost anywhere else, because the system moves real money: an access decision is effectively a decision about who can create, approve or release a payment, or change the bank details behind one. It is the foundation that segregation of duties is built on, because SoD only works if roles are defined correctly and assigned to the right people.

**Q: What is role-based access control?**

Role-based access control (RBAC) means access is granted through roles that bundle the rights needed for a job, rather than switching individual permissions on user by user. A person is assigned the role for what they do — cash management, payment approval, static-data maintenance — and inherits exactly the rights that role carries. It is paired with least privilege: each role, and so each person, gets the minimum access the job needs and nothing more. RBAC keeps access consistent, reviewable and much harder to get quietly wrong than per-user permission grants.

**Q: Why does user provisioning matter for treasury?**

Because access in a treasury system decays. Provisioning is the lifecycle of granting access when someone joins, adjusting it when they change role, and removing it promptly when they leave. The dangerous point is the role change: new access gets added, old access rarely gets taken away, and people accumulate conflicting rights that break segregation of duties. Orphaned accounts from leavers and accumulated rights from movers are among the most common audit findings, and both are provisioning failures, not one-time setup mistakes.

---

# Treasury Reporting and Analytics Architecture

Source: https://gravam.com/blog/treasury-reporting-and-analytics-architecture
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-29
Reviewed: 2026-08-02
Summary: Treasury reporting architecture explained — operational, warehouse and BI layers — and why every reported number is only as trustworthy as its source.

**Treasury reporting and analytics architecture is the structure that turns treasury data into the outputs people actually act on — the cash position, the forecast, exposure and risk reports, bank fee and KPI reporting, the board pack — and its real job is not the charts but making sure every number draws from the [right source](https://gravam.com/blog/treasury-system-of-record) at the right time.** A reported figure is only as trustworthy as the source it came from, and across SAP FI, TRM and treasury systems the reporting pain I've seen has almost never been the visualisation tool. It's been ungoverned data: numbers stitched together by hand from sources no one could reconcile. Get the sourcing and the layers right and reporting is a lookup; get them wrong and every board pack is a small act of faith.

## What treasury reporting has to deliver

Treasury reporting isn't one report — it's a family of them, each with its own audience and its own timing:

- **The cash position** — where the money is, by account and currency, today.
- **The cash forecast** — where it's expected to be, over the coming days and weeks.
- **Exposure and risk reports** — FX and interest-rate exposures, limit utilisation, counterparty concentration.
- **Bank fee and KPI reporting** — what banking relationships cost, and how the function is performing.
- **Board packs** — the periodic, summarised view for people who won't open the TMS.

Each of these needs data from the right source at the right moment. The cash position needs current balances from the [data model](https://gravam.com/blog/treasury-data-model)'s bank statements; the forecast needs AP/AR from the ERP plus treasury's own deals; exposures come from positions; the board pack needs consistent, reconciled month-end figures. The mistake is treating them as one reporting problem with one pipe. They're several, and they have genuinely different requirements.

## The core principle: report from the system of record

Here is the whole game in one sentence: **reports must draw from the system of record for each domain, not from whatever spreadsheet is nearest.** A number is only as trustworthy as the source it came from. If the cash position on a board slide was typed from a workbook that someone updated from an email, it isn't a cash position — it's a rumour with a currency symbol. Being able to walk a reported figure back hop by hop to its source transaction — [data lineage](https://gravam.com/blog/treasury-data-lineage) — is what turns "trust me" into "here's the trail."

The [system-of-record discipline](https://gravam.com/blog/treasury-system-of-record) says one system owns the authoritative version of each domain: the TMS owns cash, positions and exposures; the ERP owns the general ledger; the market-data source owns rates. Reporting is a **system of engagement** built on top of that — it _consumes and presents_, it doesn't own. That's exactly why a reporting layer is safe: it makes no claim to be authoritative. The trouble starts the moment a "report" gets edited and quietly becomes a second, competing version of the truth.

> A treasury report is only as trustworthy as the source it was pulled from. The visualisation is the easy part; the sourcing is the whole game.

Reconciled, single-source reporting is what lets a group treasurer sign a number without a caveat. Everything else in this architecture exists to serve that.

## The layers

A working reporting architecture has three layers, each doing a distinct job:

- **Operational reporting** — straight from the TMS or ERP, for day-to-day figures. The daily cash position, today's payments, current limit utilisation. Read close to the source, minimal transformation, current data.
- **Data warehouse / mart** — for cross-system, historical and analytical reporting. This is where you combine treasury data with ERP data, hold consistent point-in-time snapshots, and run the analysis that no single operational system can answer alone. Month-end, trends, year-on-year, bank fee analytics.
- **BI / dashboard layer** — for visualisation and self-service. Dashboards, board-pack visuals, the ability for a treasury analyst to slice a figure without raising a ticket. This layer sits on top of the other two; it presents, it doesn't originate.

The layering matters because each layer answers a different kind of question. Ask an operational system to run five years of historical analysis and you'll strain it and get inconsistent snapshots; drive a live intraday position off a nightly warehouse load and you'll be funding against yesterday.

## Real-time versus periodic

The freshness requirement splits the plumbing. The **daily cash position and intraday views** need current data, read close to the operational source — a treasurer deciding whether to fund an account cannot work from last night's extract. **Month-end and board reporting** is analytical and historical; it's best served from a warehouse holding consistent, reconciled snapshots, because the value there is comparability and completeness, not the last five minutes.

Matching freshness to plumbing is a design decision, not an afterthought. Most "the numbers don't match" complaints trace back to two reports reading the same domain at different freshness — and no one having decided which is authoritative for which purpose.

## Data lineage and trust

The quiet requirement underneath all of this is **lineage**: being able to trace a reported figure back to its source. When someone asks "where did this number come from?", the answer should be a path — this figure came from these positions, valued at these rates, as of this date — not a shrug.

Unexplained numbers destroy confidence in a treasury report faster than wrong numbers do. A wrong number you can trace is a fixable error; a right number no one can explain is a report no one trusts. Lineage is also what makes reconciliation possible: you can only reconcile a number to its source if you know what its source is.

## Reporting failures that start below the tool

On paper, treasury reporting looks like a BI project — pick the tool, build the dashboards, done. In reality, the tool is rarely the problem. I've watched teams agonise over which visualisation platform to buy while the actual failure sat one layer down: **ungoverned data.** Numbers assembled by hand from a dozen sources, each maintained by a different person, none reconciled, none reproducible. Refresh the dashboard and the figures change, and no one can say why.

The pattern is always the same. The official system says one thing; the workbook everyone actually uses says another; the board pack is built from the workbook. The prettiest dashboard layered on top of that is just a faster way to present numbers you can't defend. Fix the sourcing — report from the system of record, hold history in a governed warehouse, make every figure traceable — and the visualisation becomes the trivial last step it was always supposed to be.

This is the [reporting layer of the reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury): not a tool you bolt on, but the disciplined presentation of data whose ownership you already decided. Get the source right and the report tells the truth. Get it wrong and no chart can save it.

***

_See also [the treasury data model](https://gravam.com/blog/treasury-data-model) and [market data in treasury systems](https://gravam.com/blog/market-data-in-treasury-systems)._

## Questions this article answers

**Q: What is treasury reporting architecture?**

Treasury reporting architecture is the structure that turns treasury data into the cash position, forecasts, exposure and risk reports, bank fee and KPI reporting, and board packs. It usually has three layers: operational reporting straight from the TMS or ERP for day-to-day figures, a data warehouse or mart for cross-system, historical and analytical reporting, and a BI or dashboard layer for visualisation and self-service. The architecture's real job isn't the charts — it's making sure every reported number draws from the authoritative source for that domain, so the figure can be trusted and traced.

**Q: Where should treasury reports get their data?**

From the system of record for each domain, not from whichever spreadsheet is nearest. The cash position and exposures come from the TMS, the general ledger from the ERP, market rates from the market-data source. A reported number is only as trustworthy as the source it was pulled from, so reporting should read from authoritative systems (or a warehouse fed from them) rather than being assembled by hand from many disconnected extracts that no one can reconcile.

**Q: What is the difference between real-time and periodic treasury reporting?**

Real-time and periodic treasury reporting have different freshness needs and different plumbing. Real-time or intraday reporting — the daily cash position, live balances, limit monitoring — needs current data straight from operational systems and is read close to the source. Periodic reporting — month-end, quarter-end and board packs — is analytical and historical, so it's typically served from a data warehouse or mart that holds consistent, point-in-time snapshots. Trying to run heavy historical analytics against a live operational system, or to drive an intraday position from a nightly warehouse load, is a mismatch of freshness to plumbing.

---

# Treasury Master Data Management

Source: https://gravam.com/blog/treasury-master-data-management
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: Treasury master data is the static reference data everything depends on — banks, counterparties, instruments, settlement instructions — and ownership is key.

**Treasury master data is the relatively static reference data the whole landscape runs on — house banks and bank accounts, counterparties, financial instruments, currencies, and the standing settlement instructions attached to them — and master data management is the governance of that data: who owns it, how it changes, and [how it stays clean](https://gravam.com/blog/treasury-data-quality-and-governance).** It sits one layer beneath the [treasury data model](https://gravam.com/blog/treasury-data-model): the data model is _how the data is structured_, master data management is _who owns and maintains the static data inside it_. This is the least glamorous part of any SAP FI/TRM or treasury landscape I have worked on — and the part where a surprising share of the incidents actually start.

## What treasury master data is

Master data is the stable, descriptive data that transactions refer to rather than the transactions themselves. In a treasury landscape it is a fairly consistent set of domains:

- **House banks and bank accounts** — the banks you hold relationships with and the accounts cash actually moves through.
- **Counterparties and business partners** — the banks and trading partners deals are done with.
- **Financial instruments and product types** — the definitions of the products treasury transacts in.
- **Currencies** — the currency set and the context around it.
- **Standing settlement and payment instructions** — how and where payments to a given party settle: the account, the correspondent, the routing.

None of it changes often. All of it is referenced constantly. That combination — stable but shared by everything — is exactly what makes it dangerous when it is wrong.

## Why it matters: where the quiet errors live

Good master data is invisible. You never notice a correct bank account. Bad master data, by contrast, does not announce itself as a data-quality problem — it announces itself as a _payment incident_. A wrong bank account or a wrong standing settlement instruction does not throw an error; it routes real money, cleanly and successfully, to the wrong place. The payment run works. The reconciliation is what tells you.

> Good master data is invisible. Bad master data is a payment incident.

The same quiet failure mode shows up in exposure. Duplicate counterparty records — the same real-world bank represented twice because two teams onboarded it slightly differently — fragment your view of exposure to that name. You think you are within limit against a counterparty; you are actually over it, split across two records that never aggregate. Nothing looks broken. The number is simply wrong, and it is wrong in a way that is very hard to trace back, because a wrong figure still looks like a figure.

This is the docs-vs-reality gap I keep running into: on paper, master data is a setup task you complete before go-live. In reality it is a live control surface, and it is usually the most under-owned one in the landscape.

## Ownership and the system of record

The governing principle is simple to state and hard to enforce: **each master-data domain needs exactly one owning system and one maintenance path.** Bank accounts are not maintained in the ERP _and_ the TMS _and_ a spreadsheet — they are owned in one place, and everywhere else consumes a copy.

This is the [system-of-record](https://gravam.com/blog/treasury-system-of-record) discipline applied specifically to static data — the free [System-of-Record Map](https://gravam.com/tools/system-of-record-map) is one way to write the owners down. The system of record answers "which number is right?" for balances and positions; master data ownership answers the same question for the reference data those numbers are built on. If a bank account is maintained independently in three systems, you do not have one bank account with three copies — you have three bank accounts that happen to agree today and will drift apart tomorrow. The [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) calls this out as the classic duplication trap, and master data is where the trap is usually sprung.

The rule that keeps it clean: one owner per domain, a directional flow from that owner to every consumer, and no consumer quietly editing its own copy.

## Change control: static data is a fraud vector

Not all changes are equal. Changing a currency description is low-stakes. Changing a beneficiary bank account or a standing settlement instruction is one of the most sensitive actions in the entire landscape, because it silently redirects where money goes — and that makes it a classic fraud vector. The attack is not exotic; it is an approved-looking change to an account number.

So static-data changes to bank accounts and settlement instructions need [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems): four-eyes approval, where the person who enters a change cannot be the person who approves it. This is not bureaucracy for its own sake. It is the specific control that stops a single compromised or careless individual from repointing a payment path. If your master data can be changed by one person with no second check, your payment security has a hole in it regardless of how good the payment approvals themselves are.

## Data quality and lifecycle

Master data is not set-and-forget; it has a lifecycle, and each stage is a control point:

- **Onboarding.** A new bank, counterparty or account enters through a defined path with the right validation and approval — not as an ad-hoc addition someone made to unblock a payment.
- **Periodic review.** Existing records are re-checked on a cycle. Is this account still in use? Is this counterparty still active? Are these settlement instructions still current?
- **Deactivation.** Records that are no longer needed are deactivated deliberately, not left live indefinitely.

The cost of skipping this is stale data: dormant accounts that stay open as an attack surface, counterparties that linger long after the relationship ended, settlement instructions that quietly went out of date. Stale master data is not neutral. Every unused-but-active record is something that can be transacted against by mistake or on purpose.

## Master data gaps that open fraud paths

- **No single owner.** The same account or counterparty maintained in several systems, guaranteed to diverge.
- **Weak change control.** Bank account and settlement-instruction changes made without four-eyes — the fraud vector left open.
- **Duplicate records.** The same real-world entity entered twice, fragmenting exposure and breaking reconciliation.
- **No lifecycle.** Onboarding but no review and no deactivation, so stale data accumulates as risk.
- **Treated as a project task.** Master data owned intensely at go-live and by no one afterward.

Assign one owner per domain, put four-eyes on the changes that move money, and run a real lifecycle from onboarding through deactivation — and master data becomes the dependable foundation it is supposed to be. Skip it, and it stays what it too often is: the quietest, least-owned part of the landscape, and the place your next incident is most likely to begin.

***

_See also [the treasury data model](https://gravam.com/blog/treasury-data-model) and [the treasury system of record](https://gravam.com/blog/treasury-system-of-record)._

## Questions this article answers

**Q: What is treasury master data?**

Treasury master data is the relatively static reference data the treasury landscape depends on — house banks and bank accounts, counterparties or business partners, financial instruments and product types, currencies, and the standing settlement and payment instructions attached to them. It is the stable descriptive data that every transaction refers to, as distinct from the transactional activity itself. Master data management is the governance of that data: who owns it, how it is changed, and how its quality is kept high over time.

**Q: Why does master data ownership matter?**

Because master data is shared by everything, an error in it propagates everywhere and it must have a single owning system and a single maintenance path. When the same bank account or counterparty is maintained in two or three systems, the copies drift, exposures fragment across duplicate records, and no one can say which version is authoritative. Assigning one system of record per master-data domain is what keeps the data consistent and reconcilable rather than a permanent source of divergence.

**Q: How should bank master data be maintained?**

Bank accounts and their standing settlement instructions should be maintained in one owning system through one controlled path, under four-eyes approval. Changing a beneficiary account or a settlement instruction is a classic fraud vector, so those changes need segregation of duties — the person who enters a change cannot be the one who approves it. Combine that with a defined lifecycle of onboarding, periodic review and deactivation so stale or unused accounts do not linger as a risk.

---

# Treasury Integration Patterns: Files, APIs and Middleware

Source: https://gravam.com/blog/treasury-integration-patterns-files-apis-middleware
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: Treasury integration patterns — batch files, APIs and middleware — and their trade-offs, plus why point-to-point connections collapse under their own weight.

**Treasury systems integrate three broad ways — batch files, APIs, and a middleware layer that sits between them — and the real skill is choosing deliberately per flow rather than accreting interfaces by accident.** File-based batch is the traditional backbone; APIs add immediacy where it pays; middleware decouples the whole landscape so it scales. Most treasury estates I've worked in are a hybrid of all three, and whether that hybrid is clean or a swamp comes down to whether someone decided the shape on purpose.

This is the broader-patterns companion to [designing ERP-to-TMS integration](https://gravam.com/blog/designing-erp-tms-integration): that piece is about the flows between two specific systems; this one is about the mechanisms you connect _any_ two systems with, and how they compound across a whole landscape.

## The three patterns

**File-based / batch.** The oldest and still the workhorse. Systems exchange structured files on a schedule — bank statements in as MT940 or camt.053, payments out as pain.001 / ISO 20022, accounting extracts, AP/AR feeds — moved over SFTP or a host-to-host channel. Nothing happens the instant an event occurs; it happens when the job runs. The overnight statement file is still the thing the morning cash position is built on at most companies, and there's a good reason it endures.

**API-based / real-time.** REST calls and webhooks that fetch or push data on demand: a same-day balance, an intraday statement, a payment status that updates as it clears, an instant payment. Instead of waiting for the next batch window, you ask when you need to know, or you get called back when something changes. This is the mechanism behind [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury) and much of what banks now offer alongside their file channels — see [bank connectivity options](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) for how these sit next to SWIFT, host-to-host and EBICS.

**Middleware / integration layer.** An iPaaS, ESB or integration hub that sits _between_ the systems rather than wiring them directly together. It maps one system's format to another's, orchestrates and schedules the flows, retries failures, and gives you a single place to watch every interface. It doesn't do treasury work itself — it makes the connections between the systems that do.

## The trade-offs

Each pattern buys you something and charges you something:

- **Batch is simple, robust and reconciliable — but not real-time.** A file is easy to reason about, easy to rerun, and easy to check with control totals (record counts and amount sums sent vs received). The price is latency: you know what the file knew when it was cut, not what's true now.
- **APIs give immediacy — and add three new problems.** You gain currency and on-demand access. You inherit _availability_ (the endpoint has to be up when you call), _error handling and retries_ (a timeout mid-payment is a different problem from a file that didn't arrive), and _versioning_ (endpoints change, and a silent change to a field can break you weeks later). None of these are dealbreakers; they're just work that a nightly file doesn't ask of you.
- **Middleware costs more up front — and scales far better than a mesh.** Standing up an integration layer is real money and real effort before it carries a single flow. What you're buying is the thing that stops the landscape collapsing as it grows.

> The cadence of an interface is a design decision, not a default. Batch, API or brokered through middleware — choose it per flow, for a reason, and write the reason down.

## The choice that actually shapes the landscape: point-to-point vs hub-and-spoke

The pattern that decides whether a treasury estate stays maintainable isn't files vs APIs — it's **point-to-point vs hub-and-spoke**.

Point-to-point looks harmless at first. Two systems, one connection. Add a bank, add a direct link. Add a payment factory, a market-data feed, a second ERP after an acquisition — each one a fresh direct wire to everything it touches. The connection count doesn't grow linearly; it grows toward _n squared_. I've walked into landscapes with dozens of these — most undocumented, several with no clear owner, a couple that no one dared touch because nobody could say what would break. That's the mesh, and it's how integration quietly becomes the thing everyone's afraid of.

Hub-and-spoke inverts it. Every system connects once, to the middleware. Adding a system is one new spoke, not a new wire to every existing node. The format mapping lives in one place; the monitoring lives in one place; the ownership is clear because the hub _is_ the owner of the connections. That's the whole case for middleware, and it's why the up-front cost is usually worth it past a handful of systems.

## The concerns that cut across all three

Whatever mechanism you choose, the same handful of things separate a stable interface from a fragile one — and they matter for a file, an API and a brokered flow alike:

- **Idempotency and duplicate handling.** A rerun after a failure, or a webhook delivered twice, must not double-post or double-pay. Design every flow so reprocessing is safe.
- **Error handling and retries.** Decide what happens when a flow fails — not if. Retries with sensible limits for transient failures; a clear stop-and-alert for the rest.
- **Reconciliation.** Every interface should carry a way to prove all the data arrived intact. Control totals turn a silent partial failure into a caught exception.
- **Monitoring.** Watch whether each interface _ran and completed_, and alert an owner when it didn't. An unmonitored interface is a wrong number waiting to happen. This earns [its own discipline](https://gravam.com/blog/interface-monitoring-and-reconciliation).
- **Clear ownership.** Every interface has exactly one team that owns it. The orphaned interface — the one nobody remembers building — is where the worst incidents come from.

## The accidental integration hybrid

The architecture diagrams show clean patterns: this flow is batch, that one is an API, everything brokered through the hub. Reality is a hybrid, and that's fine — batch files for bank statements because they're robust and reconciliable, APIs where intraday currency genuinely pays, middleware in the middle so it all holds together. The problem is never the hybrid. The problem is the _accidental_ hybrid — the one where each interface was added the fastest way that worked that day, and five years later no two look alike and no one owns half of them.

The skill isn't picking one pattern and forcing everything through it. It's choosing deliberately, flow by flow, and keeping the count of interfaces something a human can still hold in their head. Decide the shape on purpose, or the landscape decides it for you — badly.

***

_See also [the treasury system of record](https://gravam.com/blog/treasury-system-of-record) for the question that decides which direction an interface runs, and [treasury data lineage](https://gravam.com/blog/treasury-data-lineage) for tracing a number back through the patterns it travelled._

## Questions this article answers

**Q: What are the main treasury integration patterns?**

Three broad ones. File-based/batch — scheduled exchange of structured files (MT940, camt, pain/ISO 20022) over SFTP or host-to-host — is the traditional treasury backbone. API-based/real-time uses REST calls and webhooks for on-demand data and near-real-time status. Middleware (an iPaaS, ESB or integration hub) sits between systems to map formats, orchestrate flows and monitor them centrally. Most real landscapes are a deliberate mix of all three, chosen per flow.

**Q: File-based vs API integration — which is better?**

Neither file-based nor API integration is better in the abstract; it depends on the flow. Batch files are simple, robust and easy to reconcile with control totals, but they are not real-time — you get data on a schedule. APIs give immediacy and on-demand access, but add concerns you don't have with a nightly file: bank/service availability, error handling and retries, and version management as endpoints change. Use batch for high-volume periodic data like statements and end-of-day accounting; use APIs where currency genuinely matters, like a payment status or an urgent balance.

**Q: What does middleware do in a treasury landscape?**

A middleware or integration layer decouples systems so they don't connect directly to each other. It maps formats between systems, orchestrates and schedules flows, and gives one place to monitor and alert on every interface. The alternative — point-to-point connections between every system and bank — works at small scale but multiplies into an unmaintainable mesh as you add endpoints. Middleware costs more up front but turns that mesh into a hub-and-spoke that scales.

---

# Payment Fraud Prevention and Controls in Treasury

Source: https://gravam.com/blog/payment-fraud-prevention-in-treasury
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Payment fraud prevention in treasury: the main threats are BEC, invoice redirection, insider diversion and standing-data tampering — and how to stop them.

**Payment fraud in treasury is stopped not by one clever control but by layers of them — segregation of duties, approval workflows, beneficiary verification, screening, system controls and reconciliation — arranged so that no single failure lets money leave.** A treasury system exists to move funds out of the company, which is exactly why it draws fraud. The threats are mostly unglamorous: a convincing email, a changed bank account, a rushed exception. The defence is defence-in-depth, and the honest lesson from years of running these systems is that the control which fails is almost never the one that was missing — it's the one that got skipped under pressure.

This is general guidance on common, well-established controls, not security advice tailored to a specific organisation. Treat it as a map of the usual layers, then apply your own risk assessment.

## The threats worth designing against

Four recur often enough to design around, and it helps to see them as two pairs.

The first pair attacks _from outside, through people_. **Business email compromise (BEC)** — including CEO-fraud — is a spoofed instruction that impersonates someone trusted: an "urgent and confidential" transfer that appears to come from a senior executive, or a message from a supplier's finance contact. **Invoice redirection** is its close cousin: a genuine invoice for a genuine supplier, but the beneficiary account has been fraudulently changed, so a legitimate-looking payment goes to the fraudster. Neither of these is a hack of your system. They're a hack of your process.

The second pair attacks _the data_. **Internal fraud** is an insider diverting a payment — someone with legitimate access using it to move money where it shouldn't go. **Standing-data tampering** is the quiet one: changing a bank account on a supplier or counterparty record so that entirely normal future payments flow to the wrong place. As I covered in [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems), changing a beneficiary's account number is functionally identical to redirecting a payment — but it usually lives outside the payment approval flow, which is what makes it dangerous. The payment that follows looks perfectly ordinary, because it _is_ ordinary; only the destination is wrong.

The pattern across all four: the most damaging frauds don't look like attacks. They look like business as usual.

## Defence-in-depth: the control layers

No single control catches everything, so you stack them. Each layer assumes the one before it might have been bypassed.

### Segregation of duties and four-eyes

This is the foundation, and I won't repeat the [full case for it here](https://gravam.com/blog/segregation-of-duties-in-treasury-systems). The essentials for fraud prevention: the person who _enters_ a payment is not the person who _releases_ it, and — just as important — a change to a beneficiary account or standing settlement instruction requires independent approval in its own right. If static-data changes aren't four-eyes and audited, you've locked the front door and left the back one open.

### Approval workflows and authorization limits

Payments move through defined states, and the authority required scales with the amount: bigger payments need more approvers, or higher ones. A five-figure payment and a seven-figure payment should not clear the same way. The system must _enforce_ these limits rather than trust people to remember them, and the same discipline applies inside [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury), where automation can otherwise carry a bad instruction all the way to the bank without a human ever pausing on it.

### Beneficiary and bank-account verification

Before you pay a new or changed account, you verify it out-of-band. The classic control is a **callback to a known number** — one you already hold on file, never the number printed on the suspicious email or the changed invoice. Increasingly this is reinforced by **Confirmation of Payee-style checks**, where the account name you intend to pay is matched against the name the receiving bank holds, so a mismatch surfaces before the money moves rather than after. In US ACH, note what the network's own tools do and don't prove: a zero-dollar prenote confirms an account exists, not who owns it, and a return coded R17 with QUESTIONABLE in the addenda is the receiving bank flagging a probable impersonation after the fact — both explained in [the NACHA ACH file format and return codes post](https://gravam.com/blog/nacha-ach-file-format-and-return-codes).

### Sanctions and watchlist screening

Every payment should be screened against sanctions and watchlists before release. This is where clean, structured data earns its keep: [ISO 20022 payment messages](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) carry richly structured party information, which makes screening more accurate and generates fewer of the false positives that train people to click "approve" without looking.

> The control that isn't followed under pressure is the control that fails. Most real losses aren't an exotic breach — they're a rushed exception to a control that was working fine until someone was told it was urgent.

### System controls

Beyond process, the platform itself should be configured to make fraud harder. **Whitelist known beneficiaries** so payments to established accounts are routine and payments to new ones are exceptional and scrutinised. **Restrict who can add or change beneficiaries** to a small, controlled group, and require **out-of-band verification** for those changes. Apply **payment-run controls** so batch runs can't be quietly altered between assembly and release. Each of these narrows the path a fraudulent payment can travel. Where checks are still issued, positive pay extends the same idea to the bank, which pays only the checks you told it about — [positive pay in SAP](https://gravam.com/blog/positive-pay-in-sap) covers the issue file, void handling and the ACH controls sold alongside it. And all of it assumes the channel to the bank is itself trustworthy — the certificates, keys and signing that make an instruction verifiably yours are a control layer of their own, covered in [bank connectivity security](https://gravam.com/blog/bank-connectivity-security).

### Reconciliation and monitoring

The last layer assumes something got through. Prompt reconciliation against bank statements, and monitoring for anomalies — a new beneficiary, an unusual amount, a payment just under an approval threshold — is how you catch what the earlier layers missed, and how you catch it in hours rather than at month-end. A control that only detects fraud after the quarter closes is a control that detects it too late.

## Docs vs reality: where the money actually goes

Here's the part the policy binder tends to underplay. In practice, the large losses I've seen or heard about up close rarely come from an attacker defeating a well-designed control. They come from someone _stepping around_ one that was working perfectly well.

The pattern is almost always the same. A payment is flagged urgent, a senior name is invoked, the callback "can't be done right now because the contact is travelling" — and the exception, this one time, just to unblock things, is granted. The control didn't fail on its own; it was suspended by the same organisation that built it, in the moment it mattered most.

So the practical work of fraud prevention isn't only designing the layers. It's making the layers survive contact with a deadline: no verbal-only overrides, a defined and _logged_ exception path so skipping a callback is itself a visible, approved event rather than a quiet favour, and a culture where "urgent and confidential" is treated as a warning sign rather than a reason to hurry. The strongest control set on paper is worth nothing if pressure can talk it out of the room.

## Pulling it together

Design for the four threats — BEC and invoice redirection, insider diversion, and standing-data tampering — with layers that each assume the last one failed: segregation of duties on payments _and_ on static data, workflows with real authorization limits, out-of-band beneficiary verification, screening before release, platform controls that restrict and whitelist, and reconciliation to catch the remainder. Then do the harder thing and make those layers hold when someone is in a hurry — including when the thing in a hurry is not a person. An agent given a per-transaction ceiling and a goal will meet both, which is why [the limits that actually constrain an AI initiator](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment) are cumulative rather than per item. That combination — defence-in-depth that survives pressure — is why [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) treats controls as a first-class design concern rather than something bolted on afterwards.

***

_See also [segregation of duties in treasury systems](https://gravam.com/blog/segregation-of-duties-in-treasury-systems), [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury) and [pain.008 direct debit initiation](https://gravam.com/blog/pain-008-direct-debit-initiation)._

## Questions this article answers

**Q: What are the main payment fraud risks in treasury?**

Four recur: business email compromise (a spoofed instruction, often posing as a senior executive or a supplier, changing where money goes); invoice redirection (a genuine invoice with a fraudulently altered beneficiary account); internal fraud (an insider diverting a payment); and standing-data tampering (quietly changing a bank account on a supplier or counterparty record so that normal-looking payments flow to the wrong place). The last two matter most because they don't look like an attack — the payment itself appears entirely routine.

**Q: What is business email compromise?**

Business email compromise (BEC) is a fraud where the attacker impersonates a trusted party — a CEO, a supplier's finance contact, or a colleague — usually by email, to trick someone into making or redirecting a payment. Common forms are CEO-fraud (an 'urgent, confidential' payment request that appears to come from a senior executive) and invoice redirection (a message claiming a supplier's bank details have changed). BEC targets people and process rather than technology, which is why the defence is verification, not just email security.

**Q: How do you prevent payment fraud in treasury?**

With layered controls, not a single silver bullet: segregation of duties and four-eyes on both payments and static-data changes; approval workflows with authorization limits; beneficiary and bank-account verification such as callbacks to known numbers and Confirmation of Payee-style name checks; sanctions and watchlist screening before release; system controls like whitelisting known beneficiaries and restricting who can add them; and reconciliation and monitoring to catch anything that got through. The controls only work if they hold under time pressure — most real losses come from an exception, not a gap.

---

# ISO 20022 Migration: Moving from SWIFT MT to MX (CBPR+)

Source: https://gravam.com/blog/iso-20022-migration-mt-to-mx
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-08-02
Reviewed: 2026-08-19
Summary: The industry migration from legacy SWIFT MT messages to ISO 20022 MX for cross-border payments and reporting, and what CBPR+ means for corporate treasury.

**ISO 20022 migration is the industry's move from legacy SWIFT MT messages to ISO 20022 XML — often called MX — for cross-border payments and cash reporting, governed for correspondent banking by the CBPR+ guidelines.** MT is a constrained, fixed-tag format; ISO 20022 carries the same instructions in richly structured XML, with room for fuller party and remittance data. The story is easy to tell in a sentence and hard to deliver in a program, and I've watched more of these projects run long on the mapping than on anything else.

> **Figure — An MT message and its ISO 20022 (MX) equivalent**
>
> On the left, a small sheet labelled MT with three lines, each a tag followed by text that is cut off. An arrow leads to a larger sheet labelled MX with three named fields — Dbtr, Cdtr and RmtInf — each with room for its content. Underneath, tight fields on the left and structured fields on the right.
>
> The same instruction twice — squeezed into fixed tags and tight fields in MT, with a defined field for each piece of data in ISO 20022.

## What is actually changing

For decades the plumbing of cross-border banking ran on SWIFT **MT** messages — the FIN format, with its numbered tags and tight field lengths. An [MT103](https://gravam.com/blog/mt101-vs-mt103-vs-mt202) was a single customer credit transfer; an MT940 was a statement. The format worked, but it was cramped: names and addresses got truncated, references were squeezed into free-text fields, and structured party data simply had nowhere clean to go.

ISO 20022 replaces that with structured XML. Same intent — pay this beneficiary, report this balance — but the data sits in defined fields instead of fixed tags — [here's what those fields look like inside a pain.001](https://gravam.com/blog/pain-001-structure-and-fields) — and there is room to carry it properly. People often call the new messages **MX**, in contrast to the old **MT**. This is the same standard I covered in the [companion piece on pain.001, pain.002 and the camt family](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002): that article is about the corporate-to-bank messages; this one is about the bigger industry migration those messages are part of.

## CBPR+ and the correspondent-banking layer

Here's the distinction that trips people up. A lot of the ISO 20022 migration you read about isn't the message your treasury system sends to your bank — it's the messages banks exchange _between themselves_ to move a cross-border payment through the correspondent network.

That interbank space is where **CBPR+** lives. Cross-Border Payments and Reporting Plus is a set of market-practice guidelines, developed under SWIFT's community, that define how ISO 20022 is used for cross-border payments and reporting between banks on the SWIFT network. The interbank clearing messages — the **pacs** family — are governed here, along with the reporting messages banks use among themselves.

Why do guidelines matter at all? Because a standard is not the same as an agreement. ISO 20022 is flexible enough that two banks could implement it and still not interoperate. CBPR+ exists to pin down the usage — which elements, how they're populated, what's mandatory — so the correspondent chain actually works end to end. It's the same lesson that shows up everywhere in connectivity: the standard gives you capability, the usage guidelines decide whether you get interoperability.

## The coexistence period

The migration didn't happen with a switch. For cross-border payments and reporting, the industry ran a **coexistence period** — MT and ISO 20022 in parallel — which ended on 22 November 2025, giving banks a multi-year window to move rather than a hard cutover for everyone on one date.

> Coexistence was never the destination. It was scaffolding — a way to migrate the network without breaking it. The direction of travel has always been ISO 20022 as the standard.

That date covers CBPR+ — the cross-border payment and reporting traffic over SWIFT, where the MT 1xx, 2xx and 9xx families no longer meet the requirements — not the whole migration: market infrastructures, high-value schemes, securities and individual communities moved on their own timelines, and instant-payment schemes were ISO 20022 native from the start. What matters for planning is the direction: legacy MT for cross-border payments has been retired in favour of ISO 20022, and building as though MT is permanent is building on sand.

## Why it matters to corporates

You might read all of that and think: the interbank layer is the banks' problem, not treasury's. Partly true — you don't send pacs messages. But the migration reaches corporates in concrete ways, and mostly for the better.

- **Richer remittance and party data.** The whole point of the structured format is that references, names and addresses have proper fields instead of a truncated free-text line. Fewer mangled references means fewer payments that arrive but can't be matched.
- **Better straight-through processing and reconciliation.** Structured data flows through systems without a human decoding it. When the remittance information is a field rather than a string, auto-reconciliation actually works — the benefit I keep coming back to across the [bank statement formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), where MT940 is giving way to camt.053.
- **Stronger sanctions and AML screening.** Structured party fields let screening engines look at _the right data in the right place_ rather than pattern-matching free text, which cuts false positives and closes gaps.

And then the practical work. Your bank statements move from MT940 toward **camt**; your payments move from legacy formats toward **pain / ISO 20022 XML**; and in the middle sits the mapping and enrichment — making sure your systems emit the structured data downstream expects and consume the structured data coming back. It's the same connectivity surface I cover in [SWIFT, host-to-host, API and EBICS channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), just with the message contents changing underneath.

## Where MT-to-MX migration time really goes

On paper the migration is a paragraph: MT becomes MX, coexistence ends, everyone's data gets richer. In a program it is never that.

The time goes into three places. First, **data mapping** — deciding how every field in your existing flows lands in the new structure, and where your source systems don't hold structured data cleanly enough to fill it. A pain.001 with rich party data is only as good as the master data behind it. Second, **truncation on legacy hops** — even when you send fully structured ISO 20022, a payment can cross an intermediary still running on MT, and structured data gets flattened or dropped on the way through. The richer data survives only if the whole chain carries it; during coexistence, not all of it did. Third, and heaviest, **testing across every bank channel**. ISO 20022 is a standard, not a guarantee of identical behaviour — banks vary in mandatory fields and in how they handle optional ones, exactly as with [tracking cross-border payments over SWIFT gpi](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments). A message one bank accepts, another rejects until it's mapped to that bank's rules.

I've watched teams budget the migration as a format switch and discover it was a per-bank mapping-and-testing exercise — which is where connectivity projects always run long. Treat it that way from the start: map and test each channel against real scenarios, protect the structured data end to end, and don't let ISO 20022 become MT-era free-text habits wearing an XML costume.

Get it right and you inherit a cleaner, richer, more reconcilable set of flows that will still be the standard in ten years. Treat it as a checkbox and you get XML with none of the benefit and all of the mapping bill.

***

_See also the [companion on ISO 20022 payment messages](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) and [bank connectivity channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics)._

## Primary sources

Cross-border ISO 20022 migration is date- and scheme-specific: the SWIFT CBPR+ coexistence period ended 22 November 2025 for cross-border payments and reporting alike, while market infrastructures, high-value schemes and securities run their own timelines. Verify the current status for your flows against SWIFT's programme documentation.

- SWIFT — ISO 20022 programme timeline — accessed 2026-07-28 — https://www.swift.com/standards/iso-20022/iso-20022-programme/timeline
- SWIFT — ISO 20022 for financial institutions (payment instructions) — accessed 2026-07-28 — https://www.swift.com/standards/iso-20022/iso-20022-financial-institutions-focus-payments-instructions

## Questions this article answers

**Q: What is ISO 20022 migration?**

ISO 20022 migration is the industry-wide move from legacy SWIFT MT (FIN) messages to ISO 20022 XML — often called MX — for payments and cash reporting. MT messages have a constrained, fixed-tag format; ISO 20022 carries the same information in richly structured XML fields, with room for fuller party and remittance data. The migration affects both the messages banks exchange between themselves and the formats corporates use to send payments and receive statements.

**Q: What is CBPR+?**

CBPR+ stands for Cross-Border Payments and Reporting Plus. It is the set of market-practice guidelines that define how ISO 20022 is used for cross-border payments and reporting between banks over the SWIFT network — the correspondent-banking space. CBPR+ exists so that banks implement the standard consistently rather than each interpreting the XML their own way, which is what makes interoperable cross-border ISO 20022 messaging possible.

**Q: What does ISO 20022 mean for corporate treasury?**

For corporates the practical effect is that bank statements move toward camt and payments toward pain/ISO 20022 XML, and the richer structured data improves straight-through processing, reconciliation and sanctions screening — fewer truncated references. The direction of travel is ISO 20022 as the standard, so treasury systems and bank interfaces need to send and consume the new formats correctly, per bank, rather than leaning on legacy MT habits.

---

# Real-Time Treasury: What It Actually Means

Source: https://gravam.com/blog/real-time-treasury
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Real-time treasury is the shift from batch to continuous operations, driven by instant payments and APIs. What changes, and where it genuinely matters vs batch.

**Real-time treasury is the shift from batch, next-day treasury operations to continuous, real-time ones — driven by instant payments, bank APIs and real-time data.** Instead of working from _yesterday's_ closing positions delivered in overnight files, treasury can increasingly see cash in real time, move liquidity instantly, and operate around the clock. It's important to be clear-eyed about it: real-time treasury is a _direction of travel_, not a single product you buy, and not something every process needs. The value is real where timing is tight — and overkill where prior-day data was always fine. This is what it actually means, and where it genuinely matters.

## What it is

Traditional treasury runs on a daily rhythm: [prior-day statements](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) arrive overnight, you build the [position](https://gravam.com/blog/how-to-build-a-daily-cash-position) in the morning, payments go in batches. Real-time treasury compresses that rhythm toward _continuous_: data that updates through the day, payments that settle in seconds, liquidity that moves on demand. The batch day gives way to a live picture.

## What's driving it

- **Instant payment schemes** — real-time settlement in seconds, 24/7, rather than days.
- **Bank APIs** — data and payment initiation [on demand](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), rather than in overnight files.
- **Real-time data demand** — a broader business expectation of current, not day-old, information.

Together these turn "see and move money once a day" into "see and move money continuously."

## What actually changes

> The core shift is from _yesterday's numbers this morning_ to _this moment's numbers now_ — and from _money moves overnight_ to _money moves in seconds, any time_. Everything else follows from those two.

- **Visibility:** from prior-day positions to [intraday and real-time](https://gravam.com/blog/how-to-build-a-daily-cash-position) cash views.
- **Payments:** from batch, business-hours settlement to instant, 24/7.
- **Liquidity:** from once-a-day sweeps to on-demand, intraday movement.
- **Operations:** from a defined daily cycle to a potentially always-on one.

## The opportunities

Real-time capability lets treasury use liquidity better (less idle cash, funding exactly when needed), make faster decisions on current data, respond to events immediately, and automate flows that once waited for the next batch. Where cash timing is tight or customer payments must be instant, that's a genuine step-change.

## The challenges — this is the honest part

Real-time isn't free, and the difficulties are real:

- **No overnight window.** Batch treasury relies on a quiet overnight period to process and reconcile. 24/7 operation removes it — systems and processes must cope continuously.
- **Real-time controls.** Fraud checks and [approvals](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) must happen _in the moment_, because an instant payment can't be recalled. Controls have to keep pace with speed.
- **Intraday liquidity management.** Moving money in real time means managing liquidity in real time — a harder discipline than a daily sweep.
- **Systems must keep up.** Real-time is only as real-time as your slowest system; a live bank feed into a batch-only TMS isn't real-time treasury.

## What it means practically

In practice, real-time treasury shows up as: [API connectivity](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) alongside file-based feeds; an intraday cash position that updates through the day; real-time or near-real-time [reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation); and payment [tracking](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments) and instant settlement where it matters. It's less a big-bang transformation than a gradual addition of real-time capability where it earns its place.

## Real-time ambitions that outrun the back office

- **Hype over need.** Pursuing real-time everywhere because it's the trend, when prior-day data served perfectly well and cost far less.
- **Controls left behind.** Adopting instant payments without upgrading fraud and approval controls to match — an irreversible-payment risk.
- **A real-time front on a batch back.** A live feed into systems and processes that still work in daily cycles, so nothing is actually real-time.
- **Ignoring intraday liquidity.** Enabling instant movement without the discipline of [managing liquidity through the day](https://gravam.com/blog/intraday-liquidity-management) — cut-offs, payment queues, intraday credit — to go with it.

Adopt real-time treasury where timing genuinely matters — same-day funding, instant payments, intraday liquidity, fraud response — and keep batch where batch works. Done that way, real-time is a powerful extension of [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury); done as an everything-must-be-instant fashion, it's cost and risk for little gain. The skill, as ever, is matching the capability to the need.

***

_See also [bank connectivity options](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) and [building a daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position)._

## Primary sources

- ECB — Instant payments (SCT Inst: funds available within ten seconds, 24/365) — accessed 2026-07-29 — https://www.ecb.europa.eu/paym/retail/instant_payments/html/index.en.html
- ECB — TARGET Instant Payment Settlement (TIPS) — accessed 2026-07-29 — https://www.ecb.europa.eu/paym/target/tips/html/index.en.html
- Swift — Corporates (single channel, Instant Cash Reporting API) — accessed 2026-07-29 — https://www.swift.com/corporates

## Questions this article answers

**Q: What is real-time treasury?**

Real-time treasury is the shift from batch, next-day treasury operations to continuous, real-time ones — enabled by instant payment schemes, bank APIs and real-time data. Instead of working from yesterday's closing positions delivered in overnight batches, treasury can see cash in real time, move liquidity instantly, and operate around the clock. It's a direction of travel across the industry rather than a single product, and how far a given treasury goes toward it depends on its needs and its banks' and systems' capabilities.

**Q: What is driving real-time treasury?**

Three things mainly: instant (real-time) payment schemes that settle in seconds rather than days; bank APIs that provide data and initiate payments on demand rather than in overnight files; and a broader business demand for faster, more current information. Together these make it possible to see and move money continuously instead of in daily batches, which is the foundation of real-time treasury.

**Q: Does every treasury need to be real-time?**

No. Real-time capability is genuinely valuable where timing is tight — same-day funding, intraday liquidity management, instant customer payments, fraud response — but for many treasury processes, prior-day data and batch processing are perfectly adequate and simpler. The goal isn't to make everything real-time for its own sake; it's to apply real-time where it materially improves a decision or a customer experience, and keep batch where batch works. Chasing real-time everywhere adds cost and complexity for little gain.

---

# SWIFT gpi: Tracking Cross-Border Payments

Source: https://gravam.com/blog/swift-gpi-tracking-cross-border-payments
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: SWIFT gpi makes cross-border payments faster and trackable end to end, giving each a unique reference (UETR) so you can follow its status. What treasury gets.

**SWIFT gpi (global payments innovation) makes cross-border payments faster and — crucially — trackable end to end, by giving each payment a unique reference (a UETR) that lets you see its status and location as it moves, like tracking a parcel.** It exists to fix a problem every treasurer knew well: international payments used to be slow and utterly opaque. You sent the money and then… waited, blind, unable to say where it was, when it would land, or how much fee would be shaved off along the way. gpi turns that black box into something you can watch — and answers the oldest question in cross-border payments: _where is my money?_

## What it is

SWIFT gpi is a service layered over the correspondent banking network that carries most cross-border payments. Its two headline promises: payments move **faster**, and — the part that changed the game — they're **trackable**. Each gpi payment carries a **UETR** (Unique End-to-end Transaction Reference) that stays with it through every bank in the chain, so its progress can be followed in near real time.

## The problem it solved

> The old cross-border payment was a message in a bottle: you sent it, and found out it arrived only when the beneficiary said so. gpi replaced the bottle with a tracking number.

Before gpi, an international payment hopped across correspondent banks with no visibility. You couldn't see its status, couldn't predict its arrival, and couldn't tell how much each intermediary would deduct. If it went astray, tracing it meant a slow manual investigation, bank by bank. For treasury — trying to fund an account, pay a supplier, or reconcile — that opacity was a real operational problem.

## How it works

- **UETR.** Each payment gets a unique reference at origination, and it travels with the payment the whole way.
- **The tracker.** Every bank in the chain updates the payment's status against that UETR in a shared tracking database.
- **Status visibility.** The sender can see where the payment is, whether it's been credited, and what fees were taken — in near real time.

The UETR is the key idea: [one identifier, end to end](https://gravam.com/blog/payment-references-endtoendid-uetr), that every party updates — turning a chain of disconnected hops into a single traceable journey.

## What treasury gets

- **Payment status visibility.** See where a payment is and when it's credited — no more blind waiting.
- **Confirmation of credit.** Positive confirmation the beneficiary was paid, which helps [reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation) and reduces "did it arrive?" queries.
- **Speed.** Faster settlement of cross-border payments.
- **Fee transparency.** Visibility of the deductions taken along the way.

For a treasury managing [payments](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) and funding across borders, that visibility turns a source of uncertainty and manual chasing into something predictable.

## Where it fits

gpi sits alongside the broader modernization of payments — the move to [ISO 20022](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) and richer, structured payment data. It works over the [connectivity](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) treasury already uses, and its tracking data can feed treasury systems so payment status is visible where the work happens, not just on a bank portal.

## Limits and considerations

gpi is a real improvement, not a magic wand. It still depends on the **banks in the chain supporting it**, its benefits depend on you actually _using_ the tracking data (surfacing it in your systems and processes, not ignoring it), and it's one part of a longer payments-modernization story rather than the whole of it. Treat it as a capability to integrate and use, not a box that ticks itself.

## What to keep in mind

- **Bank support.** Confirm your banks offer gpi and how you access the tracking (via your systems or their channels).
- **Use the data.** The value is in _acting_ on payment status — automating confirmation and reconciliation — not just having it available.
- **It's cross-border-focused.** gpi addresses the correspondent-banking cross-border problem specifically; domestic instant-payment schemes are a separate track.

SWIFT gpi took the least visible, most frustrating part of treasury payments — the cross-border black box — and made it trackable and faster. Used well, it removes a whole category of "where's the money?" uncertainty and manual chasing from the payments process. Like the rest of good [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury), the value isn't the capability itself — it's wiring it into how treasury actually works.

***

_See also [ISO 20022 payments](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) and [bank connectivity options](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics)._

## Primary sources

- SWIFT — gpi (Global Payments Innovation) — accessed 2026-07-28 — https://www.swift.com/products/swift-gpi

## Questions this article answers

**Q: What is SWIFT gpi?**

SWIFT gpi (global payments innovation) is a service that makes cross-border payments faster and trackable end to end. It gives each payment a unique tracking reference (a UETR — Unique End-to-end Transaction Reference) and provides a tracker that shows the payment's status and location as it moves through the chain of banks, much like tracking a parcel. It was introduced to solve the long-standing problem of international payments being slow, opaque, and impossible to trace once sent.

**Q: What problem does SWIFT gpi solve?**

Traditionally, cross-border payments were slow and opaque: once you sent an international payment, you couldn't see where it was, when it would arrive, or how much would be deducted in fees along the way — the classic 'where is my money?' problem. If it didn't arrive, tracing it was a slow, manual investigation across correspondent banks. SWIFT gpi addresses this by making payments trackable in near real time, with visibility of status, timing and fees, and confirmation when the funds are credited to the beneficiary.

**Q: What is a UETR?**

A UETR (Unique End-to-end Transaction Reference) is a unique identifier assigned to a payment that stays with it through the entire chain of banks, from the originator to the beneficiary. It's what makes a payment trackable end to end — every bank in the chain updates the payment's status against the same UETR, so the sender can follow the payment's progress and confirm when it's been credited. It functions like the tracking number on a parcel.

---

# The Treasury Data Model: Core Entities and Reference Data

Source: https://gravam.com/blog/treasury-data-model
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-02
Summary: The treasury data model is the structure of a treasury system's data — the core entities and the reference data they depend on. Why every output rests on it.

**The treasury data model is the structure of the data a treasury system holds — the core entities (deals, positions, cash flows, exposures) and the reference data (counterparties, bank accounts, instruments, currencies) they depend on, and how they all relate.** It's foundational because _everything the system produces derives from it_: every position, valuation, exposure, forecast, [report](https://gravam.com/blog/treasury-reporting-and-analytics-architecture) and control is computed from this underlying data. Get the model coherent and [the reference data clean](https://gravam.com/blog/treasury-data-quality-and-governance), and the outputs are trustworthy; get it messy and every number inherits the flaw — silently, because a wrong figure still looks like a figure. The data model is the quiet foundation the whole [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) rests on.

## What it is

A treasury system isn't really a set of screens — it's a structured body of _data_ with logic on top. The data model is that structure: what entities exist, what each represents, how they connect, and which data is authoritative. Understanding it is understanding what the system fundamentally _is_.

## The core (transactional) entities

The activity of treasury, as data:

- **Deals / transactions** — the trades, loans, deposits and instruments treasury enters into.
- **Cash flows** — the individual payments and receipts a deal generates over its life.
- **Positions** — the aggregated holdings at a point in time (what you hold, in what).
- **Exposures** — the [risk positions](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) derived from deals and holdings.
- **Balances** — cash balances by account and currency.

These are created continuously and flow through the system in volume.

## The reference (master) data

The stable data that transactions _refer to_:

- **Counterparties** — the banks and trading partners deals are done with.
- **Bank accounts** — the accounts cash moves through.
- **Instruments** — the definitions of the financial instruments used.
- **Currencies & calendars** — the currencies, rates context, and business-day calendars.
- **Standing settlement instructions** — how and where payments settle.

Reference data is relatively stable, but _shared by everything_ — so an error in it propagates everywhere.

## Master vs transactional data

> The distinction that keeps a data model clean: **master data** is stable, shared and [carefully governed](https://gravam.com/blog/treasury-master-data-management) (a wrong counterparty or bank account corrupts every transaction that references it); **transactional data** is high-volume activity that references the master. The classic modelling error is storing _derived_ data (a position, a valuation) as if it were master data — positions should be _computed_ from deals and rates, not maintained by hand, or they drift out of line with the reality they're supposed to summarise.

## Why the model matters

Everything the system outputs is _derived_ from this data. A [cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) is computed from balances and flows; a valuation from positions and [market data](https://gravam.com/blog/market-data-in-treasury-systems); an exposure from deals. So the data model's coherence is the ceiling on the trustworthiness of _every_ output. A messy or inconsistent model doesn't announce itself — it just produces subtly wrong numbers that are very hard to trace back to their cause.

## The relationships

The entities aren't independent — they form a chain: a **deal** generates **cash flows** and contributes to **positions**; positions aggregate into **exposures**; flows and balances feed the **cash position**. Understanding those relationships is what lets you see how a single mis-modelled deal ripples out into a wrong exposure and a wrong report. The model is the map of those ripples.

## Reference data quality

Because reference data is shared by everything, its quality is decisive: a wrong bank account, a mis-defined instrument, a duplicated counterparty corrupts every transaction that touches it. Reference data therefore needs _governance_ — controlled maintenance, [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) on changes, and a single authoritative source — exactly the [system-of-record](https://gravam.com/blog/treasury-system-of-record) discipline applied to the data the whole model depends on.

## How treasury data stops reconciling

- **Inconsistent master data.** The same counterparty or account defined differently in different places, so nothing reconciles.
- **No clear model.** Data structured ad hoc, so relationships are unclear and outputs are hard to trust or trace.
- **Derived data stored as master.** Positions or valuations maintained by hand instead of computed, so they drift from reality.
- **Poor reference-data governance.** Uncontrolled changes to shared data, propagating errors everywhere.
- **Duplicate entities.** The same real-world thing represented multiple times, fragmenting the data.

Model the core entities and their relationships coherently, separate master from transactional data, compute derived data rather than storing it by hand, and govern reference data as the shared asset it is — and the treasury data model becomes the dependable foundation every trustworthy output stands on. It's the least visible part of a treasury system and the one everything else quietly depends on.

***

_See also [the treasury system of record](https://gravam.com/blog/treasury-system-of-record) and [the reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._

## Questions this article answers

**Q: What is a treasury data model?**

A treasury data model is the structure of the data a treasury system holds and how it relates — the core transactional entities (deals or transactions, positions, cash flows, exposures, balances) and the reference or master data they depend on (counterparties, bank accounts, financial instruments, currencies, calendars). It defines what each piece of data is, how the pieces connect, and which data is authoritative. Every report, valuation and control in the system derives from it, so a coherent data model is foundational to a treasury system working correctly.

**Q: What is the difference between master data and transactional data in treasury?**

Master (or reference) data is the relatively stable descriptive data that transactions refer to — counterparties, bank accounts, instruments, currencies, standing settlement instructions. Transactional data is the activity itself — deals, payments, positions, cash flows — which is created continuously and references the master data. The distinction matters because master data must be governed carefully (it's shared by everything and errors propagate widely), while transactional data flows through in volume. Confusing the two, or storing derived data as if it were master, corrupts the model.

**Q: Why does the treasury data model matter?**

Because everything the system produces derives from it. Positions, valuations, exposures, cash forecasts, reports and controls are all computed from the underlying data, so if the data model is incoherent or the reference data is wrong, every output inherits the flaw — silently, because a wrong number still looks like a number. A clean, consistent data model with well-governed reference data is what makes the system's outputs trustworthy; a messy one is a source of errors that are very hard to trace back.

---

# What Is the Treasury System of Record?

Source: https://gravam.com/blog/treasury-system-of-record
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-02
Summary: A treasury system of record is the single authoritative source for its data. Designating one, and the TMS-vs-ERP boundary, ends 'which number is right?'

**A system of record is the single authoritative source for a given set of data — the system whose version is treated as definitive when others disagree.** For treasury, it's the system that holds the [master version of deals, cash positions, exposures and bank data](https://gravam.com/blog/treasury-data-model), and it's usually the [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system). Designating _one_ system of record per data domain — and drawing a clean boundary between the TMS and the ERP — is what prevents the most corrosive problem in a finance landscape: two systems showing two numbers, and nobody able to say which is right.

## What a system of record is

In any landscape with more than one system, the same fact often lives in several places — a bank balance in the TMS and the ERP, a deal in the trading system and the accounting system. The system of record is the one designated as **authoritative**: its copy is the truth, and every other copy is a derived view that must reconcile to it. Without that designation, you don't have data — you have several _versions_ of data, and an argument.

## Why treasury needs a clear one

Treasury runs on numbers that must be trusted absolutely — a [cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) you fund against, an exposure you hedge on, a payment you release. If two systems can each claim to hold "the" position, then at the exact moment you need certainty, you have doubt.

> The question "which number is right?" should never require a meeting to answer. A clear system of record makes it a lookup, not a debate.

A single source of truth isn't a nice-to-have architectural ideal — it's the difference between decisions made on facts and decisions made on whichever screen someone happened to open.

## The boundary: TMS vs ERP

The central design question is _who owns what_. A clean, common split:

| Data domain | Typical system of record |
| --- | --- |
| Deals, positions, exposures | TMS |
| Bank statements, connectivity, cash | TMS |
| General ledger, accounting | ERP |
| Vendor/customer master, AP/AR | ERP |

The [TMS and ERP integrate](https://gravam.com/blog/designing-erp-tms-integration), but each should _own_ its domain and _consume_ the other's — not both claim the same data. The TMS is the system of record for treasury; the ERP for the ledger; and the flow between them has a clear direction per domain.

## System of record vs system of engagement

Not every system needs to own data. A **system of engagement** (or reference) _consumes and presents_ data for a particular purpose without owning it — a treasury dashboard, a reporting layer, an analytics tool. These are enormously useful, and they're safe _precisely because_ they don't claim to be authoritative: they're views built on top of the system of record. Trouble starts only when a "view" quietly starts being edited and becomes a second, competing master.

## The two-sources-of-truth problem

The failure this all prevents has a signature: two systems, two numbers, and a recurring reconciliation nobody can close. It usually comes from one of a few causes — the same master data maintained independently in two places, bidirectional sync that lets edits originate on both sides, or a shadow spreadsheet that's become the _real_ source while the official system lags. Each produces the same symptom: no one can say [which figure is authoritative](https://gravam.com/blog/treasury-reporting-and-analytics-architecture), so everyone quietly keeps their own.

## How to define it well

1. **Per data domain, name one owner.** Deals, cash, statements, GL — each gets exactly one system of record. Not "mostly the TMS" — _the_ TMS, for these domains.
2. **Make the flow directional.** For each shared data element, decide which system originates it and which consumes it. Avoid bidirectional master sync.
3. **Treat everything else as a view.** Dashboards and reports read from the record; they don't become alternate masters.
4. **Kill the shadow copies.** Every persistent spreadsheet that's really a source of truth is a system of record you didn't design — find it and fold it in.

## How ownership breaks down

- **[Duplicate masters](https://gravam.com/blog/treasury-master-data-management).** The same data maintained independently in two systems, guaranteed to diverge.
- **Bidirectional sync loops.** Both systems can edit, so "latest wins" races and neither is authoritative.
- **Unclear ownership.** "The TMS and the ERP both kind of own cash," so reconciliation never closes.
- **Shadow spreadsheets.** The number people actually work from lives in a workbook that stopped agreeing with the official system months ago.

Name one system of record per data domain, draw the TMS–ERP boundary explicitly, keep data flow directional, and treat every dashboard as a view rather than a master — and "which number is right?" stops being a question. That single-source-of-truth discipline is the backbone the whole [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) hangs on.

**Map yours:** the free [Treasury System-of-Record Map](https://gravam.com/tools/system-of-record-map) makes you name one owner per data domain — and flags any domain with two owners, a flow written in as the owner, or no owner at all — then exports a table for your architecture doc.

***

_See also the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) and [ERP-TMS integration](https://gravam.com/blog/designing-erp-tms-integration)._

## Questions this article answers

**Q: What is a system of record in treasury?**

A system of record is the single, authoritative source for a given set of data — the system whose version is treated as definitive when systems disagree. In treasury, it's the system that holds the master version of deals, cash positions, exposures and bank data, typically the treasury management system. Designating one system of record per data domain is what lets an organization answer 'which number is right?' with certainty instead of a debate.

**Q: What is the difference between a system of record and a system of engagement?**

A system of record holds the authoritative, master version of data — it's where the truth lives. A system of engagement or reference is a system that consumes and presents that data for a particular use, without owning it. A dashboard or a reporting layer can be a system of engagement built on top of the treasury system of record. The distinction matters because only the system of record's copy is authoritative; everything else is a view.

**Q: Should the TMS or the ERP be the system of record for treasury data?**

Whether the TMS or the ERP is the system of record depends on the data domain, and the key is drawing a clean boundary. Typically the TMS is the system of record for treasury-specific data — deals, positions, exposures, bank statements and connectivity — while the ERP remains the system of record for the general ledger and accounting. Problems arise when both systems claim ownership of the same data and sync bidirectionally, creating two competing versions of the truth. Decide who owns what, once, explicitly.

---

# Straight-Through Processing in Treasury

Source: https://gravam.com/blog/straight-through-processing-in-treasury
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-02
Summary: Straight-through processing (STP) means a transaction flows from initiation to settlement with no manual re-keying. Why every manual touchpoint is a risk.

**Straight-through processing (STP) means a transaction flows end to end — from initiation through confirmation, settlement and accounting — with no manual re-keying or intervention.** In treasury, high STP means a payment or deal is captured _once_ and then flows automatically through every downstream step. It matters because these transactions move real money: every manual touchpoint STP removes is a place where an error can no longer creep in, a delay can no longer form, and a fraud can no longer hide. STP isn't automation for its own sake — it's the systematic removal of the risky, valueless human steps between "we decided to pay" and "it's paid and booked."

## What STP is

Picture a payment's journey: someone initiates it, it's approved, sent to the bank, settled, acknowledged, and posted to the [ledger](https://gravam.com/blog/treasury-system-of-record). STP is the degree to which that whole chain happens _without anyone re-entering the data_. Full STP: entered once, flows all the way through. No STP: a human re-keys it at every boundary — into the banking portal, then into the accounting system, then into a reconciliation sheet.

## Why it matters

Four benefits, all significant, but the last is the real prize:

- **Fewer errors.** Data entered once and reused can't be mistyped at step three.
- **Lower cost.** Manual re-keying is slow, expensive human effort doing what a machine should.
- **More speed.** Automated flows settle and post faster, with less lag.
- **Stronger control.** _This is the one that matters most._ Every hand that touches a payment is a control risk and a [fraud opportunity](https://gravam.com/blog/payment-fraud-prevention-in-treasury). Fewer touchpoints means fewer places for money to be diverted or a mistake to slip through.

> Every manual re-keying step in a payment flow is two things at once: a place for an honest error, and a place for a dishonest one. STP closes both at the same time.

## What breaks STP

STP degrades wherever a human is forced to copy, translate or re-enter:

- **Swivel-chair integration.** Systems that don't talk, bridged by a person reading one screen and typing into another.
- **Format mismatches.** A bank or system that needs data in a shape nothing else produces, so someone translates it by hand. (This is why [standard formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) and [ISO 20022](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) matter for STP.)
- **Exceptions.** Transactions that fall out of the automated path — a failed match, a missing reference — and land in a manual queue.
- **Manual approvals outside workflow.** Approvals done over email or on paper rather than in a system [workflow](https://gravam.com/blog/segregation-of-duties-in-treasury-systems), forcing re-entry to record the decision.

## The building blocks

High STP rests on the same foundations as the rest of good [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury):

- **Integration** — systems connected so data flows, not swivel-chaired.
- **Standard formats** — a common language so no translation step is needed.
- **Matching** — automated reconciliation (confirmations, statements, payment status) so the routine cases clear themselves — [SAP cash application](https://gravam.com/blog/sap-cash-application-ai) shows what that looks like for receivables, rules first and a model for the residue.
- **Workflow** — approvals and controls built _into_ the system, so a control step doesn't become a manual break.

## STP vs exceptions: 100% is a myth

The goal is _high_ STP, not total STP. Some transactions genuinely need human judgement — an unusual deal, a genuine exception, a control that _should_ pause and ask. Chasing 100% automation means either forcing bad automation onto cases that need a person, or removing controls that should exist. The real target is: **automate the routine to near-total, and [handle the exceptions well](https://gravam.com/blog/treasury-exception-management)** — route them fast, to the right person, with context. A good STP design is measured as much by how cleanly it handles the exceptions as by how few there are.

## Measuring it

STP is measurable: the **STP rate** is the proportion of transactions that flow through untouched. Tracking it — by process, by counterparty, by bank — turns "we should automate more" into a specific target and shows where the manual breaks actually are. What you measure, you can improve; an unmeasured STP rate is just a vague aspiration.

## What keeps treasury flows from running straight through

- **Swivel-chair everywhere.** Unintegrated systems bridged by people, accepted as normal.
- **Re-keying across formats.** Manual translation because formats were never standardised.
- **Controls as manual breaks.** Approvals done outside workflow, so every control step breaks the flow and gets re-entered.
- **No measurement.** No STP rate, so no one knows where the manual effort and risk actually concentrate.
- **Chasing 100%.** Over-automating cases that need judgement, or dropping necessary controls to hit a number.

Integrate the systems, standardise the formats, automate the matching, build controls into workflow, and measure the STP rate — and treasury processing shifts from a chain of risky manual hand-offs to a flow that's captured once and trusted end to end. That's not just efficiency; for a function that moves money, it's one of the strongest controls you have.

***

_See also [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation) and [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems)._

## Questions this article answers

**Q: What is straight-through processing (STP) in treasury?**

Straight-through processing means a transaction flows end to end — from initiation through confirmation, settlement, the bank, and accounting — without manual re-keying or intervention. In treasury, high STP means a payment or deal is captured once and then flows automatically through every downstream step. Each manual touchpoint that STP removes is a place where an error, a delay, or a fraud can no longer be introduced.

**Q: Why is straight-through processing important in treasury?**

Because every manual step in a money-moving process is a risk. Re-keying introduces errors, slows things down, and — critically — creates opportunities for fraud and control failures. STP reduces cost (less manual effort), reduces error (data is entered once and reused), speeds settlement, and strengthens control (fewer hands touching a payment). For treasury, where the transactions move real money, raising STP is one of the highest-leverage improvements available.

**Q: What breaks straight-through processing?**

The main culprits are re-keying between systems that aren't integrated (swivel-chair processing), format mismatches that require manual translation, exceptions that fall out of automated flows, and manual approval steps that aren't built into workflow. Anything that forces a human to copy, translate, or re-enter data breaks STP. The goal isn't 100% automation — some exceptions genuinely need judgement — but to remove the manual steps that add risk without adding value.

---

# Segregation of Duties in Treasury Systems

Source: https://gravam.com/blog/segregation-of-duties-in-treasury-systems
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: Treasury moves money, so it's a prime fraud target. Segregation of duties means no one person can initiate, approve and release a payment or trade alone.

**Segregation of duties (SoD) means no single person can initiate, approve and release a payment or trade alone.** The powers are deliberately split, so that fraud or a serious error requires _collusion_ between people rather than the act of one — a far higher bar to clear. In a treasury system, which exists to move money, SoD is not one control among many; it's the foundational one. Combined with approval workflows, [access control](https://gravam.com/blog/access-management-and-user-provisioning-treasury) and [audit trails](https://gravam.com/blog/audit-trails-and-logging-treasury-systems), it's what keeps the system's power to move funds always subject to a second pair of eyes.

## Why treasury specifically

Most systems hold data; a treasury system _moves money out of the company_. It executes payments, releases trades, and settles obligations. That makes it a prime target for both external fraud ([business email compromise, payment redirection](https://gravam.com/blog/payment-fraud-prevention-in-treasury)) and internal fraud — and it makes ordinary errors expensive in a way that a wrong report never is. The whole point of treasury controls is that no individual should be able to move company funds on their own authority.

> A treasury system's defining feature — it moves money — is also its defining risk. Segregation of duties is what stops that feature from being a single point of failure.

## The key separations

Three separations matter most:

- **Initiate vs approve/release.** The person who _creates_ a payment or trade cannot be the one who _approves and releases_ it. This is the classic four-eyes control on outgoing money.
- **Deal vs settle/confirm.** The person who strikes a deal shouldn't also confirm and settle it — otherwise a fictitious or off-market trade can be booked and settled by one hand.
- **Transact vs maintain static data.** The person who processes payments shouldn't also be able to change **master data** — beneficiary bank details, [standing settlement instructions](https://gravam.com/blog/reference-architecture-for-corporate-treasury), approval limits — unchecked.

## Four-eyes approval workflows

SoD is enforced through **approval workflows**: a payment or trade moves through defined states — created, approved, released — each requiring a _different_ user with the right authority, often with limits (larger amounts need higher or additional approvers). The system must _enforce_ this, not rely on people remembering. A workflow that can be bypassed, or where one person holds every role, is SoD on paper only.

## The static-data blind spot

The most under-controlled risk isn't the payment — it's the **bank details behind it**. Changing a beneficiary's account number is functionally identical to redirecting a payment, but it often lives outside the payment approval flow. So a change to **standing settlement instructions or beneficiary bank data must itself be a four-eyes, audited action.** Many real payment frauds are a quiet master-data change, not a fraudulent transaction — the payment then looks perfectly normal. In SAP this separation has to hold at three gates — dual control on bank details, the F110 proposal and run, and the BCM batch release — which the [SAP payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow) walks through object by object.

## Access control

SoD depends on **roles** that actually restrict what each user can do — and on there being _no super-user_ who quietly holds all of them. The same question is now being asked about software that acts on its own initiative: if an AI agent submits a payment run, [whose identity is it acting as](https://gravam.com/blog/agent-identity-and-permissions), and which of these separations does it inherit? Access should be least-privilege (only what the role needs), reviewed periodically (people change jobs; access lingers), and free of the accumulation where someone ends up able to both create and release because two old roles were never removed.

## Audit trail

Every sensitive action — a payment approved, a rate overridden, a bank detail changed — must leave an **immutable record of who did what, when.** The audit trail is both a deterrent and the means of investigation. If a control left no evidence, then as far as the auditor is concerned it never operated.

## How segregation of duties erodes in practice

- **SoD on paper only.** The policy exists but the system doesn't enforce it, or one person holds every role in practice.
- **Super-users.** An admin account that bypasses every separation "for convenience."
- **Unguarded static data.** Payment approvals are locked down, but changing beneficiary bank details isn't — the actual fraud path.
- **Access creep.** Old roles never revoked, so individuals accumulate conflicting powers.
- **Uncontrolled emergency access.** "Break-glass" access used routinely, unlogged, defeating the whole model.

Split initiate from approve, deal from settle, and transacting from maintaining master data; enforce it in workflow, not policy; guard static data as tightly as payments; and make every sensitive action auditable. That's what lets a system move money safely — the entire reason [treasury architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) treats controls as a first-class design concern, not a bolt-on. It is also why the failure mode to watch for in AI oversight is the familiar one: a four-eyes control where the second pair of eyes clicks through is the same defect as [the human oversight the AI Act asks for](https://gravam.com/blog/eu-ai-act-high-risk-requirements-finance-systems) being satisfied on paper and not in anyone's day. When the maker is an agent that also assembles the evidence, that defect stops being a habit and becomes structural — which is the subject of [four-eyes and segregation of duties for AI agents](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents).

***

_See also the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) and [market data in treasury systems](https://gravam.com/blog/market-data-in-treasury-systems)._

## Questions this article answers

**Q: What is segregation of duties in treasury?**

Segregation of duties (SoD) is the control principle that no single person should be able to complete a sensitive end-to-end process alone — most importantly, that the person who initiates a payment or trade cannot also approve and release it. Splitting these powers means fraud or a serious error requires collusion between people rather than the action of one, which is a far higher bar. In treasury, where the system moves real money, SoD is the foundational control.

**Q: Why is segregation of duties critical in treasury systems?**

Because treasury systems execute payments and trades — they move money out of the company — which makes them a prime target for both fraud and costly error. A single person able to create a payment, approve it, and change the beneficiary bank details unchecked can divert funds. SoD, combined with approval workflows and audit trails, ensures no individual has that unchecked power, so the system's ability to move money is always subject to a second pair of eyes.

**Q: What duties should be separated in a treasury system?**

The key separations are: initiating a payment or trade versus approving and releasing it (four-eyes); dealing versus settlement and confirmation; and transacting versus maintaining static/master data such as bank account details and standing settlement instructions. The static-data separation matters as much as the payment one, because changing a beneficiary's bank details is functionally the same as redirecting a payment.

---

# Market Data in Treasury Systems

Source: https://gravam.com/blog/market-data-in-treasury-systems
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: Market data (FX rates, interest curves, prices) is the external reference data treasury needs to value positions. How to source, control and integrate it.

**Market data — FX rates, interest rate curves, benchmark rates and security prices — is the external reference data a treasury system needs to value positions, revalue exposures and price instruments.** Integrating it well means three things: sourcing it reliably, applying the _right_ rate at the _right_ time, and controlling which rate is "official." Get it wrong and the damage is quiet but severe: every valuation, every revaluation, every number that flows to the financial statements inherits the error.

## What market data is

It's the data that comes from _outside_ the company, describing the market rather than your transactions:

- **FX rates:** spot and forward, for translating and valuing foreign-currency positions.
- **Interest rate curves:** used to discount future cash flows and value instruments.
- **Benchmark / reference rates:** SOFR, €STR and the like, for floating-rate instruments (the [LIBOR to SOFR transition](https://gravam.com/blog/interest-rate-benchmark-reform-libor-sofr) covers where they come from).
- **Security and bond prices:** to mark investments to market.
- **Volatilities:** for pricing options and other derivatives.

This is _reference_ data, separate from your own [transaction and position data](https://gravam.com/blog/reference-architecture-for-corporate-treasury), and it needs its own sourcing, validation and control.

## Why treasury needs it

Almost every treasury number depends on market data:

- **Revaluation:** restating foreign-currency exposures and balances at current rates.
- **Mark-to-market:** valuing investments and derivatives using curves and prices.
- **Translation:** converting foreign balances into the reporting currency for the [cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position) and the accounts.
- **Exposure measurement:** sizing positions against limits in a common currency.
- **Hedge accounting:** measuring effectiveness, which is entirely rate-driven.

If the rate is wrong, all of these are wrong. Because they look like normal numbers, no one notices until a reconciliation or an audit does.

## Sources

Market data comes from **data providers** (the major terminals and feeds), **banks** (rates for their own instruments), **exchanges**, and **central banks** (official reference rates). The architectural questions are the same regardless of source: is the feed reliable, is it timely, and, critically, is it _consistent_? Pulling FX from one source and curves from another that use different conventions is how positions stop reconciling.

## The official rate

The most important control in market data is deciding **which rate is authoritative** (the "golden" or official rate) for each purpose and moment.

> The failure mode without this control: finance revalues at the rate they pulled at 4pm, treasury at the rate from 5pm, and the subsidiary at yesterday's, so the "same" position has three values and nothing reconciles. One official rate, one source, one timestamp, applied everywhere, ends that.

For revaluation especially, the month-end official rate must be a single controlled value from a defined source, as of a defined time, used by _everyone_.

## Timing and snapshots

Market data is time-sensitive: a rate is only meaningful with an "as of." Treasury systems typically take **snapshots** (an end-of-day set of rates and curves captured at a defined cut-off) and stamp each valuation with the rate date it used. This is what makes a valuation reproducible: you can always answer "what rate did this number use, and when was it captured?"

## How to integrate it

The pattern mirrors any other [interface](https://gravam.com/blog/interface-monitoring-and-reconciliation):

1. **Feed:** an automated import from the chosen source(s) on a schedule.
2. **Validate:** sanity-check incoming rates (missing points, zero or absurd values, stale timestamps) _before_ they're used. Bad market data must be caught at the door.
3. **Store** with an as-of timestamp, so history is preserved and valuations are reproducible.
4. **Control** the official set — which rates are approved for use, versus raw imports.
5. **Audit:** who changed a rate, and when. Manually overriding a market rate is a sensitive, [controlled](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) action.

## How bad rates reach a valuation

- **Stale rates.** A feed silently stops and yesterday's rates get used as today's; [monitor the feed](https://gravam.com/blog/interface-monitoring-and-reconciliation) like any other.
- **Inconsistent sources.** Different rates or conventions across systems, so positions don't reconcile.
- **No validation.** A garbage rate (a zero, a fat-fingered override) flows straight into a valuation.
- **Manual entry without control.** Rates typed in by hand, unaudited: a fraud and error surface.
- **No official-rate discipline.** Everyone picks their own rate and the same position has several values.

Source it reliably, validate it at the door, control the official set, and stamp every valuation with the rate it used, and market data becomes the dependable backbone of treasury valuation instead of a silent source of wrong numbers. For how this is actually configured — datafeed setup, rate types and the market data buffer — see [market data management in SAP](https://gravam.com/blog/sap-treasury-market-data-management).

***

_See also the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) and [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation)._

## Questions this article answers

**Q: What is market data in a treasury system?**

Market data is the external reference data a treasury system uses to value and price financial positions: FX rates (spot and forward), interest rate curves, benchmark rates, security and bond prices, and volatilities. It's distinct from the company's own transaction data: it comes from outside (providers, banks, exchanges) and drives valuation, revaluation, exposure measurement and hedge accounting.

**Q: Why does treasury need market data?**

Because almost every treasury calculation depends on it. You revalue FX exposures at current rates, mark investments and derivatives to market using curves and prices, translate foreign balances into the reporting currency, and measure exposure against limits. If the market data is wrong, stale, or from an inconsistent source, every one of those numbers is wrong, including the ones that go into the financial statements.

**Q: What is a golden rate or official rate in treasury?**

A golden or official rate is the single, controlled rate a company designates as authoritative for a given purpose and time: for example, the month-end FX rate used to revalue all foreign-currency balances. Controlling which rate is official, from which source and as of what time, ensures every part of the business values the same position identically, rather than picking whichever rate they happened to pull.

---

# Interface Monitoring and Reconciliation for Treasury Systems

Source: https://gravam.com/blog/interface-monitoring-and-reconciliation
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: Treasury interfaces fail silently and partially. Monitoring proves each ran; reconciliation proves the data arrived intact. How to design both from the start.

**Interface monitoring proves each interface _ran and completed_; interface reconciliation proves _all the data arrived intact_. Treasury interfaces need both, because they fail silently and partially — and a feed that quietly doesn't run, or transfers only part of its data, surfaces as a wrong cash position or a missed payment days later.** The interfaces that cause the worst damage aren't the ones that fail loudly; they're the ones that fail quietly. Monitoring and reconciliation are how you make silent failure impossible.

## Why interfaces fail silently

A treasury landscape is a [web of feeds](https://gravam.com/blog/treasury-integration-patterns-files-apis-middleware): the [ERP to the TMS](https://gravam.com/blog/designing-erp-tms-integration), bank statements in, payments out, market data. Each is a point where something can go wrong — a job doesn't run, a file is late or malformed, [a downstream system is down](https://gravam.com/blog/disaster-recovery-business-continuity-treasury), a feed transfers 998 of 1,000 records. None of these announces itself. The system doesn't crash; it just has slightly wrong or missing data. And because a cash position built from a partial statement _looks_ like a cash position, the failure is invisible until someone can't reconcile it or a payment doesn't land.

## Monitoring: did it run and complete?

The first question is existence. For every interface, you need to know it **ran when it should, and completed successfully** — and to be alerted when it didn't. That means:

- A schedule or expectation for each feed (this runs at this time / before this event).
- Detection of a run that's missing, late, or ended in error.
- An **alert to a named owner** — not a log entry someone might read.

Monitoring catches the "the feed didn't run" and "the feed errored" cases. But a feed can run _successfully_ and still be wrong — which is where reconciliation comes in.

## Reconciliation: did the data arrive intact?

The second question is completeness and integrity. The tool is **control totals**: the source records how many items and what total amount it sent; the target records how many it received and processed; you compare them, every run.

> Source sent **1,000** AP items totalling **€10,000,000**. Target booked **1,000** totalling **€10,000,000**. ✓ balanced.
> Target booked **998** totalling **€9,900,000**. ✗ break — investigate before trusting the position.

Counts catch missing records; amount sums catch corrupted or altered values. Together they turn a silent partial failure into a caught, investigable exception — one that lands in a proper [exception-management queue](https://gravam.com/blog/treasury-exception-management) with an owner and a clock, rather than in someone's inbox — in SAP, the statement-side version of that queue is [FEBAN post-processing](https://gravam.com/blog/feban-bank-statement-post-processing).

> Monitoring without reconciliation gives false comfort: the dashboard is green because the feed _ran_, while it quietly moved the wrong data. Reconciliation without monitoring misses the feed that never ran at all. You need both, on every interface that matters.

## Alerting and ownership

Detection is worthless if no one acts. Every monitored interface and every reconciliation break needs a **named owner** and an **alert that reaches them** — a channel they actually watch, with enough context to act. A break that lands in an unread log is the same as no monitoring at all. This is as much an operating-model decision as a technical one.

## Statement and payment reconciliation specifically

Two flows deserve particular rigour:

- **Bank statements in.** Confirm you received a statement from _every_ account for the day, and that opening/closing balances are internally consistent (in [MT940](https://gravam.com/blog/mt940-format-tags-explained), the `:60a:` opening balance plus the `:61:` lines must equal the `:62a:` closing balance). A missing statement means a wrong position.
- **Payments out.** Reconcile what you _instructed_ (pain.001) against the acknowledgements and status ([pain.002](https://gravam.com/blog/pain-002-status-and-reject-codes)) — so you know each payment was accepted and settled, not silently rejected.

## Build it in, don't bolt it on

The cheapest time to add monitoring and reconciliation is when you design the interface; the most expensive is after a wrong number has already reached the board. Make control totals and run-monitoring part of every interface's specification, alongside the data and format — not a manual check someone remembers to do.

## Why green dashboards miss broken feeds

- **Green-dashboard comfort.** Monitoring that shows feeds ran, with no reconciliation, so partial data passes unnoticed. The identical trap appears one layer up in AI systems, where a dashboard of aggregates cannot answer the only question anyone ever asks — [what happened to this record, on this day](https://gravam.com/blog/production-ai-observability).
- **Alerts no one owns.** Breaks logged but not routed to a person who acts.
- **Manual, after-the-fact reconciliation.** Someone eyeballs it "when there's time," until the one time they don't. Bank reconciliation is the workflow I most often see redesigned — [taken apart end to end here](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation), including which parts must stay deterministic.
- **Skipping statement completeness.** Not checking that a statement arrived from every account, so a missing feed silently understates cash.

Monitor that every interface ran, reconcile that every one moved its data intact, route breaks to an owner who acts — and the silent, partial failures that quietly corrupt a treasury landscape stop happening.

***

_See also [ERP-TMS integration](https://gravam.com/blog/designing-erp-tms-integration) and the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._

## Questions this article answers

**Q: What is interface monitoring in treasury systems?**

Interface monitoring is the discipline of confirming that each interface between systems — ERP to TMS, bank statements in, payments out — actually ran and completed as expected, and alerting an owner when it didn't. It answers 'did the feed run?' Without it, a feed that silently fails to run isn't noticed until a position is wrong or a payment is missed.

**Q: What is the difference between interface monitoring and reconciliation?**

Monitoring answers 'did the interface run and complete?' Reconciliation answers 'did all the data arrive intact?' A feed can run successfully but transfer only part of the data, or transfer it with errors — monitoring alone wouldn't catch that. Reconciliation uses control totals (record counts and amount sums, sent vs received) to prove completeness and integrity. You need both.

**Q: How do you reconcile system interfaces?**

Use control totals: compare the number of records and the sum of amounts sent by the source against what the target received and processed, for every interface run. If a source sends 1,000 items totalling a known amount and the target books fewer or a different total, the reconciliation flags a break to be investigated. Build this into the interface rather than doing it manually after the fact.

---

# Designing ERP-to-TMS Integration

Source: https://gravam.com/blog/designing-erp-tms-integration
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-02
Summary: ERP TMS integration design: what flows each way, batch vs real-time, reconciliation and ownership — so your ERP and treasury system stay in step.

**ERP-to-TMS integration flows reference and AP/AR data from the ERP into the treasury system, and accounting entries (and often payment status) back into the ERP's general ledger — through defined, governed interfaces that follow your system-of-record decisions.** Done well, the two systems stay in step. Done as a [web of ad-hoc extracts](https://gravam.com/blog/treasury-integration-patterns-files-apis-middleware), they drift apart, and you inherit the reconciliation problem that quietly consumes finance-systems teams.

## What flows between ERP and TMS

Design it as deliberate flows in both directions, anchored to the [system-of-record decisions](https://gravam.com/blog/reference-architecture-for-corporate-treasury):

**ERP → TMS**

- Master and reference data — entities, bank accounts, counterparties, cost centres — from wherever they're mastered.
- AP / AR data to feed cash forecasting and, where relevant, payments.

**TMS → ERP**

- Accounting entries treasury generates — cash movements, deals, FX, interest, fees — posted to the general ledger.
- Payment status, where the ERP or a process needs it.

Each field should flow _from its owner_: if the ERP is the system of record for bank master data, it flows to the TMS, not the other way — and never both.

## Interface design principles

- **Interface-based, not point-to-point.** Define interfaces with clear contracts (what data, what format, what cadence) rather than bolting on extracts whenever someone needs data. Ad-hoc extracts become undocumented spaghetti no one can safely change.
- **Follow system-of-record ownership.** The direction of every flow is decided by who owns the data. This prevents the classic duplicate-maintenance and drift problem.
- **Idempotent and recoverable.** A rerun after a failure shouldn't double-post or corrupt data; design for safe reprocessing.
- **Clear cutoffs and timing.** Agree when each flow runs relative to close, payment runs and the working day, so data is complete when the other side needs it.

## Batch vs real-time

Choose per flow, not as a religion:

- **Batch** — scheduled files or jobs — suits high-volume, periodic data: end-of-day accounting, AP/AR extracts, statement imports.
- **Real-time / API** suits data that must be current: a payment status, an urgent balance check, an instant payment — the building blocks of [real-time treasury](https://gravam.com/blog/real-time-treasury).

Most landscapes use batch for the bulk and APIs where immediacy genuinely pays. The cadence matters less than making each flow reliable, monitored and reconciled.

## Reconciliation: every interface must reconcile

The rule that separates a stable integration from a fragile one: **every interface carries a way to prove all the data arrived intact.** Control totals — record counts and amount sums sent vs received — turn a silent partial failure into a caught exception. If an ERP sends 1,000 AP items totalling €10m and the TMS books 998 totalling €9.9m, the interface must _flag_ it, not quietly proceed.

> Build reconciliation into the interface from day one, not as a manual afterthought. The interfaces that cause the worst problems aren't the ones that fail loudly — they're the ones that fail _partially and silently_, and the first sign is a position that won't tie out weeks later.

## Error handling and monitoring

Interfaces fail — a feed doesn't run, a file is malformed, a downstream system is down. Design for it: monitor whether each interface _ran and completed_, alert an owner when it doesn't, and make reprocessing safe. (This deserves its own discipline — see [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation).) An unmonitored interface is a wrong number waiting to happen.

## Where ERP-to-TMS interfaces drift

- **Point-to-point spaghetti.** Extracts built ad hoc, undocumented and unmonitored, until the landscape can't be changed safely.
- **No reconciliation.** Interfaces with no control totals, so partial failures surface as unexplained breaks much later.
- **Unclear ownership.** Both systems "own" a data domain, so they drift and you reconcile forever.
- **Timing and cutoff gaps.** A flow runs before its source is complete, so downstream data is subtly wrong.

Design ERP-TMS integration as governed, reconciled interfaces that follow data ownership, and the two systems stay in step. Skip that and the integration becomes the thing everyone's afraid to touch. Start by naming one owner per data domain — the free [System-of-Record Map](https://gravam.com/tools/system-of-record-map) makes you do exactly that, and flags anything that breaks the rule.

***

_See also the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury) and [interface monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation)._

## Questions this article answers

**Q: How does a TMS integrate with an ERP?**

Through defined interfaces in both directions. The ERP typically sends the TMS reference and master data plus AP/AR information for forecasting and payments; the TMS sends accounting entries back to the ERP's general ledger, and often payment status. Good integration is interface-based and governed — following the system-of-record decisions so each field flows from its owner — rather than a web of ad-hoc extracts, and every interface is reconciled.

**Q: What data flows between an ERP and a treasury system?**

Commonly, from ERP to TMS: master and reference data (entities, accounts, counterparties), and AP/AR data to feed cash forecasting and payments. From TMS to ERP: the accounting entries treasury generates (cash, deals, FX, interest) posted to the general ledger, and sometimes payment status. The exact flows depend on your system-of-record design — which system owns each data domain.

**Q: Should ERP-TMS integration be batch or real-time?**

Batch and real-time are both valid ERP-TMS integration patterns; choose per flow. Batch (scheduled file or job) suits high-volume, periodic data like end-of-day accounting or AP/AR extracts. Real-time or API suits data that must be current, such as a payment status or an urgent balance. Many landscapes use batch for the bulk and APIs where immediacy genuinely matters. What matters most is that each flow is reliable, monitored and reconciled, whatever its cadence.

---

# ISO 20022 for Corporates: pain, camt and pacs Messages

Source: https://gravam.com/blog/iso-20022-payments-pain-001-pain-002
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: The ISO 20022 messages a corporate treasury meets — pain.001, pain.002, pain.008, camt.052/053/054, camt.086 and pacs — and which guide covers each.

**ISO 20022 is the global XML standard for financial messaging, and for a corporate treasury it comes down to about a dozen messages in three families: pain, the instructions you send your bank; camt, the statements, reports and bills your bank sends you; and pacs, the messages banks exchange with each other.** This page is the catalogue: what each message is for, who sends it, and which guide on this site opens it field by field. For the file structures themselves, go straight to [pain.001](https://gravam.com/blog/pain-001-structure-and-fields), [pain.002](https://gravam.com/blog/pain-002-status-and-reject-codes), [pain.008](https://gravam.com/blog/pain-008-direct-debit-initiation), [camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942), [camt.053](https://gravam.com/blog/camt-053-structure-and-fields) or [camt.054](https://gravam.com/blog/camt-054-notification-explained). ISO 20022 is [replacing the patchwork of legacy and proprietary formats](https://gravam.com/blog/iso-20022-migration-mt-to-mx), and its structured data is what makes better straight-through processing and reconciliation possible, provided you handle the bank-specific variations.

> **Figure — The three ISO 20022 message families a treasury meets**
>
> You, your bank and other banks. An arrow from you to your bank is labelled pain. An arrow from your bank back to you is labelled camt. A two-way arrow between your bank and other banks is labelled pacs. A key reads pain, you instruct; camt, bank reports; pacs, bank to bank.
>
> pain goes from you to your bank, camt comes back, and pacs travels between banks — a corporate never sends one.

## What ISO 20022 is

ISO 20022 is not a single message; it's a **standard**: a common, structured XML language for financial messages across payments, cash management, securities and more. Its value over older formats is **structure**: information sits in defined fields rather than free text, so it's richer, cleaner and easier for systems to process automatically. That's why cross-border payments have moved to it and many market infrastructures are still migrating.

The messages are organized into families. The two a corporate treasury deals with most:

- **pain:** _Payments Initiation_ (customer-to-bank): instructing and tracking payments.
- **camt:** _Cash Management_: statements and reports (covered in [statement formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), field by field in the [camt.053 walkthrough](https://gravam.com/blog/camt-053-structure-and-fields)).

(You'll also hear **pacs**, the bank-to-bank clearing messages — [the successors of MT103 and MT202](https://gravam.com/blog/mt101-vs-mt103-vs-mt202) — but those are between banks, not something a corporate sends.)

## The message catalogue

The number tells you which message; the family prefix tells you who is talking to whom. Here are the ones a treasury actually meets, what each carries, and where this site opens it up:

| Message | Direction | What it carries | Guide on this site |
| --- | --- | --- | --- |
| `pain.001` CustomerCreditTransferInitiation | Corporate → bank | Credit-transfer instructions: debtor account, beneficiaries, amounts, requested execution dates | [pain.001 structure and fields](https://gravam.com/blog/pain-001-structure-and-fields) |
| `pain.002` CustomerPaymentStatusReport | Bank → corporate | The status of a pain.001 or pain.008 the bank received — accepted, rejected with reason codes, pending | [pain.002 status and reject codes](https://gravam.com/blog/pain-002-status-and-reject-codes) |
| `pain.008` CustomerDirectDebitInitiation | Corporate → bank | Direct-debit collections: mandate details, sequence types, collection dates | [pain.008 direct debit initiation](https://gravam.com/blog/pain-008-direct-debit-initiation) |
| `camt.052` BankToCustomerAccountReport | Bank → corporate | The intraday account report — movements so far today, ahead of the closing statement | [camt.052 vs MT942, field by field](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) |
| `camt.053` BankToCustomerStatement | Bank → corporate | The end-of-day statement: typed balances and the entries booked in the period | [camt.053 field by field](https://gravam.com/blog/camt-053-structure-and-fields) |
| `camt.054` BankToCustomerDebitCreditNotification | Bank → corporate | Event-driven debit and credit notifications, and the itemised breakdown of a batch booking | [camt.054 notification explained](https://gravam.com/blog/camt-054-notification-explained) |
| `camt.086` BankServicesBillingStatement | Bank → corporate | The periodic bank fee statement: every chargeable service with volume, price, settlement and tax | [bank fee analysis](https://gravam.com/blog/bank-fee-analysis) |
| `pacs.008` FIToFICustomerCreditTransfer | Interbank | The credit transfer itself, moving between the banks that settle it |  |
| `pacs.002` FIToFIPaymentStatusReport | Interbank | The status of a pacs payment message, back to the institution that sent it |  |
| `camt.056` FIToFIPaymentCancellationRequest | Interbank | A request to revoke a payment order not yet settled, or recall one already settled |  |
| `camt.029` ResolutionOfInvestigation | Interbank | The answer to a camt.056 — whether the revocation or recall succeeded |  |

Three things worth reading off it. First, the interbank rows are not yours to send. Once your bank accepts the pain.001, it is the bank that puts a pacs.008 into the clearing, and the pacs.002 that comes back goes to an institution, not to you; what reaches you is the pain.002. That distinction settles a lot of arguments about which message "the payment" is.

Second, the corporate side is two loops, not one. Instruction out and status back (pain.001, pain.002) tells you what the bank did with your file. The camt messages tell you what the account did: camt.052 during the day, camt.053 at the end of it, camt.054 when something specific happened or a batch needs itemising. A treasury that consumes only camt.053 has an end-of-day picture and no intraday one, which is a choice — just make it deliberately.

Third, the cancellation pair is interbank. A corporate asks its bank to attempt a recall; the bank raises the camt.056 and the camt.029 comes back to the bank. ISO 20022 does define a customer-to-bank request for this, camt.055 CustomerPaymentCancellationRequest, but whether your bank accepts it, and how the answer reaches you, is a per-bank arrangement rather than something the standard settles for you.

One thing the table deliberately does not carry is version numbers. Every message here exists in several versions, and the version lives in the XML namespace rather than in the message code — "we're on camt.053" says nothing until someone names the version and the bank's implementation guide alongside it.

## How the pieces fit in a payment flow

Read as a flow rather than a list, the corporate side is short:

1. Your treasury system or [payment factory](https://gravam.com/blog/what-is-a-payment-factory) generates a **pain.001** (or a **pain.008** to collect). What goes where in the file, and where bank guides narrow the schema, is in the [pain.001 structure guide](https://gravam.com/blog/pain-001-structure-and-fields).
2. The bank answers with one or more **pain.002** status reports: accepted, rejected with a reason code, or pending. Decoding those codes is its own [reference](https://gravam.com/blog/pain-002-status-and-reject-codes).
3. The bank executes through the interbank rails in **pacs**; you don't see those messages.
4. The account side comes back in **camt**: intraday in camt.052, end of day in camt.053, event by event or itemised in camt.054, and once a month the fee bill in camt.086.

Each step has its own guide because each has its own failure modes. This page stays the map.

## Why the migration matters

The formats treasury relies on are moving to ISO 20022. [SWIFT's cross-border payment instructions](https://gravam.com/blog/swift-gpi-tracking-cross-border-payments) left legacy MT for ISO 20022 (MX) when [the coexistence period ended on 22 November 2025](https://gravam.com/blog/iso-20022-migration-mt-to-mx), many market infrastructures are still migrating, and instant-payment schemes are ISO 20022 native. For treasury that means two things: your systems and [bank interfaces](https://gravam.com/blog/ebics-european-bank-connectivity) need to **send pain.001 and consume camt** correctly, and you gain **richer data** (better structured references and remittance information), which improves straight-through processing and reconciliation. The upside is real; it just has to be implemented per bank.

## pain.001 and pain.002 pitfalls across banks

- **Assuming ISO 20022 means identical.** Banks implement the standard with variations: different mandatory fields, different handling of optional ones. A pain.001 that one bank accepts may be rejected by another until mapped to its rules. "We support ISO 20022" is a starting point, not a guarantee of interoperability.
- **Ignoring pain.002.** Sending payments (pain.001) without consuming the status report (pain.002), so you don't actually know what happened to them until something breaks.
- **Underestimating mapping and testing.** Treating format adoption as a switch rather than a per-bank mapping-and-testing exercise, exactly where connectivity projects run long.
- **Losing the richer data.** Adopting the XML format but still cramming references into free-text, throwing away the structure that was the whole point.

> Treat ISO 20022 adoption like any bank interface: map and test pain.001 (and pain.002) per bank against real scenarios, and make sure you're using the structured fields, not recreating MT-era free-text habits inside XML. The standard gives you the capability; your implementation decides whether you get the benefit.

Get the payment messages right — pain.001 out, pain.002 back, mapped and tested per bank — and you have a controlled, trackable, reconcilable payment flow. Half-adopt it and you get XML with none of the benefit. That single, instrumented path out to the banks is also the easiest place to see what [a control layer](https://gravam.com/blog/the-enterprise-ai-control-layer) is: one choke point every irreversible action has to pass through, whoever — or whatever — initiated it.

***

_See also [bank statement formats](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) and [bank connectivity channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics)._

## Primary sources

ISO 20022 message definitions and versions evolve; the catalogue table names messages and roles but pins no versions — confirm the versions and profiles your banks require against the ISO 20022 catalogue and each bank's implementation guide. Retitled as a catalogue and re-checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- ISO 20022 — Message definitions catalogue — accessed 2026-07-28 — https://www.iso20022.org/iso-20022-message-definitions
- SWIFT — ISO 20022 for financial institutions — accessed 2026-07-28 — https://www.swift.com/standards/iso-20022/iso-20022-financial-institutions-focus-payments-instructions
- SIX — Swiss Payment Standards, Implementation Guidelines for Credit Transfer (pain.001, with the pain.002 and pain.008 message flow) — accessed 2026-09-02 — https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2026-en.pdf
- SIX — Swiss Payment Standards, Implementation Guidelines for Customer-Bank Messages (Reports): camt.052, camt.053, camt.054 — accessed 2026-09-02 — https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-cash-management-sps-2026-en.pdf
- ECB — TARGET RTGS User Detailed Functional Specifications (scope of pacs.008, pacs.002, camt.056, camt.029) — accessed 2026-09-02 — https://www.ecb.europa.eu/paym/target/t2/prouse/shared/pdf/rtgs-udfs-r2026-JUN-revised.pdf
- ECB — TIPS User Detailed Functional Specifications (FIToFICustomerCreditTransfer and FIToFIPaymentStatusReport message names) — accessed 2026-09-02 — https://www.ecb.europa.eu/paym/target/target-professional-use-documents-links/tips/shared/pdf/TIPS_UDFS_v2.0.0_190614_rev.pdf
- ISO 20022 — Message Definition Report Part 2, Bank Services Billing, Maintenance 2018–2019 (camt.086.001.03 BankServicesBillingStatementV03) — copy distributed in the moov-io/iso20022 repository — accessed 2026-09-25 — https://github.com/moov-io/iso20022/blob/v0.2.1/docs/specifications/bank_services_billing_3/ISO20022_MDRPart2_BankServicesBilling_2018_2019_v1.pdf

## Questions this article answers

**Q: Which ISO 20022 messages does a corporate treasury use?**

Mostly two families. From the pain family, which the corporate sends to its bank: pain.001 for credit transfers, pain.008 for direct debits, and pain.002 coming back with the status of both. From the camt family, which the bank sends to the corporate: camt.052 intraday account reports, camt.053 end-of-day statements, camt.054 debit and credit notifications, and camt.086 for bank fee billing. The pacs messages such as pacs.008 and pacs.002 travel between banks and are not something a corporate normally sends or receives.

**Q: What is the difference between pain, camt and pacs messages?**

The family prefix says who is talking to whom. pain, Payments Initiation, is customer to bank: the payment and direct-debit instructions and their status reports. camt, Cash Management, carries statements, reports, notifications and bank fee billing, plus some investigation messages. pacs, Payments Clearing and Settlement, is bank to bank: the credit transfer between the institutions that settle it and its status. A corporate lives in pain and camt; pacs is what its bank does with the instruction.

**Q: What is ISO 20022 in simple terms?**

ISO 20022 is a global standard for financial messages built on structured XML. Instead of many proprietary and legacy formats, it provides a common, richly structured language for payments (the pain and pacs families), cash management and statements (camt), and more. Its structured data carries more information more cleanly than older formats, which is why the industry is migrating to it.

**Q: Why is the ISO 20022 migration important for treasury?**

Because the formats treasury depends on (payment initiation and bank statements) are moving to ISO 20022, and the richer, structured data improves straight-through processing and reconciliation. SWIFT cross-border payment instructions left legacy MT for ISO 20022 when the coexistence period ended on 22 November 2025, and many market infrastructures are still migrating, so treasuries need their systems and bank interfaces to send pain.001 and consume camt correctly, allowing for bank-specific variations.

---

# Bank Statement Formats: MT940 vs camt.053 vs BAI2

Source: https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: MT940, camt.053 and BAI2 are the main bank statement formats treasury imports: legacy SWIFT, modern ISO 20022, a US format. How they differ and which to use.

**MT940, camt.053 and BAI2 are the main formats a bank statement arrives in, and a treasury system has to import whatever its banks send.** MT940 is the legacy SWIFT flat-file standard — compact and everywhere, but limited in structure. camt.053 is the modern ISO 20022 XML statement — richer and more structured, the direction the industry is moving. BAI2 is a flat-file format used mainly in the US. The format matters because it determines how much a system can _automatically_ reconcile versus how much a human has to touch.

> **Figure — One bank statement in three formats**
>
> Three sheets side by side. MT940 is lines that begin with tags such as :20:, :61: and :86:. camt.053 is XML, each entry inside an Ntry element. BAI2 is comma-separated records that begin with a record code such as 03, 16 and 49.
>
> The same end-of-day statement in three shapes — SWIFT's tagged lines, ISO 20022 XML, and the comma-separated records used mainly in the US.

## What these formats are

All three are **end-of-day bank statements** — the file a bank sends reporting the prior day's opening and closing balances and every transaction. Your treasury system imports it to build the cash position and reconcile. (There are intraday cousins too — more below.) Remember the distinction from the [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics): the format is _what the file says_; the channel is _how it travels_.

## MT940

MT940 is the SWIFT **Customer Statement Message** — a flat file of tagged fields (account, opening/closing balances, and a line per transaction; [tag by tag here](https://gravam.com/blog/mt940-format-tags-explained)). Its payment-side cousins are [a separate comparison](https://gravam.com/blog/mt101-vs-mt103-vs-mt202). It's compact, mature and extremely widely supported, which is why it's still the workhorse in many landscapes. Its weakness is **structure**: transaction detail is often packed into free-text fields, so richer information (remittance data, structured references) can be lost or hard to parse, which limits automatic matching. Its intraday sibling is **MT942** (interim transaction report).

## camt.053

camt.053 is the ISO 20022 **Bank-to-Customer Statement** — an **XML** end-of-day statement with a defined, structured schema. Because the data is structured rather than free-text, it can carry richer, cleaner information — better structured references and remittance detail — which supports **higher automatic reconciliation rates**. It's the direction of travel as [the industry migrates to ISO 20022](https://gravam.com/blog/iso-20022-migration-mt-to-mx). Its relatives: **camt.052** (intraday report) and **[camt.054](https://gravam.com/blog/camt-054-notification-explained)** (debit/credit notification). For what's actually inside the file — balances, entries, the Bank Transaction Code — see the [camt.053 field-level walkthrough](https://gravam.com/blog/camt-053-structure-and-fields).

> "We use camt.053" is not the whole story. Banks implement the ISO 20022 schema with variations — different usage of optional fields, different ways of populating references. So camt.053 from Bank A and Bank B may not be identical, and each still needs mapping and testing. The standard reduces variation; it doesn't eliminate it.

## BAI2

BAI2 is a statement format from the **Bank Administration Institute**, used mainly in the **United States**. Like MT940 it's a structured flat file, reporting balances and transactions with numeric **type codes** that classify each entry ([record by record here](https://gravam.com/blog/bai2-file-format-explained)). If your banks are US-based, BAI2 is common; outside the US, MT940 or camt.053 dominate. Many of the US transactions it reports are ACH payments, whose own file format and return codes are [covered separately](https://gravam.com/blog/nacha-ach-file-format-and-return-codes).

## Comparison

|  | MT940 | camt.053 | BAI2 |
| --- | --- | --- | --- |
| **Type** | SWIFT flat file | ISO 20022 XML | Flat file (US) |
| **Structure** | Limited; free-text detail | Rich, structured schema | Structured, type-coded |
| **Auto-reconciliation** | Moderate | Higher (structured data) | Moderate |
| **Geography** | Global, legacy | Global, growing | Mainly US |
| **Intraday sibling** | [MT942](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) | [camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) | (intraday BAI variants) |
| **Direction of travel** | Being superseded | The target standard | US-specific |

## Why the format matters

It's not a technicality — it decides how much of reconciliation is automatic. Structured data (camt.053) lets the system match statement lines to expected items and open receivables with less human intervention; free-text-heavy formats (MT940) leave more to manual matching or fragile parsing rules. When teams complain that "reconciliation is manual," the statement format and how it's mapped is often part of the cause.

## Which to use, and migration

You largely take what your banks offer, but the strategic direction is **camt.053 / ISO 20022** for its richer data. Treat any move as a **per-bank migration**: confirm each bank's camt variant, map and test it against real statements, and expect to run MT940 and camt.053 in parallel through the transition. Don't assume one bank's camt file behaves like another's.

## Statement format pitfalls, bank by bank

- **Assuming camt is uniform.** Bank-specific variations mean each camt.053 still needs mapping and testing.
- **Losing data in MT940.** Relying on free-text fields for references that then can't be parsed reliably.
- **Format vs channel confusion.** Agreeing a channel (SWIFT, host-to-host) without settling the statement format per bank.
- **No reconciliation testing.** Going live without testing statements against real reconciliation scenarios, then discovering the auto-match rate is poor.

Get the format and its mapping right per bank, favour structured formats where you can, and reconciliation quietly gets easier.

***

_See also [bank connectivity channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), [ISO 20022 payments](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and what the statement is actually used for once it arrives: [the bank-reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation)._

## Primary sources

- Nordea — Account Statement Service MT940 file description — accessed 2026-07-29 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- Nordea — Balance and Transaction Reporting (MT940/MT941/MT942) — accessed 2026-07-29 — https://www.nordea.dk/Images/38-49260/Balance_and_Transaction_Reporting.pdf
- Nordea — Corporate Access MIG camt.053.001.02 (BankToCustomerStatement) — accessed 2026-07-29 — https://www.nordea.com/en/doc/caar-camt-053-001-02-account-statement-standard.pdf
- DZ BANK — camt.053 / camt.052 bank account statement and reporting — accessed 2026-07-29 — https://corporates.dzbank.com/content/firmenkunden/en/homepage/products/transaction-banking/national-international_payments/iso-20022/camt-053-52.html
- Modern Treasury — BAI2 Files — accessed 2026-07-29 — https://www.moderntreasury.com/learn/bai2

## Questions this article answers

**Q: What is the difference between MT940 and camt.053?**

MT940 is the legacy SWIFT flat-file end-of-day statement format — widely used, compact, but with limited structure. camt.053 is the modern ISO 20022 XML end-of-day statement — richer, more structured data that supports better automatic reconciliation. camt.053 is the industry's direction of travel as part of the ISO 20022 migration, but MT940 is still very common, so many treasuries handle both.

**Q: What is BAI2 format?**

BAI2 is a bank statement file format defined by the Bank Administration Institute, used mainly in the United States. Like MT940 it is a structured flat file that reports balances and transactions with type codes. Where your banks are US-based, you'll often receive BAI2; elsewhere MT940 or camt.053 are more common.

**Q: Should we move from MT940 to camt.053?**

Generally the direction of travel is toward camt.053 (ISO 20022), because its richer, structured data improves automatic reconciliation and carries information MT940 can lose. But it's driven by what your banks support and your systems can consume, and there are bank-specific variations in camt files. Plan it as a migration per bank, test thoroughly, and expect to run both formats during the transition.

---

# Treasury Bank Connectivity: SWIFT, Host-to-Host, API, EBICS

Source: https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: SWIFT, host-to-host, API and EBICS — how corporate treasury connects to banks. Host-to-host vs corporate SWIFT compared on reach, cost and who runs it.

**Corporate treasury connects to banks through four main channels — SWIFT, host-to-host, API and EBICS.** SWIFT gives multi-bank reach through one standardized connection; host-to-host is a direct, efficient link to a single bank; APIs bring real-time balances and payment status; and [EBICS is a regional standard](https://gravam.com/blog/ebics-european-bank-connectivity) used mainly in parts of Europe. The comparison most corporates face is host-to-host versus corporate SWIFT: host-to-host is a private file link built bank by bank, corporate SWIFT is one network connection — your own or a service bureau's — that reaches all your banks. There's no single best choice — you pick per bank and per need, and most treasuries run a mix. The important thing is not to confuse the _channel_ (how the message travels) with the _format_ (what it says).

## What bank connectivity does

Whatever the channel, connectivity does two jobs: bring **bank statements in** (so you can build the cash position and reconcile) and send **payment instructions out** (and get their status back). Everything below is a different way to move those two flows.

## SWIFT

SWIFT is the global bank-messaging network. For a corporate, connecting to SWIFT (directly or, often, through a service bureau or a bank's channel) means **one standardized connection that reaches many banks**. That's its strength: instead of a separate integration per bank, you speak one network. The trade-offs are cost and complexity — it's an investment that pays off when you have many bank relationships across regions, and is often overkill for a handful. SAP-centred landscapes have a managed variant of the one-connection idea: [SAP Multi-Bank Connectivity](https://gravam.com/blog/sap-multi-bank-connectivity) runs member-bank, host-to-host, EBICS and Swift connections behind a single connector in the ERP.

## Host-to-host (H2H)

Host-to-host is a **direct, secure file exchange between your systems and one specific bank** — typically automated file transfer (SFTP and similar). It's efficient and reliable for a small number of **strategic, high-volume** relationships: once set up, statements and payment files flow automatically. The catch is that it's **per bank** — every host-to-host link is its own setup, so it scales poorly across many banks.

## Host-to-host vs SWIFT for corporates

This is the comparison most corporates actually face, because it is the choice for the bulk flows — statements in, payment files out. Both carry the same files in the same formats. What differs is the shape of the cost: host-to-host is cheap per connection and multiplies with every bank; SWIFT has a fixed cost up front and adds banks at little extra connection effort.

|  | Host-to-host | SWIFT for corporates |
| --- | --- | --- |
| **What it is** | A private file connection to one bank, built to that bank's specification | One connection to a shared network, reaching every bank you have an agreement with |
| **Reach** | One bank per connection | Many banks through one connection |
| **Who operates it** | You and the bank, each maintaining your end | You (own Swift connection) or a service bureau on your behalf |
| **Fixed cost** | Low — no network membership | Higher — Swift membership, the connection or bureau fees, security obligations |
| **Cost per extra bank** | A new build each time: bank specification, keys, testing | Lower on the connection side; formats and bank onboarding still per bank |
| **Standardization** | Bank-proprietary channel; formats as the bank offers them | Standard channel and messaging services; formats still agreed per bank |
| **Makes sense with** | A few strategic, high-volume banks | Many banks across regions |

### How a corporate connects to SWIFT

"Corporate SWIFT" is not one product; it is a few decisions, and it helps to keep them apart.

- **The corporate-to-bank environment is SCORE.** Swift describes the Standardised Corporate Environment as a closed user group it administers, in which corporates interact with financial institutions. It offers three transfer mechanisms — FIN, FileAct real-time and FileAct store-and-forward — and a corporate subscribes to the ones its banks support. In treasury terms: FIN carries individual messages such as [MT940 statements](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), and FileAct carries files, which is how ISO 20022 statements and bulk payment files usually travel. For a corporate that loses its SCORE eligibility, Swift names a member-administered closed user group (MA-CUG) — one run by an individual bank — as the alternative.
- **The connection is either yours or shared.** A corporate can connect directly, or use what Swift calls indirect or shared connectivity through a service bureau — a third party that runs the Swift infrastructure for several customers. Swift's Shared Infrastructure Programme sets the legal, financial and operational requirements those bureaux must meet, and Swift inspects against them; the bureau remains responsible for its own service.
- **Alliance Lite2 is no longer the entry route.** For years a common answer for a corporate wanting its own low-footprint connection was Alliance Lite2. Swift now states that Alliance Lite2 is available to existing clients only and points new customers to Alliance Cloud. If a proposal or an older article recommends Lite2 for a new connection, check it against Swift's current page.

What I can't give you from a primary source is a price or a bank-count threshold: Swift does not publish one on these pages, and bureau pricing is commercial. The rest of this section is general practice, not Swift's statement.

### How many banks before SWIFT makes sense

There is no official number. The reasoning is arithmetic: every host-to-host connection is a separate build and a separate thing to maintain — its own specification, its own keys and certificates to renew, its own testing whenever either side changes — so the effort grows in a straight line with the number of banks. SWIFT's cost is mostly fixed and shared across them.

- **A handful of banks carrying most of the volume:** host-to-host to each is usually simpler and cheaper, and nothing is gained by joining a network to reach them.
- **A growing or scattered bank landscape:** the point arrives where maintaining one more private connection costs more than adding one more bank to a network connection you already run. That is when SWIFT, directly or through a service bureau, earns its fixed cost.
- **Both at once** is common and reasonable: host-to-host to the two or three core banks, SWIFT for the long tail. Before building either for a bank with one small account, ask whether the account should exist — [rationalizing accounts](https://gravam.com/blog/bank-account-rationalization) removes connections that never have to be built.

One caveat applies to both: neither removes per-bank onboarding. SWIFT standardizes the channel, not the content, so each bank still has its own format variant, its own agreement and its own test cycle — which is why a [payment hub](https://gravam.com/blog/payment-hub-vs-payment-factory) or a TMS still sits between the ERP and either channel, and why every link needs [monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation) whichever route it takes.

## API

Bank APIs bring **real-time, request-response connectivity** — fetch a balance now, submit a payment and get its status immediately, rather than waiting for a batch file. They're the modern direction of travel and shine where **immediacy** matters: [intraday positioning](https://gravam.com/blog/real-time-treasury), instant payments, real-time status. Maturity and coverage still vary by bank, and like host-to-host, they're **bank-by-bank**, so breadth takes effort.

## EBICS

EBICS (Electronic Banking Internet Communication Standard) is a **bank-connectivity standard used mainly in parts of Europe** (notably Germany, France and neighbours). Where your banks support it, it's a standardized way to exchange statements and payments. Its relevance is largely regional — essential in some European landscapes, not applicable elsewhere.

## Comparison

|  | SWIFT | Host-to-host | API | EBICS |
| --- | --- | --- | --- | --- |
| **Reach** | Many banks, one connection | One bank per link | One bank per API | Banks supporting EBICS |
| **Mode** | Messaging / files | File exchange | Real-time request-response | Files / messaging |
| **Real-time** | Generally batch | Batch | Yes | Generally batch |
| **Best for** | Multi-bank, multi-region | Few high-volume banks | Immediacy: intraday, instant | European landscapes |
| **Effort / cost** | Higher setup; scales across banks | Per-bank setup | Per-bank; maturity varies | Regional standard |

## How to choose

Work from your bank landscape and needs, not a preference for one technology:

- **Many banks, many regions?** SWIFT's single multi-bank connection avoids integrating each bank separately.
- **A few strategic, high-volume banks?** Host-to-host is efficient and robust for those relationships.
- **Need real-time balances or payment status?** APIs, where your banks support them.
- **European banks that use EBICS?** Use it where it applies.
- **Reality:** most treasuries **combine** channels — SWIFT or a bank portal for breadth, host-to-host for a few core banks, APIs where immediacy pays.

## Where connectivity projects get stuck

- **Underestimating onboarding.** Every channel and bank is a setup with agreements, formats and testing; connectivity is [almost always the critical path](https://gravam.com/blog/why-tms-implementations-fail), not the software.
- **One channel for every bank.** Forcing all relationships through a single channel when a mix fits better — SWIFT for reach, H2H for the core few.
- **Confusing channel and format.** Agreeing "we'll use SWIFT" without settling the statement and payment formats ([MT940](https://gravam.com/blog/mt940-format-tags-explained), camt.053, pain.001) — you need both, per bank.
- **No monitoring.** A feed failing silently until a position is wrong or a payment is missed.

Pick channels per bank and need, agree the formats alongside them, start early, and monitor every link — and connectivity stops being the thing that holds go-live. It is also the clearest illustration of why capability is never the hard part: the difficulty lives in the joins between systems that were not designed to talk to each other, which is [equally true of enterprise AI](https://gravam.com/blog/why-enterprise-ai-is-an-architecture-problem). The security layer under all of it — certificates, keys, mTLS, OAuth and SWIFT CSP — is its own discipline: see [bank connectivity security](https://gravam.com/blog/bank-connectivity-security).

***

_See also the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._

## Primary sources

- Swift — Corporates (single channel to all your banks) — accessed 2026-10-04 — https://www.swift.com/corporates
- EBICS — Electronic Banking Internet Communication Standard — accessed 2026-10-04 — https://www.ebics.org/en/home
- Nordea — Account Statement Service MT940 file description — accessed 2026-10-04 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf
- Nordea — Corporate Access MIG camt.053.001.02 (BankToCustomerStatement) — accessed 2026-10-04 — https://www.nordea.com/en/doc/caar-camt-053-001-02-account-statement-standard.pdf
- Swift — SCORE (Standardised Corporate Environment): closed user group, services and eligibility — accessed 2026-10-04 — https://www.swift.com/myswift/ordering/order-products-services/score
- Swift — Shared Infrastructure Programme (service bureaux) — accessed 2026-10-04 — https://www.swift.com/about-us/swift-partner-programme/find-partner/shared-infrastructure-programme
- Swift — Alliance Lite2 (existing clients only; Alliance Cloud) — accessed 2026-10-04 — https://www.swift.com/products/lite-2

## Questions this article answers

**Q: What is the difference between SWIFT, host-to-host and API bank connectivity?**

SWIFT is a shared network that reaches many banks through one standardized connection — good for multi-bank reach, higher in cost and complexity. Host-to-host is a direct, secure file exchange between your systems and one specific bank — efficient for a few high-volume relationships. API connectivity is real-time and modern, bank-by-bank, best where you need instant balances or payment status. EBICS is a standard used mainly in parts of Europe. Most corporates use a mix, chosen by bank and need.

**Q: What is the difference between host-to-host and corporate SWIFT connectivity?**

Host-to-host is a private, direct file connection between a company's systems and one bank, built to that bank's specification and repeated for every bank. Corporate SWIFT connectivity is one connection to the Swift network that reaches every bank the company has an agreement with; corporates exchange FIN messages and FileAct files with banks through SCORE, the closed user group Swift administers for corporate-to-bank traffic. Host-to-host has no network membership and little fixed cost, but its effort multiplies with each bank. SWIFT has a fixed cost — membership, the connection or a service bureau, and security obligations — that is shared across all banks. Host-to-host therefore suits a few high-volume banks, and SWIFT suits a landscape of many banks. Either way, formats and onboarding are still agreed bank by bank.

**Q: Which bank connectivity method is best for corporate treasury?**

The best bank connectivity method depends on your bank landscape. If you deal with many banks across regions, SWIFT's single multi-bank connection is attractive. If you have a few strategic banks with high volumes, host-to-host is efficient. Where real-time balances or instant payment status matter, APIs are the direction of travel. In Europe, EBICS is common. There is no single best answer — most treasuries combine channels.

**Q: Is connectivity the same as file format?**

No — connectivity and file format are different things, and confusing them causes trouble. Connectivity is the channel — how the message travels (SWIFT, host-to-host, API, EBICS). The format is the content — what the message says (MT940 or camt.053 for statements, pain.001 for payments). You choose a channel and a format per bank, and both have to be agreed and tested.

---

# A Reference Architecture for Corporate Treasury

Source: https://gravam.com/blog/reference-architecture-for-corporate-treasury
Topic: Treasury Systems Architecture & Connectivity — https://gravam.com/topics/treasury-systems-architecture
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-18
Summary: How a corporate treasury landscape fits together: ERP, TMS, bank connectivity and market data, joined by defined interfaces, with a system-of-record matrix.

**A corporate treasury reference architecture has four layers — source systems (the ERP), the treasury system (a TMS or ERP treasury module), bank connectivity, and market data — connected by defined interfaces, with a clear system of record for each type of data.** Most of the value, and most of the risk, lives in the connections and the ownership decisions, not in the individual systems. Get the interfaces and the system-of-record boundaries right and the landscape stays clean; get them wrong and you buy years of reconciliation.

## The reference architecture

At a high level, it looks like this:

> **Figure — Corporate treasury reference architecture**
>
> The ERP and market data feed the treasury system, which returns accounting entries to the ERP and exchanges statements and payments with the banks.
>
> Four layers, each with a clear job, joined by governed interfaces — the ERP as source, the treasury system as the core, banks as connectivity, and market data feeding valuation and forecasting.

Four layers, each with a clear job, joined by governed interfaces:

## The four layers

- **Source systems (ERP).** The accounting and operational backbone — the general ledger, accounts payable and receivable, and much of the master data. It is the source of truth for _what happened_ financially.
- **Treasury system (TMS or ERP treasury).** The core treasury engine: cash positioning and forecasting, payments, financial-risk management, debt and investments. It consumes data from the ERP and produces accounting back to it.
- **Bank connectivity.** The channel to the outside world: statements come in (MT940, camt.053, BAI2) and payments go out (pain.001 / ISO 20022) over SWIFT, host-to-host, API or EBICS. Often a bank connector or integration layer sits here.
- **Market data.** FX and interest rates feeding valuation, risk and forecasting.

## System of record: who owns what

The single most consequential architectural decision is assigning a **system of record** to each data domain — one owner, everywhere else a copy. Here's a defensible default; adapt it to your landscape, but decide it explicitly.

| Data domain | Typical system of record | Notes |
| --- | --- | --- |
| General ledger | ERP | Treasury posts _to_ it |
| AP / AR | ERP | Feeds treasury forecasting |
| Bank master data | One owner (ERP _or_ TMS) | The classic duplication trap |
| Cash position | TMS | Built from bank statements |
| Cash forecast | TMS | Fed by ERP AP/AR + treasury |
| Exposures & deals | TMS | Risk lives here |
| Payment status | TMS or payment hub | Decide, don't let both claim it |
| FX / interest rates | Market-data source | Distributed read-only |

> The most common architecture failure isn't a missing system — it's the _absence of this table_. When bank master data or payment status is "owned" by two systems, you get duplicate maintenance, drift and permanent reconciliation. Deciding ownership per domain is cheap; discovering you never did is expensive.

## The interfaces

Design the connections deliberately, not as a web of point-to-point extracts:

- **ERP → TMS:** AP/AR and reference data for forecasting and payments.
- **TMS → ERP:** accounting entries to the GL (and sometimes payment status).
- **TMS ↔ Banks:** statements in, payments out, acknowledgements back — usually the [critical path](https://gravam.com/blog/why-tms-implementations-fail) in any implementation.
- **Market data → TMS:** rates for valuation and forecasting.

Each interface should follow the system-of-record decisions — a field flows _from_ its owner — and be monitored and reconciled, so a broken feed is caught before it becomes a wrong number.

An interface register makes the direction and the ownership explicit — and names what a silent failure of each one actually costs:

| Interface | Flows | Direction follows | What a silent failure costs |
| --- | --- | --- | --- |
| **ERP → TMS** | AP/AR and reference / master data | ERP owns it | Stale reference data → a forecast built on it |
| **TMS → ERP** | Accounting entries (± payment status) | TMS owns treasury postings | A sub-ledger that won't reconcile to the GL |
| **TMS ↔ Banks** | Statements in, payments out, acks back | The bank's formats/channel | The critical path — a missed statement or payment |
| **Market data → TMS** | FX and interest rates | Market-data source | Mis-valuation and a mispriced position |

Keep this register next to the system-of-record table: one says _who owns each field_, the other says _which pipe carries it and what breaks if it's quiet_.

## Environments

Finance systems need a proper environment strategy — typically development, test, and a **pre-production** environment that genuinely mirrors production, then production. The pre-prod discipline matters: in one landscape, pre-production was quietly treated as "another test environment," and teams changed static data in Test and Pre-Prod independently — which produced configuration drift that only surfaced at go-live. Keep environments controlled and their data governed.

## Where treasury architectures rot

- **No system-of-record decision.** Two systems own the same data; reconciliation becomes a permanent job.
- **Point-to-point spaghetti.** Interfaces built ad hoc as extracts, undocumented and unmonitored, until no one can safely change anything.
- **Dirty master data.** Bank accounts, counterparties and mappings maintained inconsistently across systems.
- **Unmonitored interfaces.** A feed fails silently and the first sign is a wrong position or a missed payment.

## Design principles

Keep four principles in view: **one owner per data domain**; **interface-based, governed integration** rather than point-to-point; **master data owned and clean**; and **every interface monitored and reconciled**. Follow them and the architecture is a stable foundation. Skip them and each new system makes the landscape harder, not easier.

**Start with ownership:** the free [Treasury System-of-Record Map](https://gravam.com/tools/system-of-record-map) applies the first principle — one owner per data domain — flags anything that breaks it, and exports a table you can drop straight into your architecture doc.

***

_See also [what a TMS is](https://gravam.com/blog/what-is-a-treasury-management-system), [bank connectivity options](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), and where an AI agent could sit in a landscape like this one: [how AI agents fit into existing enterprise systems](https://gravam.com/blog/how-ai-agents-fit-into-existing-enterprise-systems)._

## Questions this article answers

**Q: What does a corporate treasury systems architecture look like?**

At its simplest, four layers connected by defined interfaces: source systems (the ERP, holding the ledger, AP and AR), the treasury system (a TMS or the ERP's treasury module, handling cash, risk and payments), bank connectivity (the channel to banks for statements and payments), and market data (FX and interest rates). The value and the risk are in the interfaces and in deciding which system is the source of record for each type of data.

**Q: Which system should be the system of record for each treasury data domain?**

One system per domain: the ERP owns the general ledger, the TMS owns the cash position and exposures, and bank master data has one owner rather than being maintained in several places. Defining the system of record for each domain is the most important architectural decision because it prevents duplicate maintenance and reconciliation.

**Q: What data flows between the ERP and the TMS?**

The ERP typically sends AP/AR and reference data to the TMS, and the TMS sends accounting entries (and sometimes payment status) back to the ERP's general ledger — through defined interfaces. The design should be interface-based and governed, not a web of point-to-point extracts, and it should follow the system-of-record decisions so each field flows from its owner.

---

# SAP S/4HANA Cash Forecasting, End to End

Source: https://gravam.com/blog/sap-s4hana-cash-forecasting
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-26
Summary: How SAP S/4HANA cash forecasting works: One Exposure flows, flow types, liquidity items, the forecast apps, SAC liquidity planning, and how to measure accuracy.

**SAP S/4HANA cash forecasting is a view over One Exposure from Operations, not a separate calculation: 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](https://gravam.com/blog/sap-cash-management-s4hana) 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

| Stage | SAP object | The question it answers | Where it usually breaks |
| --- | --- | --- | --- |
| 1. Capture | One Exposure (`FQM_FLOW`), Flow Builder, source apps | _Which flows exist?_ | A source application never activated for a company code |
| 2. Lifecycle | Flow type → certainty level | _Is this forecast or actual?_ | G/L accounts without a flow type, so the flow is invisible |
| 3. Meaning | Liquidity item | _What is the cash for?_ | A growing "unassigned" bucket |
| 4. Short/medium view | Cash Flow Analyzer (F2332), Liquidity Forecast (F0512A) | _What will we hold, and when?_ | Overdue forecast flows no one clears out |
| 5. Long-range plan | SAP Analytics Cloud liquidity planning | _What will we hold next year?_ | Plan and actuals on different category structures |
| 6. Accuracy | Snapshot, SAC versions | _Was the forecast right?_ | Nobody kept the forecast, so there's nothing to compare |

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](https://gravam.com/blog/one-exposure-from-operations-fqm-flow). 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](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting) 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](https://gravam.com/blog/sap-cash-management-s4hana) 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":

| What you want to see | How to get it in the Cash Flow Analyzer |
| --- | --- |
| What really happened (actual cash flow) | Filter on certainty level ACTUAL |
| What is expected from documents and deals | The forecast certainty levels, by liquidity item |
| What was expected but has not arrived | The **overdue** column: forecast flows dated before the key date |
| Where the unconfirmed remainder comes from | Drill into the overdue amount by certainty level and source |

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](https://gravam.com/blog/liquidity-items-in-sap-cash-management) 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](https://gravam.com/blog/13-week-cash-flow-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](https://gravam.com/blog/cash-forecast-operating-model-and-ownership) 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](https://gravam.com/blog/ai-workflow-teardown-cash-forecasting) 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](https://gravam.com/blog/how-to-measure-cash-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:

| Setting or object | What SAP documents |
| --- | --- |
| Where to switch it on | Financial Supply Chain Management → Cash and Liquidity Management → General Settings → **Define Basic Settings** → _Enable snapshot_ |
| Scope | Supported only in full-scope (advanced) cash management; disabled by default, can be activated at any time |
| How it works | Flows are time-segmented in `FQM_FLOW` through the validity fields `VALID_FROM` and `VALID_TO` |
| Where you read it | Cash Flow Analyzer and Check Cash Flow Items let you choose an earlier snapshot time |
| Housekeeping | Program `FQM_DELETE` with deletion type _Snapshot Cleanup_; a job to delete redundant snapshot flows |

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.

## How I would run cash forecasting in S/4HANA

- 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](https://gravam.com/blog/planning-levels-and-groups-in-sap) and [direct vs indirect cash flow forecasting](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting)._

## Primary sources

SAP S/4HANA Cash Management (on-premise and Cloud; snapshot requires full scope with FIN_FSCM_CLM) and the SAP Best Practices liquidity planning content for SAP Analytics Cloud as documented when checked. App IDs, certainty levels, snapshot settings and SAC content were checked on 2026-09-25 through cross-checked excerpts of the listed sources; SAP Help pages could not be opened directly, so verify against your own release and edition before designing.

- SAP Help — Liquidity Forecast (SAP S/4HANA Cash Management) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/60398e5768895b3be10000000a4450e5.html
- SAP Help — Flow Type (One Exposure from Operations; flow level determines certainty level) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/6b02798d81064337abb6bc738914f30c.html
- SAP Help — Classic Cash Management in One Exposure from Operations (certainty levels ACTUAL and CMIDOC) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/5ebf73570a380222e10000000a44147b.html
- SAP Community (SAP) — Features and functions of app Cash Flow Analyzer (F2332) — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/features-amp-functions-of-app-cash-flow-analyzer-f2332-in-s-4hana-cash-and/ba-p/14206107
- SAP Community (SAP) — Snapshot: how it works? — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/snapshot-how-it-works/ba-p/13561749
- SAP Community (SAP) — Generic hints for 'Enable Snapshot' in Cash Management — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/generic-hints-for-enable-snapshot-in-cash-management/ba-p/13482403
- SAP Knowledge Base Article 3288033 — Use of snapshot in SAP S/4HANA Cash Management — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3288033
- SAP Help — Liquidity Planning for SAP S/4HANA Cloud (SAP Best Practices, SAP Analytics Cloud) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_ANALYTICS_CLOUD/42093f14b43c485fbe3adbbe81eff6c8/b834ee07a87042c1a163af1869472dd8.html
- SAP Help — Liquidity Planning with SAP Analytics Cloud (SAP S/4HANA Cloud) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/39e81b8f567d415185768de918b5092d.html
- SAP Help — Manage Financial Plan Data Jobs for SAP Analytics Cloud Integration — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/1cbcff7ccd35405ab445b223c1ab1588/c28c3b25b5af49649756fea55d408773.html
- SAP Help — Integrating SAP Analytics Cloud with SAP S/4HANA Cloud Public Edition — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/1cbcff7ccd35405ab445b223c1ab1588/2f610a5f08cb4142ac188c3e6a127b4e.html

## Questions this article answers

**Q: How does cash forecasting work in SAP S/4HANA?**

Cash forecasting in SAP S/4HANA is a view over One Exposure from Operations, the flow store in table FQM_FLOW. Flow Builder and the source applications write cash-relevant flows into it — open receivables and payables, purchasing and sales documents, treasury deals, loans, memo records and bank statements. Each flow carries a flow type, whose flow level sets its certainty level, and a liquidity item that says what the cash is for. The Cash Flow Analyzer and Liquidity Forecast apps read that store for the short and medium term; SAP Analytics Cloud liquidity planning takes over for the longer range, where the documents that feed One Exposure do not exist yet.

**Q: How does SAP tell actual cash flows from forecast ones?**

By certainty level. Every flow in One Exposure carries one, derived from the flow level attribute of its flow type. Certainty level ACTUAL marks an event that has actually happened, such as a bank-confirmed cash movement, and is what the actual cash flow view in the Cash Flow Analyzer shows. The other certainty levels, predefined by SAP, mark forecast flows of different reliability, for example memo records or treasury transaction flows. Filtering on certainty level is how you separate what happened from what is expected.

**Q: Can you measure cash forecast accuracy in SAP S/4HANA?**

Only if you keep the forecast. One Exposure holds the current state of flows, so last week's forecast for today is not there to compare unless the snapshot function is switched on. Snapshot is available in full-scope cash management, is disabled by default and is enabled in Define Basic Settings. With it, the Cash Flow Analyzer and Check Cash Flow Items apps can show flows as they stood at an earlier timestamp, which you compare with the ACTUAL flows for the same dates, by liquidity item and horizon. For the long-range plan, SAP Analytics Cloud versions such as Forecast and Actual play the same role.

---

# Positive Pay in SAP: Check Issue Files, FCHX and Voids

Source: https://gravam.com/blog/positive-pay-in-sap
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: How positive pay works in SAP: the check register in PAYR, issue files from FCHX, void handling, encashment, and where ACH debit blocks and filters fit.

**Positive pay is a bank service that checks every presented check against the list of checks the company actually issued. In SAP, that list comes from the check register (table PAYR) and is written by the check extract, transaction FCHX (report RFCHKE00) on-premise or the Create Positive Pay Files app in S/4HANA Cloud.** Any presented check that isn't on the list, or doesn't match it on number and amount (and payee name, with payee positive pay), becomes an exception, and the company decides whether the bank pays or returns it. The service is only as good as the issue file, which means only as good as the SAP data and timing behind it, voids included.

This page covers the SAP side end to end: where check data lives, how the extract works, how voids and encashments flow, and how check positive pay relates to the ACH controls US banks sell alongside it. The broader fraud picture is in [payment fraud prevention in treasury](https://gravam.com/blog/payment-fraud-prevention-in-treasury). This page is about making one specific control work.

## How positive pay works at the bank

The bank-side mechanics are common across US banks, though every detail below is set per bank agreement:

- **The issue file.** The company sends the bank its issued checks, at minimum check number, amount and issue date, and with **payee positive pay** also the payee name. Banks accept fixed-length, delimited or spreadsheet uploads, each to their own layout.
- **Matching and exceptions.** Presented checks are matched against the issue file. A check that is not on the file, or doesn't match it, is presented to the company as an exception.
- **The decision and the default.** The company decides pay or return for each exception before a daily cutoff. Anything not decided gets the default decision you chose at enrolment. Return is the protective default. Pay as a default removes most of the protection, because an exception nobody looks at gets paid.

The SAP job is to make sure the issue file is complete, on time and current. A late or incomplete file turns every legitimate check into an exception, the exception list turns into a rubber-stamp exercise, and then the control stops working.

## Where the check data lives: PAYR

Every check SAP creates, whether from the F110 payment run, a manual check or payroll, gets an entry in **PAYR**, the payment medium file table, which serves as the check register. The fields that matter for positive pay:

| Field | Meaning | Role in positive pay |
| --- | --- | --- |
| ZBUKR, HBKID, HKTID | Paying company code, house bank, account ID | Which bank account's issue file the check belongs in |
| RZAWE | Payment method | Separates check payment methods |
| CHECT | Check number | The primary matching key at the bank |
| RWBTR | Amount paid in payment currency | Matched against the presented amount |
| ZNME1 | Payee name (line 1) | Needed for payee positive pay |
| VOIDD, VOIDR, VOIDU | Void date, void reason code, voiding user | Makes a void visible to the extract, and auditable |
| EXTRD, EXTRT | Extract date and time | Written by the extract; drives "only new or changed" logic |
| BANCD | Check encashment date | Set when the bank statement clears the check |

Check lots (FCHI) define the number ranges. The check register (FCHN) displays PAYR, and the Fiori app **Manage Outgoing Checks** (F1578) covers displaying, creating, voiding, cashing and reissuing checks in S/4HANA.

## The extract: FCHX and Create Positive Pay Files

FCHX reads PAYR for the selected company code and house bank accounts, writes the check details to a file, and updates the extract date and time on each check it includes. That stamp is what makes the process incremental. SAP's documentation for the Cloud app describes the selection option that relies on it: include only checks not yet extracted, which covers both new checks and checks that were extracted before but have since changed, for example voided. The same app can create files for checks from Payroll Accounting or from Financial Accounting, which matters when payroll checks run from the same bank account.

Three practical points:

- **The standard layout is rarely the bank's layout.** The classic extract writes a standard header-and-item structure, and banks each specify their own format. S/4HANA Cloud delivers the payment medium format **US_POSIPAY** (a fixed-width text file) and lets you define your own. On-premise, the usual route is a payment medium format built with [DMEE](https://gravam.com/blog/sap-dmee-payment-file-format-tree) rather than a modified extract program.
- **A custom extract must keep the stamp.** If you replace the standard program, it has to write EXTRD and EXTRT back to PAYR. If it doesn't, the "new or changed" logic breaks and the next file either repeats or misses checks.
- **Automate it and deliver it like any bank file.** S/4HANA Cloud has a job template (Creation of Positive Pay Files), and SAP documents an asynchronous outbound service, **Positive Pay File - Send**, for transmission. When the file goes through [SAP Multi-Bank Connectivity](https://gravam.com/blog/sap-multi-bank-connectivity), check the encoding: KBA 3780893 records Cloud positive pay files defaulting to UTF-16 instead of UTF-8 when MBC is selected in the payment method. That is a mismatch many bank parsers will reject.

> Positive pay protects you from the checks you didn't write. It only works if the bank gets every check you did write, and every one you cancelled, before the cutoff.

## Voids: the part that fails quietly

A voided check that the bank doesn't know about is a valid instrument. If it turns up, whether stolen from the mail or deposited twice, the bank has no reason to stop it. So void handling is the core of positive pay, not an edge case.

| Situation | Transaction | Effect |
| --- | --- | --- |
| Issued check lost or damaged, payment stands | FCH9 | Voids the check; payment document unchanged; reissue follows |
| Wrong payee or amount, payment must go | FCH8 | Voids the check and reverses the payment document in one step |
| Blank check stock spoiled or destroyed | FCH3 | Voids unused checks so the numbers are accounted for |
| Fiori equivalent | Manage Outgoing Checks | Void, reissue and cash from one app |

Void reason codes are defined in Customizing for Accounts Receivable and Accounts Payable, and the void writes date, reason and user into PAYR. The design rules that follow:

- **Extract after voiding, before the bank's cutoff.** A same-day void has to be in that day's file. Schedule the extract after the day's check printing and void activity, not before it.
- **Don't delete what the bank needs to see.** FCHE deletes voided checks and FCHD deletes payment-run check information. Both are housekeeping transactions, so restrict them and never run them before the void has been extracted.
- **Checks written outside SAP.** A handwritten emergency check has no PAYR entry, so it will arrive at the bank as an exception. Either record it in SAP as a manual check or accept that someone has to recognise it in the exception list.

## Closing the loop: encashment and the statement

When the bank statement reports a paid check, EBS clears it through the check interpretation algorithms (011, 012, 013, as in the [EBS guide](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms)) and sets the encashment date PAYR-BANCD. Your outstanding-checks list depends on that field. The catch is on the manual path: KBA 3466455 covers the encashment date not being updated when a check is cleared manually in post-processing instead of by the algorithm. Anyone clearing checks in [bank statement post-processing](https://gravam.com/blog/feban-bank-statement-post-processing) needs to know whether their clearing path updates the field, or the outstanding list slowly drifts from the bank's paid file.

## Check positive pay versus ACH controls

US banks usually sell check positive pay together with ACH controls, and the controls get confused because they share a name:

| Control | Protects against | How it decides | Fed from |
| --- | --- | --- | --- |
| Check positive pay | Altered, counterfeit or unissued checks | Presented check vs issue file; exceptions to the company | SAP issue file (FCHX) |
| Payee positive pay | Altered payee name on a genuine check | Adds payee-name matching to the above | SAP issue file with payee |
| ACH debit block | Any ACH debit on the account | Blocks ACH debits unless an exception is allowed | Bank setup |
| ACH debit filter / ACH positive pay | Unauthorised originators | Allows listed originators or company IDs, optionally with amount limits; exceptions for review | Bank setup |

The practical difference for an SAP team: check positive pay is an interface you build and monitor, while ACH blocks and filters are bank-side master data. They don't live in SAP, but they are standing payment data all the same. Changes to the allowed-originator list deserve the same [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) and dual control as changes to a vendor's bank details, because an unauthorised addition to that list works just like a redirected payment.

## What I would put in the control description

The control only works if the operating detail is written down: which accounts are enrolled; the default decision (return); who reviews exceptions and their deputy; the extract schedule relative to check printing and the bank cutoff; a daily reconciliation of the file's check count and total to the register; restricted access to FCHX, FCHE and FCHD; and a monitored transmission, treated as an interface like any other in the [interface monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation) set. None of it is complicated. It fails when one of those pieces is missing.

## What I couldn't verify, and left out

- **Bank liability rules.** How liability for a paid fraudulent check shifts with and without positive pay depends on your bank agreement and the law that applies to it. It is not something to generalise on a systems page.
- **Cutoff times and fees.** They differ by bank. The ones in circulation are specific to one bank's product.
- **Payroll-side positive pay details.** Payroll checks share PAYR and the extract, but payroll check processing has its own transactions that this page doesn't cover.

***

_See also [bank communication management in SAP](https://gravam.com/blog/bank-communication-management-bcm-sap), [SAP payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow) and [BAI2 file format](https://gravam.com/blog/bai2-file-format-explained)._

## Primary sources

SAP ERP 6.0 and SAP S/4HANA on-premise and private edition (FCHX / RFCHKE00, check management transactions, table PAYR) and SAP S/4HANA Cloud Public Edition (Create Positive Pay Files, format US_POSIPAY). Bank-side positive pay terms are US bank practice and vary by bank. Claims were checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- SAP Help — Create Positive Pay Files (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/031c345485b84c8c94265be9ef61d3a8/459238f5840149b1a2ba294e5c94efe2.html
- SAP Help — Positive Pay File - Send (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/7b5bc94d359f4d74843a659b5d35bb36/0e59f3a9d1214f0b94a2af1375cb3d89.html
- SAP Help — Manage Outgoing Checks (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/314007560be38c5be10000000a44147b.html
- SAP Help — Defining Void Reason Codes — accessed 2026-09-25 — https://help.sap.com/doc/26f0d353ca9f4408e10000000a174cb4/700_SFIN20%20006/en-US/70eed353ca9f4408e10000000a174cb4.html
- SAP KBA 3466455 — Check encashment date PAYR-BANCD not updated in post-processing outside FEBAN — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3466455
- SAP KBA 3780893 — Positive pay file encoding defaults to UTF-16 when Multi-Bank Connectivity is selected (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3780893
- SAP Community — Positive pay: an overview — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-members/positive-pay-an-overview/ba-p/13249558
- SAP Datasheet — Table PAYR (Payment Medium File) — accessed 2026-09-25 — https://www.sapdatasheet.org/abap/tabl/payr.html
- Truist — Positive Pay / Payee Positive Pay quick reference guide — accessed 2026-09-25 — https://treasuryresources.truist.com/content/dam/treasuryresources/us/en/documents/fraud-mitigation/daily-resposibilities-for-positive-pay-digital-treasury.pdf
- Johnson Financial Group — Positive Pay FAQs — accessed 2026-09-25 — https://www.johnsonfinancialgroup.com/commercial/treasury-management/positive-pay-faqs/
- Western Alliance Bank — ACH filter and ACH debit block — accessed 2026-09-25 — https://www.westernalliancebancorporation.com/first-independent-bank/commercial-corporate/treasury-management/fraud-protection/ach-filter-ach-debit-block

## Questions this article answers

**Q: How do you create a positive pay file in SAP?**

With transaction FCHX (report RFCHKE00, Check Extract - Creation) in SAP ERP and S/4HANA on-premise, or the Create Positive Pay Files app in SAP S/4HANA Cloud Public Edition. Both read the check register in table PAYR for a paying company code and house bank, write the check details to a file, and stamp the extracted checks with an extract date and time so the next run picks up only new checks and checks that changed since, such as voids. The bank's layout usually differs from SAP's standard output, so most implementations map it through a payment medium format or DMEE.

**Q: What is the SAP table for check register and positive pay?**

PAYR, the payment medium file table, is the check register. It holds one entry per check, identified by paying company code, house bank, account ID, payment method and check number, plus the amount, payee name, void date, void reason and void user, the extract date and time written by the positive pay extract, and the encashment date written when the bank statement clears the check.

**Q: How are voided checks handled in positive pay in SAP?**

A voided check has to reach the bank as a void, or the bank will pay it if it is presented. In SAP you void an issued check with FCH9 when the payment stands, or with FCH8 when the payment document is reversed too; unused checks are voided with FCH3, and the Manage Outgoing Checks app covers voiding in Fiori. The void writes a void date and reason to PAYR, and SAP documents that the next positive pay extract includes checks that were already extracted but have since changed, for example voided.

**Q: What is the difference between check positive pay and ACH debit block?**

Check positive pay protects outgoing checks: the company sends the bank a list of issued checks and the bank refers any presented check that does not match for a pay or return decision. An ACH debit block protects against electronic debits pulled from the account: it stops ACH debits from posting unless an exception is allowed, while an ACH debit filter allows only specified originators or company IDs. Check positive pay is fed from the ERP; ACH blocks and filters are maintained at the bank.

---

# FEBAN: Bank Statement Post-Processing in SAP

Source: https://gravam.com/blog/feban-bank-statement-post-processing
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: Why bank statement items stay open in SAP, how to reprocess them in FEBAN, FEB_BSPROC or the Reprocess Bank Statement Items app, and how to shrink the queue.

**FEBAN is SAP's GUI transaction for bank statement post-processing: it lists the electronic bank statement items the import could not fully post or clear and lets someone finish them by changing the posting rule, adding the account or clearing information, and posting.** Its newer sibling is FEB_BSPROC, and in S/4HANA the Fiori app Reprocess Bank Statement Items (F1520) does the same job. They all work the same queue, and the queue is a symptom. Every item in it is a configuration gap or a data problem that will come back tomorrow unless someone fixes the cause as well as the item.

This page is the working companion to the [SAP electronic bank statement guide](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms), which covers the configuration chain. This one starts where that chain drops an item: why it dropped, how to reprocess it, and how to stop the same item dropping again.

## Five names for one queue

The naming confuses people, so start there:

| Tool | What it is | Where you meet it |
| --- | --- | --- |
| FEBAN | Classic GUI post-processing transaction | SAP ERP and S/4HANA on-premise, most users' habit |
| FEBA_BANK_STATEMENT | Post-processing transaction named in SAP's S/4HANA documentation | The [transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes) lists this one |
| FEB_BSPROC | Newer GUI post-processing transaction; SAP Help documents it as Reprocess Bank Statement Items (FEB_BSPROC) | S/4HANA; also documented in SAP's Cloud Public Edition help |
| Reprocess Bank Statement Items (F1520) | Fiori app: reprocess items manually or with processing rules, assign to customer, supplier or G/L, clear open items | All S/4HANA editions |
| Manage Processing Rules - For Bank Statements (F3555) | Fiori app for rules that repeat a reprocessing decision automatically | S/4HANA; see "shrinking the queue" below |

SAP's support content lists FEBA_BANK_STATEMENT, FEB_BSPROC, FEBA and FEBAN together as the post-processing transactions. The practical warning is that they are not interchangeable views of one thing. SAP publishes a page on the differences between FEB_BSPROC and the Fiori app, and its knowledge base has articles on items that show in FEBAN or FEB_BSPROC but not in F1520 (KBA 3364532), and on open-item allocation that happens automatically in FEB_BSPROC but needs a manual step in F1520 (KBA 3568048). Pick one tool per team and learn how it behaves. When two people work the same statement in different tools, expect to spend time reconciling the tools instead of the bank account.

## Why items stay open

An item reaches post-processing because one of the two posting areas did not complete. Posting area 1 books the bank side (bank account and clearing account). Posting area 2 does the subledger side: it finds the customer or supplier and clears the open item. The statement line-item table FEBEP carries a status for each (the fields VB1OK and VB2OK), and adding both to your FEBAN layout is the fastest diagnostic you have. Area 1 done and area 2 not done means the cash is booked but nothing is cleared, which is the most common state in the queue.

The causes, in the order I would check them:

| Symptom in the queue | Usual cause | Fix at the source |
| --- | --- | --- |
| Nothing posted at all for a whole account | House bank account without a G/L account, or currency mismatch | House bank and G/L master data |
| Items of one type never post | External transaction code (with its + or − sign) has no posting rule for that transaction type | Assign External Transactions to Posting Rules |
| Area 1 posted, area 2 open, reference visible in the note to payee | Interpretation algorithm found nothing: number ranges missing at import, or leading zeros differ | Import variant with BELNR/XBLNR ranges; algorithm choice (e.g. 026 for missing leading zeros) |
| Area 1 posted, area 2 open, reference present but deformed | Customer dropped digits, added spaces or wrapped the number in text | Search string plus mapping string, tested with the simulation |
| Customer identified, nothing cleared | Amount does not match open items: partial payment, deductions, charges | Tolerances, processing rules, or a residual-item policy |
| Item cannot be selected for clearing in F1520 | The open item belongs to a payment order (KBA 3557857) | Check the payment order the item belongs to first |

The algorithm and search-string mechanics behind rows three and four are covered in detail in the [EBS guide](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms). For most items that pile up in the queue, the fix is in the import variant or the search strings, not in the posting rules.

## Reprocessing an item

In FEBAN the working pattern is: select the statement and item, look at the note to payee, correct what is wrong on the item (posting rule, account, the reference or clearing criteria), and post. FEB_BSPROC adds an editable note to payee. The Fiori app lets you assign the payment to a customer, supplier or G/L account and clear open items. There you can also mark an item as reprocessed with a reason, which is the option to use when the item needs no posting but should leave the queue.

Three details save time:

- **Foreground, not background.** SAP's support content and KBA 2637795 discuss posting from the post-processing transactions in foreground or background, and the recommendation is foreground. When a posting fails in foreground you see why. In background you find out later.
- **Manual clearing does not always do what the automatic path does.** KBA 3466455 is the clearest example: the check encashment date (PAYR-BANCD), which the check algorithms 011–013 set when they clear a check automatically, is not updated when a check's payment document is cleared manually in post-processing. How you clear checks decides whether your outstanding-checks list and your [positive pay](https://gravam.com/blog/positive-pay-in-sap) reconciliation agree with the bank.
- **Reversal and re-post is a normal operation.** A wrongly posted item can be reversed and reprocessed with the same functions as the original posting. Treat it as a correction with an audit trail, not a failure to hide.

> The post-processing queue is where the EBS configuration shows its gaps. Clearing an item fixes today's statement. Recording why it failed is what fixes next week's.

## Shrinking the queue

Staffing the queue works until volume grows. The durable approach is to treat the queue as a defect list and work it by cause:

1. **Classify before you clear.** Pull the open items (FEBKO for statement headers, FEBEP for items) and group them by external transaction code and bank. A handful of codes usually accounts for most of the volume, and each one points to a single configuration fix.
2. **Map what the banks actually send.** Missing external-code assignments are the cheapest fix, since one row in Customizing removes a daily manual posting.
3. **Tune search strings with the simulation.** SAP provides a simulation of document-number search strings against imported statements. Use it before transporting a new string.
4. **Turn repeated decisions into processing rules.** Manage Processing Rules - For Bank Statements (F3555) defines conditions and actions (G/L postings, AP/AR postings, clearing), which the Reprocess Bank Statement Items app can apply. SAP ties the automatic mode, where rules run in the background during import, to its Cash Application integration, so check your scope before designing around it.
5. **Enrich at import when the pattern is yours.** The BAdI FIEB_CHANGE_BS_DATA runs during import and again during post-processing, including FEB_BSPROC and F1520. It is the place for company-specific logic that no standard algorithm will ever know, such as deriving a customer from a virtual account number. Keep it small and documented.
6. **Fix references upstream.** Remittance discipline with customers and [virtual account](https://gravam.com/blog/virtual-account-management-structures) structures improve auto-clear more than any post-processing tool can.

Measure the result as a rate, not a headcount: the share of items that post and clear without a person, per bank and per transaction code. That rate is [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury) applied to bank statements. When it drops, a bank changed something, and the queue will show it before anyone tells you.

## Where AI fits in the queue

The residue that survives all six steps is exactly the part that rules handle badly: free-text remittance, payments for several invoices with deductions, references that are nearly right. SAP's own answer is its Cash Application service, whose automatic bank statement reprocessing proposes matches for these items. The design question for any AI step here is the one the [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) works through: the model proposes, deterministic rules check amount and tolerance, and a named person decides the clearing on the residue. The [exception path](https://gravam.com/blog/designing-the-exception-path) should be designed before the model is chosen, and the [treasury exception management](https://gravam.com/blog/treasury-exception-management) page covers the operating side: owners, ageing and escalation.

## What I couldn't verify, and left out

- **Whether FEBAN is formally deprecated.** Some sources say FEB_BSPROC replaces FEBAN from a given release. I found SAP documentation for FEB_BSPROC but no SAP statement retiring FEBAN, so this page describes both as available on-premise.
- **The exact field-level differences between FEB_BSPROC and F1520.** SAP publishes a comparison page, but I could only confirm the individual differences named in the KBAs above.
- **Scope-item numbers for automatic processing rules.** They differ by edition and release. Check your own scoping.

***

_See also [bank statement formats: MT940 vs camt.053 vs BAI2](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), [SAP cash management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana) and [SAP treasury Fiori apps](https://gravam.com/blog/sap-treasury-fiori-apps)._

## Primary sources

SAP ERP 6.0 and SAP S/4HANA on-premise and private edition (FEBAN, FEBA_BANK_STATEMENT, FEB_BSPROC — the last also documented for Cloud Public Edition) and SAP S/4HANA in all editions for the Fiori apps Reprocess Bank Statement Items (F1520) and Manage Processing Rules - For Bank Statements (F3555). Claims were checked on 2026-09-25 through cross-checked excerpts of the listed sources; SAP Help pages and knowledge base articles were read through search excerpts, not in full.

- SAP Help (support content) — Postprocessing transactions FEBA(N)/FEB_BSPROC — accessed 2026-09-25 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361880461.html
- SAP Help — Reprocess Bank Statement Items (FEB_BSPROC), SAP S/4HANA — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/e556c5227b804a6eaee49282569948c0.html
- SAP Help — Difference Between FEB_BSPROC and the Reprocess Bank Statement Items App — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/237639ef10f74caf8f7e4c675e78687e.html
- SAP Help — Reprocess Bank Statement Items (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/918bca53037f408f91a2295d04ac16bc/bc1fe656fe590950e10000000a44147b.html
- SAP Help — Manage Processing Rules - For Bank Statements — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/918bca53037f408f91a2295d04ac16bc/d6fe6526b26f46e59d9d1dd0f7427fe3.html
- SAP Help — Cash Application: Automatic Bank Statement Reprocessing — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/213464e4cbff420b90659e652136d6fd.html
- SAP KBA 2637795 — FEBA(N)/FEB_BSPROC: Posting in Foreground/Background — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/2637795
- SAP KBA 3364532 — F1520 Reprocess Bank Statement Items: missing items in the app compared to FEBAN/FEB_BSPROC — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3364532
- SAP KBA 3568048 — Different behavior between FEB_BSPROC and F1520 in the Allocate Open Items option — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3568048
- SAP KBA 3466455 — Check encashment date PAYR-BANCD not updated in post-processing outside FEBAN — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3466455
- SAP KBA 3557857 — F1520: items are part of a payment order and cannot be selected for clearing — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3557857
- SAP Community — Enhancements in EBS: BAdI FIEB_CHANGE_BS_DATA — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-members/enhancements-in-ebs-badi-fieb-change-bs-data/ba-p/13572057

## Questions this article answers

**Q: What is FEBAN in SAP?**

FEBAN is the SAP GUI transaction for post-processing electronic bank statements: it lists the statement items that the import could not fully post or clear and lets a user complete them — change the posting rule, enter the account or clearing information, and post. SAP's support content lists it alongside FEBA_BANK_STATEMENT, FEBA and the newer FEB_BSPROC as the post-processing transactions, and in SAP S/4HANA the Fiori app Reprocess Bank Statement Items (F1520) covers the same job.

**Q: Why are bank statement items not posted or cleared automatically in SAP?**

Almost always for one of a few reasons: the bank's external transaction code has no posting rule for that sign; the interpretation algorithm found no matching document because the number ranges were missing at import or the reference arrived in a different form; the reference was deformed and no search string recognised it; the amount did not match the open items; or the house bank account has no G/L account behind it. Posting area 1 can succeed while posting area 2 fails, which leaves the cash booked but the open item uncleared.

**Q: What is the difference between FEBAN and FEB_BSPROC?**

Both post-process electronic bank statement items. FEB_BSPROC is the newer transaction and is the one SAP's S/4HANA documentation describes as Reprocess Bank Statement Items (FEB_BSPROC); FEBAN is the older, widely used transaction that still runs on-premise. SAP documents the differences between FEB_BSPROC and the Fiori app separately, and its knowledge base records cases where the GUI transactions and the app show or clear items differently, so pick one tool per team and learn its behaviour.

---

# SAP Multi-Bank Connectivity (MBC): What It Is and Isn't

Source: https://gravam.com/blog/sap-multi-bank-connectivity
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: SAP Multi-Bank Connectivity is SAP's managed BTP network to banks. How it differs from host-to-host, EBICS and Swift, what flows through it, and onboarding.

**SAP Multi-Bank Connectivity (MBC) is a managed connectivity service that SAP runs on SAP Business Technology Platform (BTP). It carries payment files, payment status reports and bank statements between your SAP system and your banks, using whichever channel each bank supports: a direct link to a bank that has joined the network as a member, SFTP host-to-host, EBICS, or Swift.** You connect SAP to it once, through the connector for SAP Multi-Bank Connectivity, and SAP operates the rest. MBC is a transport layer. It does not build your payment files, approve your payments, or change a single byte of what you send.

The last sentence matters, because most MBC disappointments come from expecting the service to do something it was never designed to do. This page covers what MBC is, how it compares with the connectivity options you already know, what flows through it, and what onboarding involves.

## The three moving parts

An MBC landscape has three components, and SAP's Cloud FAQ (KBA 3398869) describes the tenant roles the same way:

| Component | Where it runs | What it does |
| --- | --- | --- |
| Connector for SAP Multi-Bank Connectivity | In your SAP system: an add-on (namespace /BSNAGT/) for SAP ERP and S/4HANA up to 1809; part of S4CORE from S/4HANA 1909 | Creates outbound messages, routes inbound ones to the right SAP process, monitors both |
| MBC tenant (test and production) | SAP BTP, operated by SAP | Receives, secures and routes messages between you and the bank side |
| Bank side | A bank tenant for member banks; otherwise the bank's own SFTP, EBICS or Swift endpoint | Delivers to and collects from the bank's back end |

SAP's documentation is explicit that all messages to and from MBC pass through the connector. That is also where you monitor them. Up to S/4HANA 1909 FP01 that meant the connector monitor, transaction /BSNAGT/MONITOR. From there on, and in S/4HANA Cloud Public Edition, it is the Fiori app **Manage Bank Messages** (F4385), where you can see failed messages, trigger reprocessing and download payloads.

## How it differs from what you already know

MBC does not replace the four [bank connectivity channels](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics). It sits on top of them. What changes is who builds and runs each connection.

| Option | Who builds and runs the connection | What you still own |
| --- | --- | --- |
| Direct host-to-host per bank | You (or your middleware team), one integration per bank | Everything: transport, keys, certificates, monitoring, every bank's quirks |
| Direct [EBICS](https://gravam.com/blog/ebics-european-bank-connectivity) client | You, with an EBICS client product and a per-bank subscriber setup | The client, the keys, the bank-by-bank initialisation |
| Swift via your own interface or a service bureau | You or the bureau, with your Swift agreement | The Swift relationship and security obligations, plus the ERP integration to the bureau |
| SAP Multi-Bank Connectivity | SAP operates the MBC tenant and the network side; channels per bank can be member-bank, SFTP, EBICS or Swift, mixed within one landscape | ERP-side connector, certificates, format content, bank agreements, per-bank onboarding requests |

The Swift row needs one clarification. For Swift, SAP has acted as an **Alliance Lite2 for Business Applications (L2BA)** provider, a Swift partner model in which SAP operates the Swift infrastructure and integration for customers who hold their own Swift agreement. You still need that agreement, and you still have a relationship with Swift. SAP runs the plumbing. SAP also documents how the [Swift Customer Security Programme](https://gravam.com/blog/bank-connectivity-security) applies in the MBC context. Read that page before assuming the attestation question has gone away.

> MBC changes who runs the pipe. It does not change what flows through it: the file your bank rejects was built in your ERP, and that is where it gets fixed.

## What flows through it

Outbound, MBC carries what your SAP system produces. That is typically [pain.001](https://gravam.com/blog/pain-001-structure-and-fields) credit transfers built by the Payment Medium Workbench and a [DMEE format tree](https://gravam.com/blog/sap-dmee-payment-file-format-tree), plus other payment files your banks accept. Inbound, it carries what the banks send back: [pain.002](https://gravam.com/blog/pain-002-status-and-reject-codes) status reports and account reporting in [camt.053](https://gravam.com/blog/camt-053-structure-and-fields), camt.052, [camt.054](https://gravam.com/blog/camt-054-notification-explained), MT940, MT942 and [BAI2](https://gravam.com/blog/bai2-file-format-explained). SAP's own guidance on common misconceptions is blunt on the key point: MBC does not change or transform file content. If a bank rejects a file for its structure, the fix is in the ERP's format configuration.

What happens to inbound messages depends on the process they belong to, and this is where MBC connects to the rest of the landscape:

- **Payment status to BCM.** When [Bank Communication Management](https://gravam.com/blog/bank-communication-management-bcm-sap) is used, BCM releases the approved batch to MBC. The status reports that come back update the batch, so the monitor shows what the bank actually did with it.
- **Payment status to APM.** In an [Advanced Payment Management](https://gravam.com/blog/sap-advanced-payment-management-apm) landscape, SAP documents inbound pain.002 processing through MBC into APM's own status handling.
- **Bank statements to EBS.** The connector documentation describes inbound statement payloads (an [MT940](https://gravam.com/blog/mt940-format-tags-explained) or camt.053 file, depending on the bank) being handed to the standard import (FF.5), and SAP documents the import route as Import by Multi-Bank Connectivity. From there the [posting rules and interpretation algorithms](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) take over, as for any other statement source.

So the architecture is layered: APM decides what flows where, BCM decides whether it may leave, and MBC carries it. [BCM, APM and output-management boundaries](https://gravam.com/blog/sap-bcm-apm-output-management-architecture) draws the same split from the control side.

## Onboarding: what actually happens

MBC onboarding is partly a service request process, which is unfamiliar to teams used to building interfaces themselves. The outline, from SAP's own getting-started material:

1. **Contract and tenants.** MBC is licensed separately. SAP's Cloud documentation states that integration requires an active MBC license. SAP provisions test and production tenants and sends a welcome pack with a checklist.
2. **Certificates.** Each organization provides certificates signed by a certificate authority SAP trusts, one set per tenant. The SAP system also imports the root and intermediate certificates of the MBC endpoints in both test and production. Certificate expiry is an operational dependency from then on: put it in the [interface monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation) calendar.
3. **Connector configuration.** On-premise, this is the connector add-on or S4CORE configuration plus the communication setup to the tenant. In Cloud Public Edition, it is the setup SAP documents under Integration with SAP Multi-Bank Connectivity.
4. **Bank by bank.** For SFTP, EBICS and member-bank connections, you raise a service request per bank. Each bank still has to agree the channel, exchange keys and run its own tests. MBC shortens the build, but it does not remove bank-side onboarding.
5. **Formats and testing.** Format content is agreed with each bank and built in the ERP. MBC carries the test files. It does not validate your pain.001 against the bank's implementation guide.

The realistic benefit is not that onboarding disappears. It is that bank number six uses the same connector, monitoring and security model as bank number one, instead of becoming a new integration project.

## The Swift change on the horizon

Swift is retiring Alliance Lite2 for Business Applications, and the successor for embedded providers is **Business Connect**, which runs on Alliance Cloud. According to SAP's migration guide for MBC customers, the official L2BA end of life is December 2027, SAP's own deadline is 30 June 2027, and the migration is designed to change the engine underneath without format changes, a new MBC tenant or a reconfiguration of the S/4HANA system. If your MBC landscape uses Swift, put the migration window in the plan now and confirm the dates with SAP. Vendor deadlines move, and the review cycle on this page is set to catch that.

## When I would choose it, and when I wouldn't

MBC makes the most sense when the landscape is SAP-centred, the bank count is more than a handful, and nobody wants to own a portfolio of per-bank SFTP and EBICS integrations. It also deserves the first look on S/4HANA Cloud Public Edition, where SAP documents MBC integration as part of the product's own bank integration setup.

It makes less sense when you already run a treasury middleware or a TMS that owns bank connectivity well, when one or two banks carry almost all the volume on a stable host-to-host link, or when most payments originate outside SAP. In those cases MBC adds a second connectivity estate rather than consolidating the first. The general trade-offs are on the [integration patterns](https://gravam.com/blog/treasury-integration-patterns-files-apis-middleware) page. MBC is one concrete instance of the "managed network" option there.

## What I couldn't verify, and left out

- **Pricing and commercial model.** Not documented publicly in a form I could cite.
- **Which banks are member banks.** The list changes and is SAP's to publish. Ask for it when you engage SAP rather than trusting a slide.
- **API channels in detail.** Some sources describe API-based bank connections through MBC. I could not confirm the scope and prerequisites in SAP's documentation, so they are not described here.

***

_See also [SAP payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow), [EBICS](https://gravam.com/blog/ebics-european-bank-connectivity) and [bank connectivity security](https://gravam.com/blog/bank-connectivity-security)._

## Primary sources

SAP Multi-Bank Connectivity as documented for SAP ERP 6.0 (connector add-on), SAP S/4HANA on-premise and private edition (connector in S4CORE from 1909) and SAP S/4HANA Cloud Public Edition. The Swift Alliance Lite2 for Business Applications retirement dates are SAP's and Swift's as published in September 2026 and may move. Claims were checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- SAP Help — SAP Multi-Bank Connectivity — accessed 2026-09-25 — https://help.sap.com/docs/SAP_MULTI_BANK_CONNECTIVITY/3fa51d2862684bcfa3183bf499792673/6146e281e340429498d7f138eda3dea4.html
- SAP Help — Connector for SAP Multi-Bank Connectivity (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/aeee1a7fdff645e586d42fafdc2268eb.html
- SAP Help — Integration with SAP Multi-Bank Connectivity (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/cdccca8e03d74101a0135863bc522b49/aa78ddc4656643ffbdabee488bf7cbfc.html
- SAP Help — Import by Multi-Bank Connectivity (Bank Communication Management, SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/fb70d54e9db84c17b5118afa0ce5db3b.html
- SAP Help — Swift Customer Security Programme (CSP) in the Context of SAP Multi-Bank Connectivity — accessed 2026-09-25 — https://help.sap.com/docs/SAP_MULTI_BANK_CONNECTIVITY/3fa51d2862684bcfa3183bf499792673/913182dd9cdd47f3a5dd2e5423f91e91.html
- SAP Community (SAP) — SAP Multi-Bank Connectivity (MBC): All You Need to Know — accessed 2026-09-25 — https://community.sap.com/t5/financial-management-blog-posts-by-sap/sap-multi-bank-connectivity-mbc-all-you-need-to-know/ba-p/13619921
- SAP Community (SAP) — Common Misconceptions About SAP Multi-Bank Connectivity (MBC) — accessed 2026-09-25 — https://community.sap.com/t5/financial-management-blog-posts-by-sap/common-misconceptions-about-sap-multi-bank-connectivity-mbc/ba-p/14419530
- SAP Community (SAP) — From Alliance Lite2 to Business Connect: Your Migration Guide for SAP Multi-Bank Connectivity — accessed 2026-09-25 — https://community.sap.com/t5/financial-management-blog-posts-by-sap/from-alliance-lite2-to-business-connect-your-migration-guide-for-sap-multi/ba-p/14486081
- SAP Community (SAP) — Advanced Payment Management: Processing Inbound Messages (pain.002) using Multi-Bank Connectivity — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/advanced-payment-management-processing-inbound-messages-pain-002-using/ba-p/13705649
- SAP KBA 3398869 — FAQs about SAP MBC for SAP S/4HANA Cloud Public Edition customers — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3398869
- Swift — Alliance Lite2 for Business Applications — accessed 2026-09-25 — https://www.swift.com/about-us/partner-programme/lite2-for-business-applications
- Swift — Business Connect — accessed 2026-09-25 — https://www.swift.com/products/business-connect

## Questions this article answers

**Q: What is SAP Multi-Bank Connectivity?**

SAP Multi-Bank Connectivity (MBC) is a managed connectivity service that SAP runs on SAP Business Technology Platform. It carries financial messages between a company's SAP system and its banks — payment files out, payment status reports and bank statements back — over whichever channel each bank supports: a direct link to a bank that is a member of the network, SFTP host-to-host, EBICS, or Swift. The SAP system connects to it once, through the connector for SAP Multi-Bank Connectivity, instead of building a separate channel for every bank.

**Q: Does SAP Multi-Bank Connectivity convert payment formats?**

No. SAP's own guidance is that MBC transports files without changing their content. The payment file, such as a pain.001, is generated in SAP S/4HANA or SAP ERP — usually through the Payment Medium Workbench and a DMEE format tree — and MBC transmits it. If the bank rejects the format, the fix is in the ERP's format configuration, not in MBC.

**Q: Is SAP MBC the same as Swift?**

No. Swift is one of the channels MBC can use. For Swift, SAP has acted as an Alliance Lite2 for Business Applications provider, operating the Swift infrastructure for customers who have their own Swift agreement. MBC can also reach banks directly as network members, or through SFTP host-to-host and EBICS connections, and a single customer can mix these channels bank by bank.

**Q: Do I need BCM to use SAP Multi-Bank Connectivity?**

No, but they are designed to work together. MBC is the transport; Bank Communication Management is the approval and release control. When BCM is used, a payment batch is approved in BCM and then handed to MBC, and the payment status reports that come back through MBC update the batch. Without BCM, the payment medium goes to MBC directly after the payment run.

---

# SAP Payment Approval Workflow: BCM Rules and Dual Control

Source: https://gravam.com/blog/sap-payment-approval-workflow
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-09-25
Reviewed: 2026-09-25
Summary: How payment approval works in SAP: dual control on bank data, proposal-versus-run separation in F110, BCM batch rules and release steps, and the Fiori apps.

**An SAP payment approval workflow is not one screen. It is three gates in sequence: dual control on the payee's bank data, a separation between proposing and executing the payment run in F110, and the batch release in Bank Communication Management (BCM), where payments are grouped by rule and released through workflow steps, optionally with a digital signature.** Most audit findings on payments come from treating the third gate as the whole control. A perfectly tiered release strategy protects nothing if the person releasing the batch also changed the supplier's IBAN yesterday.

This page covers each gate at configuration level: the objects, the transactions and apps, and where each one can be bypassed. The [BCM overview](https://gravam.com/blog/bank-communication-management-bcm-sap) explains what BCM is for. This page is about making its approval logic, and the controls around it, hold up.

## Three gates, not one

| Gate | What it controls | Where it lives in SAP | Typical bypass |
| --- | --- | --- | --- |
| 1. Payee master data | Who can change where the money goes | Sensitive fields for dual control; confirmation in FK08/FK09 (or the business partner equivalents) | Bank details changed by someone who also approves payments |
| 2. Payment run | What gets paid, and who turns it into payments | F110 and F111, authorization object F_REGU_BUK, paying-company-code configuration in FBZP | One role holding both the proposal and the payment-run activities |
| 3. Batch release | Whether the payment leaves for the bank | BCM payment grouping rules, release strategy, BNK_APP / Approve Bank Payments | Rules marked for automatic payment; payment methods that never reach BCM |

The gates answer different questions, and they fail independently. That is the reason to design them together.

## Gate 1: dual control on bank details

Payment fraud rarely changes the payment. It changes the payee's bank account and lets a normal payment run do the rest (the [payment fraud prevention](https://gravam.com/blog/payment-fraud-prevention-in-treasury) page lists it as standing-data tampering). SAP's control for this is **sensitive fields for dual control**. You define which vendor or customer master fields are sensitive in Customizing (Define Sensitive Fields for Dual Control). A change to one of them then has to be confirmed by a second person before the account can be paid. Until then, the account is blocked for the automatic payment run. FK08 confirms a single vendor and FK09 works through the list of unconfirmed changes.

The limitation matters for design. The block applies to the _automatic payment run_, not to postings. SAP's KBA 3404779 explains why invoices, and even manual payments, can still be posted against an account with unconfirmed changes. So a manual outgoing payment is outside this gate, and needs its own control. And the control is only as good as the list of fields you mark: bank details and alternative payee are the obvious ones, and whether a given bank field shows up for confirmation has its own KBAs. Test it with a real bank-detail change before relying on it.

The segregation rule is simple. Whoever confirms sensitive changes must not also approve payment batches. If they can do both, gate 1 and gate 3 are the same person, and the attack just needs that one person.

## Gate 2: separating the proposal from the run

F110 has a two-step design that invites segregation: a **proposal** (which open items will be paid, how, from which bank) and the **payment run** (post the payment documents, then create the payment medium). The authorization object F_REGU_BUK controls each step by activity code:

| Activity | Meaning |
| --- | --- |
| 02 / 03 | Edit / display parameters |
| 11 | Execute proposal |
| 12 | Edit proposal |
| 13 | Display proposal |
| 14 | Delete proposal |
| 15 | Create payment medium proposal |
| 21 | Execute payment run |
| 23 | Display payment run |
| 24 | Delete payment run payment data |
| 25 | Create payment media of payment run |
| 26 | Delete payment orders of payment run |
| 31 | Print payment medium manually |

The common segregation is a proposal role with 11–15 and a run role with 21–31, so the person who decides what gets paid is not the person who executes it. Watch activity **12** in particular. Editing the proposal means changing which items are paid, the payment method and the bank. That is a strong right, and it often gets bundled into a generic "AP clerk" role without anyone noticing.

Two points people get wrong here:

- **FBZP is configuration, not a transaction for daily use.** Paying company codes, payment methods, bank determination and ranking are Customizing, which should reach production through a transport. The control question for FBZP is change management on those settings (the [decision log and change control](https://gravam.com/blog/decision-log-and-change-control) discipline), not who runs it on Tuesday.
- **The F110 proposal workflow is not an approval workflow.** SAP's KBA 2765633 is explicit: the workflow-based release of the payment proposal organizes the clerks who review and edit the proposal. It does not support a multi-level release of payments. For that, SAP points you to BCM.

## Gate 3: BCM batches and release strategy

This is the gate most people mean when they say "SAP payment approval workflow". Its configuration has four parts, and the order matters.

**1. Merge into batches.** After F110 or F111, the merge step (FBPM1, or its report SAPFPAYM_MERGE scheduled as a job) collects eligible payments and groups them into batches. The prerequisite that surprises people is that BCM's merge works on payments whose format runs through the Payment Medium Workbench, so a payment method still on a classic payment-medium program stays outside the batch logic. The [DMEE format tree](https://gravam.com/blog/sap-dmee-payment-file-format-tree) page covers the PMW side.

**2. Payment grouping rules.** Under Payment Grouping → Rule Maintenance you define rules with selection criteria built from payment fields such as company code, house bank and payment method, and give each rule a priority. When a payment satisfies more than one rule, the priority decides which batch it lands in. Additional grouping criteria can split a rule into finer batches, for example one per payment method. A batch's rule determines its release procedure, so a wrong priority is a wrong approval path.

**3. Release strategy.** Each rule is assigned a release procedure with its release steps. There are two release objects:

- **BNK_INI** for the first approval. It is the only step with change capability: the first approver can take individual payments out of the batch.
- **BNK_COM** for subsequent approvals, which act at batch level (approve or reject). BNK_COM can carry a varying number of steps, made conditional, for example on amount.

SAP delivers standard workflow templates for these steps. SAP's BCM documentation describes approval through standard workflow, with a standard role assigned to each release step so you can plug in your own agent determination.

**4. Signature.** Under Release Strategy → Digital Signatures, you can require that approval be signed. The signature method can be a user-credential check or a digital signature based on Secure Store and Forward (SSF), and approvers then need SSF data in their user master. The configuration guides agree on the order: enable "signature required" last, after the SSF setup, the approvers' user master data, the signature method and an end-to-end approval test are in place.

> The most dangerous line in a BCM configuration is a checkbox. A rule marked for automatic payment sends its batches past the approval workflow entirely, and nothing on the approver's screen shows that it happened.

The checkbox is **Mark Rules for Automatic Payments (No Approval)**, in the same Release Strategy node. It has legitimate uses, such as high-volume low-value runs where the control sits elsewhere. But it is an exemption from gate 3, and it should be in the control documentation as one, with an owner and a review date. In a configuration review, check this list before anything else.

**Approving and monitoring.** Approvers work in BNK_APP or the Fiori app **Approve Bank Payments** (F0673A). There they can check payments within a batch and approve, reject or defer individual payments or whole batches. Volume changes the approval problem: the app's "Approve in Background" function (KBA 3196261) runs mass approval as a background job, which avoids timeouts on large batches. It also makes it easier to approve without looking, so decide deliberately who gets it. And don't assume the app enforces four eyes on its own: SAP's KBA 2444592 states that Approve Bank Payments has no check on the creator, so a user can approve a payment they created — the separation has to come from roles and the approver assignment, not from the app. After release, BNK_MONI or Monitor Payments tracks the batch to the bank, and the status coming back ([pain.002](https://gravam.com/blog/pain-002-status-and-reject-codes)) closes the loop.

## S/4HANA Cloud: approval rules instead of IMG

In SAP S/4HANA Cloud Public Edition, the same control is configured differently. SAP's documentation describes the app **Manage Payment Approval Rules**, where you define how many people (one or two) from which approver groups may approve which payment amount. The rule itself goes through approval: it is created, submitted, approved or rejected, and the user who submitted a rule may not approve it. That is four-eyes on the control itself, not only on the payments it governs.

The Cloud trap is the default. KBA 3731235 describes payment runs from **Manage Automatic Payments** being posted without an approval step until you enable the workflow, and lists the prerequisites: the Advanced Cash Operations scope item (J78), full cash management scope in the basic settings, and the payment approval settings (SSCUI 102336). If the scoping workshop assumed approval "comes with" payments, check this before go-live.

SAP's newer approval scenarios, starting in the cloud editions, run on the flexible workflow framework, which offers conditional triggering and flexible agent determination through Fiori. The underlying design decisions are the same either way: which payments need approval, from whom, in what sequence, and with what escape hatch.

## The segregation matrix to test

Configuration only shows what the system _can_ enforce. Whether it does depends on the roles. These are the combinations I would test in any payment-controls review:

| Same user holds... | ...and | Why it breaks the control |
| --- | --- | --- |
| Sensitive master-data change (vendor/BP bank data) | Confirmation (FK08/FK09) | Dual control collapses into single control |
| Sensitive master-data change or confirmation | BCM approval at any step | Can redirect a payment and then approve it |
| F110 edit proposal (12) | F110 execute payment run (21) | Decides what is paid and executes it |
| F110 execute payment run (21) | BCM approval | Creates and releases the same payments |
| Payment grouping or release-strategy customizing | BCM approval | Can route their own batches around approval |

The [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) page covers the treasury-wide version, and [access management and user provisioning](https://gravam.com/blog/access-management-and-user-provisioning-treasury) covers how these combinations creep back in through emergency access and role changes.

## Where AI requests land

The question that now comes up in design reviews is what happens when an AI step, not a clerk, creates the payment request. In SAP the answer sits exactly in these three gates. An agent that proposes payments should hit gate 2 under its own identity and meet gate 3 like any other initiator. It must never hold a BCM approval step. [Can an AI agent approve its own payment?](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment) works through why the release strategy, not the agent framework, has to enforce that. [Four-eyes and segregation of duties for AI agents](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) covers what happens to a human approver who only ever sees the agent's summary.

## What I couldn't verify, and left out

- **Flexible workflow scenario IDs for bank payments.** I found SAP documentation for the approval-rule app and for the flexible workflow framework in general, but not a scenario ID I could print with confidence. It is left out.
- **Rule-priority numbering.** Consultant guides describe which priority number wins when two grouping rules match. I could not confirm the direction in SAP's own documentation, so the page says only that priority decides.
- **Agent determination details per release step.** How your organization resolves approvers (organizational management, custom rules, BAdIs) is implementation-specific and not something a reference page should invent.

If you configure one thing differently after reading this, make it the first gate. Release strategies get the design workshops and the audit attention, while the bank-detail change that makes a fraudulent payment look routine happens in master data.

***

_See also [SAP Advanced Payment Management](https://gravam.com/blog/sap-advanced-payment-management-apm), [BCM, APM and output-management boundaries](https://gravam.com/blog/sap-bcm-apm-output-management-architecture) and [SAP Multi-Bank Connectivity](https://gravam.com/blog/sap-multi-bank-connectivity)._

## Primary sources

SAP S/4HANA on-premise and private edition (Bank Communication Management, F110, dual control on sensitive fields) and SAP S/4HANA Cloud Public Edition (Manage Payment Approval Rules, Approve Bank Payments). Also applies in substance to SAP ERP 6.0 with BCM. Claims were checked on 2026-09-25 through cross-checked excerpts of the listed sources; SAP Help pages were not fetched in full, so verify IMG paths and app availability against your release and edition.

- SAP Help — Bank Communication Management: Purpose and Features (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/3f7ad0531d8b4208e10000000a174cb4.html
- SAP Help — Payment Release Process (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/24eed353ca9f4408e10000000a174cb4.html
- SAP Help — Approve Bank Payments (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c401ac923da649359cb8052438b0d9be.html
- SAP Help — Manage Payment Approval Rules (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/cda26db3bad04f65830badab26ad4e90.html
- SAP KBA 3731235 — Enabling approval workflow for payment runs in Manage Automatic Payments (SAP S/4HANA Cloud Public Edition) — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3731235
- SAP KBA 2765633 — Workflow-based release of payment proposal and payment approval in BCM — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/2765633
- SAP KBA 3196261 — Configuring Approve in Background, Approve Bank Payments (F0673A) — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3196261
- SAP KBA 2444592 — Approve Bank Payments app allows user to approve self created payments — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/2444592
- SAP KBA 3404779 — Define Sensitive Fields for Dual Control (Customers/Vendors) — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3404779
- SAP Community (SAP) — Payment approvals configuration using BCM in SAP S/4HANA — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/payment-approvals-configuration-using-bcm-in-sap-s-4hana/ba-p/13473266
- IT-Implementor — Values for SAP authorization objects F_REGU_BUK and F_REGU_KOA — accessed 2026-09-25 — https://www.it-implementor.co.uk/2012/10/values-for-sap-auth-objects-fregubuk.html

## Questions this article answers

**Q: How do you set up a payment approval workflow in SAP?**

In SAP S/4HANA on-premise the approval workflow for outgoing payments is Bank Communication Management. Payments from F110 or F111 are merged into batches according to payment grouping rules, each rule is assigned a release procedure in the release strategy, and approvers release the batch through standard workflow — the first step with the release object BNK_INI, later steps with BNK_COM — optionally with a digital signature. Approvers work in BNK_APP or the Approve Bank Payments app. In S/4HANA Cloud Public Edition you define payment approval rules and approver groups instead, and enable the approval workflow for payment runs.

**Q: Can the same user create the payment proposal and execute the payment run in F110?**

Technically yes, if their role allows it, which is why the separation has to be designed in the authorization concept. The authorization object F_REGU_BUK controls F110 by activity — editing parameters, executing, editing and deleting the proposal, executing the payment run and creating payment media each have their own activity code. A common segregation is to give one role the proposal activities and another the payment run activities, so the person who decides what gets paid is not the person who posts and releases it.

**Q: Does the F110 payment proposal workflow give you multi-level approval?**

No. SAP's own knowledge base is explicit that the workflow-based release of the F110 payment proposal is for organising the clerks who review and edit the proposal, not a multi-level release process for payments. When you need a genuine approval process for payments, SAP points you to Bank Communication Management.

**Q: What bypasses a BCM approval workflow?**

The documented one is a rule marked for automatic payment in the release strategy: batches that fall under it skip the approval workflow entirely. Others are design gaps rather than features — payment methods not routed through BCM, a user who can both edit the proposal and approve the batch, and approvers who can also maintain the bank details on the payee.

---

# SAP DMEE: How Payment File Formats Are Built

Source: https://gravam.com/blog/sap-dmee-payment-file-format-tree
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-08-03
Reviewed: 2026-09-26
Summary: The DMEE format tree explained — node types, the mapping procedures, tree type PAYM, the FPAY* source structures, and where DMEE sits between F110 and PMW.

**SAP DMEE, the Data Medium Exchange Engine, is the tool that defines payment file formats as format trees, and every payment file SAP produces through the Payment Medium Workbench is built by walking one.** The payment run creates payment data, the PMW calls its payment medium program, and the DMEE format tree — one node per record, field and sub-field of the bank's file specification — maps system fields into the file, node by node, top to bottom. If you can read the tree, you can predict the file; if you can't, every format incident is archaeology. This page is the configuration-level reference for that tree: the node types, the mapping procedures, the source structures, and where DMEE stops and the PMW begins. Same method as the rest of this [SAP treasury guide](https://gravam.com/blog/what-is-sap-treasury-and-risk-management): search "sap dmee" and you'll find screenshot tutorials asserting node types and source structures nobody can source, so everything below is checked against SAP's own documentation, and what I couldn't verify is named at the end instead of quietly included.

## Where DMEE sits: F110 → PMW → tree → file

SAP's own description of the outgoing-file flow is worth quoting almost verbatim, because it settles the "DMEE vs PMW" confusion in one paragraph. When you execute a payment run, the system triggers the generic payment medium program of the PMW; the PMW format uses the DMEE format tree to create the file that goes to your bank. The engine's job, in SAP's technical view, is four steps: the calling application selects data and fills the transfer structure, calls the DMEE modules with the selected data, gets back an internal table in the format structure, and writes the data to a file (updating DME administration in the payment case). There's even a documented BAdI — File Modification, under DME Engine in Customizing for Cross-Application Components — that lets you touch the internal table between steps three and four.

So the division of labour is:

| Layer | Owns |
| --- | --- |
| Payment run (F110, or [treasury's F111](https://gravam.com/blog/sap-treasury-transaction-codes)) | Deciding what gets paid, when, how — and writing the payment data |
| Payment Medium Workbench (PMW) | The format's configuration shell: output type, note to payee, variants, DME administration |
| DMEE format tree | The field-by-field mapping from system data to the bank's file layout |

The PMW itself, per SAP's documentation, is the tool that configures and creates payment media, built to gradually phase out the classic RFFO* payment medium programs — with better mass-payment performance (SAP cites >50,000 payments), better control, and easier maintenance. It's not payments-only in ownership terms either: SAP lists FI-AP/AR, travel management, payroll, cash management and treasury as components that use it. Where the file goes _after_ it exists — batching, approval, bank transmission — is a different layer again, and the [output-management architecture article](https://gravam.com/blog/sap-bcm-apm-output-management-architecture) maps that whole stack; this page stays inside the format.

One consultant-grade correction to the forum lore, straight from SAP's support documentation: not every payment format is a DMEE tree. SAP maintains two groups — formats implemented with function modules (its examples: DTAZV, MT101) and formats implemented with the DME Engine (its examples: CH_DTA, SEPA_CT, V3). So if you've been hunting for the [MT101](https://gravam.com/blog/mt101-vs-mt103-vs-mt202) format tree in DMEE, that's why you haven't found it. The DMEE-built formats include the XML credit-transfer families — and if the file your tree produces is a pain.001, the [structure of that file itself](https://gravam.com/blog/pain-001-structure-and-fields) has its own reference on this site.

## What a format tree actually is

SAP's definition is compact: the DME Engine lets you model an externally defined bank format in the SAP system, because there is no worldwide standard payment file format — sometimes not even a national one — and covering every local format in standard software isn't realistic. The format tree is that model. You create one in transaction DMEE (DMEEX in current S/4HANA — more below): choose a **tree type**, name the tree — usually after the format itself — and specify whether it generates a **flat file or an XML file**. The tree starts from a root node called the header, and you insert nodes hierarchically until the tree mirrors the bank's file layout description, then activate it. Only an active tree can be used by calling applications.

Two things about that creation flow carry most of the practical weight:

- **The tree type decides everything downstream** — which source structures the mapping offers you, and which application can call the tree. PAYM is the payment program's tree type; it is why a payment tree offers you payment structures and a tax tree offers you tax structures.
- **For PAYM trees, the PMW format and the DMEE tree must have identical names.** SAP's documentation states this twice, in both directions. When the names drift apart — usually a Z-copy renamed on one side only — the format stops resolving, and the error will not tell you why.

Format trees are transportable, and can alternatively be uploaded and downloaded as XML files — which is also the honest answer to "how do I diff two trees": download both and compare the XML. SAP delivers predefined trees for many countries' formats, and the sane implementation move is copying the closest delivered tree rather than building from an empty root.

## The node types

SAP documents two node-type sets, one per file style. For **flat files** (fixed-length or delimited records):

| Node | SAP's definition |
| --- | --- |
| Segment group | Groups segments |
| Segment | Represents a record in the target file |
| Composite | Groups elements |
| Element | Represents a target field of the DME file |
| Atom | Outputs more than one value to a single element, or controls which value is output, based on conditions |
| Technical node | Not output to the file; stores values that other nodes (elements, atoms) use by referencing this node |

For **XML files**:

| Node | SAP's definition |
| --- | --- |
| Element | One line of the XML file; carries a value itself, or groups other elements as subnodes |
| Atom | Same two jobs as in flat trees — multiple values into one element, or condition-controlled value selection |
| Technical node | Same as in flat trees — stored, referenced, never output |
| XML attribute | A subnode of an element; provides detail for the element, and can hold atoms as subnodes (for mapped conditions) |

The reading that makes trees legible on first open: **segments are lines, elements are fields, composites and segment groups are grouping brackets, and atoms and technical nodes are logic.** A tree with no atoms and no technical nodes is a plain transcription of the bank's spec. Every atom is a fork — "this field can be filled more than one way" — and every technical node is a computed intermediate someone needed twice. Count the atoms and technical nodes and you've measured how much decision logic the format carries; that's where the debugging time will go.

## The mapping: seven procedures, four you'll actually use

Mapping is the step where the tree stops being a drawing of the file and becomes a program. For each element (or atom) you select a **mapping procedure**; SAP's table for outgoing files lists seven:

| Mapping procedure | When SAP says to use it |
| --- | --- |
| Constant | The value is a fixed constant |
| Structure field | The value comes from a specific source field in the system |
| Reference to tree node | An attribute of an already-defined node — its current value, length, or counter reading — is reused |
| Aggregation | A value related to reference nodes is totalled and made available to this node |
| Exit module | Standard mapping and conversion rules don't cover the requirement, so a function module supplies the value |
| Own mapping (atoms) | Elements only: the rules depend on conditions, or parts of the element fill from different sources |
| No mapping | XML trees only: the element carries no value itself and just groups subnodes |

SAP's own documentation says most cases are the mapping procedure **Structure field** — one system field into one target field, picked from the source field inventory. Constants cover the literals every format carries (record type codes, format identifiers). The remaining procedures are the interesting ones:

- **Reference to tree node** is what technical nodes exist for, and it's also how counters and lengths get into headers and trailers — a node can expose its counter reading, not just its value.
- **Aggregation** is the trailer-record procedure: on the Aggregation tab you enter the reference IDs of the nodes to total and the aggregation type — sum of values (elements only, optionally as absolute values, ignoring signs) or count of occurrences. SAP's examples are exactly what you'd guess: total amount of all payments in a level, number of payments in a level.
- **Exit module** is the escape hatch: an ABAP function module, written in the ABAP Workbench — SAP's note is explicit that you don't write code in the DME Engine — from the delivered templates DMEE_EXIT_TEMPLATE or DMEE_EXIT_TEMPLATE_EXTENDED. Documented reach: exits can select from database tables that aren't in the standard selection step at all, customer tables included. That power is why a tree with many exits is no longer inspectable from the tree alone — you're back to reading ABAP.
- **Own mapping (atoms)** turns one element into a decision: create the atoms as subnodes, give each its own procedure and source, and conditions decide which one fires.

Optionally, each mapping can name a **conversion method** to reformat the source value for the file; with none specified, data transfers in the format it has in the system — which is precisely how internal date and amount formats leak into files when a delivered tree is copied carelessly.

**Conditions** deserve their own paragraph, because they're the top cause of "the field just isn't there". Any node in an outgoing tree can carry conditions; each condition line compares two arguments, and each argument is one of three types SAP numbers explicitly: 1 = constant, 2 = field in a source structure, 3 = reference ID of another node. Lines chain with AND/OR. At generation time the engine checks each node's conditions and ignores the node when they fail — and if a condition on an upper-level node fails, **all subnodes are skipped with it**. SAP's documentation recommends the pattern deliberately: put one condition on a segment or composite to switch a whole record on or off. Efficient in design, brutal in support — the element you're staring at can be perfect while its grandparent's condition kills it.

## The data underneath: FPAY* structures and REGUH/REGUP

What can a PAYM tree actually map _from_? SAP's data mapping documentation answers structurally: the tree type determines which system structures and tables are available — for PAYM, the FPAY* structures. Its support documentation on modifying PMW formats names them: **FPAYH, FPAYP and FPAYHX**, "so the fields of these structures can be used in the nodes." That's the interface the tree sees — a header-level structure, an item-level structure, and an extension — and it's why the same tree design serves any caller that fills the interface.

The payment run's own tables sit a layer below. SAP's payment-program documentation describes the sequence: the proposal run creates entries in REGUS, REGUH and REGUP; the payment run creates the production entries in **REGUH** (settlement data from the payment program) and **REGUP** (the processed items), and the print/medium step writes **REGUT**, the TemSe administration data whose entries record code page, program name and format. Those tables — where they live and how to read them — are covered in the [treasury tables reference](https://gravam.com/blog/sap-treasury-tables); at file-generation time, the tree maps from the FPAY* transfer structures the engine is called with, and the source field inventory is what presents those fields to you.

That inventory is worth knowing as a concept, because it's the mapping screen's entire vocabulary: per tree type, SAP predefines the possible source fields — application fields, ABAP system fields (system date and the like), technical fields, and, specific to PAYM, **note-to-payee fields** served as an internal table, whose filling depends on the note-to-payee settings in the PMW format Customizing. If a field isn't in the inventory, the standard procedures can't map it — that's the documented boundary where exit modules begin.

## Tree types beyond PAYM

"DMEE" and "payment formats" get used interchangeably, but tree type PAYM is one entry in a documented list. SAP's outgoing-file documentation names, for Financial Accounting alone: **PAYM** (payment program), **UMS1/UMS2/UMS3** (advance return for tax on sales/purchases — differing in summarization: none, per tax code/transaction key, or per your output Customizing), **WTRE** (generic withholding tax reporting via RFIDYYWT), **ASLD** (EC sales list via RFASLD20) and **DEBT** (US 1099-C via RFIDUS99C). Each tree type carries its own source structures — UMS2 maps from RFUMS2_TAX_ITEM, for instance — which is the concrete meaning of "the tree type decides your inventory". If you configure payment formats only, you'll never touch the others; if you support DMEE as a platform, expect a tax tree eventually.

## PMW configuration: the settings that bind tree to payment method

For a PAYM tree to produce anything, SAP documents a specific chain of Customizing (Financial Accounting → Accounts Receivable and Accounts Payable → Business Transactions → Outgoing Payments → Automatic Outgoing Payments → Payment Media → Make Settings for Payment Medium Formats from Payment Medium Workbench):

1. **Create the PMW format** — same name as the DMEE tree, format output "payment medium without docs", type File, and the **Mapping using DME engine** indicator set. Setting that flag is what makes the format a DMEE format; it also surfaces a button that jumps straight into the tree.
2. **Assign the format to the payment method** — in the payment method's settings, set the **Use payment medium workbench** indicator and enter the PMW format name.

SAP's support documentation adds the operational transactions consultants actually type: OBPM1 through OBPM4 for the format definition, note-to-payee, and variant configuration, with the payment medium program SAPFPAYM behind them — and the documented trap that after changing OBPM1/OBPM2/OBPM3 settings, a payment medium run that has already executed once needs report RFPAYM_RESET before the changed Customizing takes effect. For modifying delivered formats, the documented options are two: make a Z-copy of the standard tree in DMEE and change the copy's nodes, or use PMW events in OBPM3 — custom function modules at documented event points (in events 06, 21, 31 and 41 you receive the output of events 05, 20, 30 and 40 in table T_FILE_OUTPUT and can change it). Tree first, events for what the tree can't see, is the maintainable order.

## S/4HANA: DMEEX, and the end of classic DMEE for outgoing files

In S/4HANA the successor transaction is **DMEEX**, the Extended Data Medium Exchange Engine, and SAP's current documentation is unambiguous about the classic tool: as of the 2025 release, **DMEE is obsolete for the outgoing direction**, with a documented process for migrating format trees from DMEE to DMEEX. DMEEX keeps the model — format trees, defined without ABAP coding in a graphical editor, generating flat or XML files — and its documentation currently scopes it to **the PAYM tree type for outgoing files**.

What DMEEX adds, per its documentation, is the maintenance layer classic DMEE never had:

- **Parent–child trees**: copy a delivered tree and register the copy as a child of the original, with **synchronization functions** to distribute parent changes to children — the answer to the oldest DMEE operational problem, Z-copies drifting as SAP updates the original.
- **Breakpoints on nodes**, with standard ABAP debugging during file generation, and **tracepoints** analyzed through the DMEEX Trace Tool (SAP Note 3077367; classic DMEE got its own trace tool via Note 3138271) — built for the two eternal questions, "why is this node missing?" and "why is this value formatted like that?".
- **Post-processing function modules** per format tree — run at the end of format creation, SAP's example being deletion of empty nodes.

If you're building new formats on S/4HANA, build them in DMEEX; if you're carrying classic trees forward, the migration is a documented process, not a re-implementation.

## What I couldn't verify, so it isn't above

Held to the same rule as the rest of the corpus — printed only if a fetched SAP page says it — three things stayed out:

- **The runtime handoff from REGUH/REGUP into FPAYH/FPAYP.** SAP documents both ends — the payment run writing REGUH/REGUP, and PAYM trees mapping from FPAYH/FPAYP/FPAYHX — but none of the pages I fetched states the mechanism that fills the FPAY* structures from the payment tables. The commonly repeated formulation ("SAPFPAYM reads REGUH/REGUP and fills FPAYH/FPAYP") may well be right; I couldn't source it, so it isn't asserted above.
- **SEPA_CT as "the pain.001 tree."** SAP's support documentation lists SEPA_CT among DME-Engine-implemented formats, but the fetched pages don't state which pain.001 version it produces, so no version claim is made here — for the message itself, the [pain.001 field reference](https://gravam.com/blog/pain-001-structure-and-fields) covers the structure bank by bank.
- **A complete tree-type catalogue.** The tree types printed (PAYM, UMS1/2/3, WTRE, ASLD, DEBT) are the ones SAP's outgoing-file documentation describes for FI. Other tree types exist for other components; anything I couldn't find described on a fetched page is omitted rather than listed by hearsay.

And the standing scope note: this reference describes classic DMEE as SAP documents it (SAP ERP EHP8, republished in the S/4HANA sets) and DMEEX as S/4HANA documents it. Which trees your system actually ships, and whether DMEE still opens at all, depends on release and edition — check yours before you promise a bank a format.

***

_See also [SAP payments output management: PMW, BCM and APM](https://gravam.com/blog/sap-bcm-apm-output-management-architecture) and the [SAP treasury transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes)._

## Primary sources

Classic DMEE as documented in SAP ERP EHP8 (Financial Accounting – General Topics), which SAP republishes in the S/4HANA documentation sets; DMEEX per SAP S/4HANA documentation. SAP's S/4HANA 2025 documentation declares classic DMEE obsolete for the outgoing direction — verify the tool and the delivered trees against your release and edition.

- SAP Help — Data Medium Exchange Engine (SAP S/4HANA, Accounting and Financial Close) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/8fbeed5f2046489696a50ac7fd76f9c6/7aa4c2531bb9b44ce10000000a174cb4.html
- SAP Help — Outgoing File (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/4dd34ba891d96599e10000000a15822b.html
- SAP Help — Creating Format Trees (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/408ad0531d8b4208e10000000a174cb4.html
- SAP Help — Node Types for Flat Files (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/0d8ad0531d8b4208e10000000a174cb4.html
- SAP Help — Node Types for XML Files (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/4e8ad0531d8b4208e10000000a174cb4.html
- SAP Help — Data Mapping (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/cb337e50f9f38d12e10000000a44176d.html
- SAP Help — Mapping Outgoing Files (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/488ad0531d8b4208e10000000a174cb4.html
- SAP Help — Source/Target Field Inventory (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/fe89d0531d8b4208e10000000a174cb4.html
- SAP Help — Aggregation (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/a289d0531d8b4208e10000000a174cb4.html
- SAP Help — Conditions (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/1f8ad0531d8b4208e10000000a174cb4.html
- SAP Help — Exit Modules (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/018ad0531d8b4208e10000000a174cb4.html
- SAP Help — Customizing Payment Methods for Use with DMEE (SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/c289d0531d8b4208e10000000a174cb4.html
- SAP Help — Payment Medium Workbench (SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/7e3ac6535e601e4be10000000a174cb4.html
- SAP Help — UMS1, UMS2, and UMS3 Tree Types (DMEE, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/6a49d1604ffc4b908f9f78fba3824187/ea89d0531d8b4208e10000000a174cb4.html
- SAP Help — Extended Data Medium Exchange Engine (DMEEX, SAP S/4HANA) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/d93424d8ff23402f80ac55a4cad80270/56e7df0d667146078398539a65670bf9.html
- SAP Support Content — PMW: General Information and DMEE or DMEEX — accessed 2026-08-03 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361880730.html
- SAP Support Content — Modifying Standard PMW Formats — accessed 2026-08-03 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361878619.html
- SAP Support Content — General Procedures and Tables in Automatic Payment Run — accessed 2026-08-03 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361878657.html

## Questions this article answers

**Q: What is the difference between DMEE and DMEEX in SAP S/4HANA?**

Same job, newer engine. DMEEX (the Extended Data Medium Exchange Engine) is the S/4HANA transaction for defining file formats as format trees, and SAP's documentation adds capabilities classic DMEE never had: copying a delivered tree as a child of the original with a parent–child hierarchy, synchronization functions to push parent changes to child trees, breakpoints and tracepoints on individual nodes for debugging file generation, and post-processing function modules that run at the end of format creation — for example to delete empty nodes. SAP's S/4HANA 2025 documentation is blunt about the direction: classic DMEE is obsolete for the outgoing direction, and there is a documented migration process for moving format trees from DMEE to DMEEX. DMEEX currently handles the PAYM tree type for outgoing files.

**Q: What is an atom in a DMEE format tree?**

A sub-node you create under an element when one mapping rule isn't enough. SAP documents two uses: outputting more than one value into a single element, and controlling which value is output to an element based on conditions. The pattern in practice: set the element's mapping procedure to 'Own mapping (atoms)', create one atom per candidate source, give each atom its own mapping procedure and a condition, and the engine picks whichever atom's condition is met at generation time. It's how a single field in the file — a payee identifier, say — can come from different source fields depending on the payment.

**Q: Which structures does a DMEE payment format tree read its data from?**

For tree type PAYM, SAP's data mapping documentation says the FPAY* structures are what the tree type makes available, and its support documentation on modifying PMW formats names them: FPAYH, FPAYP, and FPAYHX — so the fields of these structures are what you can use in the nodes. They form the source field inventory the DMEE mapping screen offers you, alongside ABAP system fields, technical fields, and — specific to PAYM — note-to-payee fields whose behaviour depends on the Payment Medium Workbench format Customizing. The payment run's own tables are separate: F110 writes REGUH (settlement data) and REGUP (processed items) when it executes.

**Q: Why is a node missing from the DMEE output file?**

Check its conditions first, then the conditions above it. SAP's documentation is explicit that when a file is generated the engine checks each node's conditions and simply ignores the node when they aren't met — and that if a condition on an upper-level node like a segment or composite fails, all of its subnodes are skipped with it. So an element can be mapped perfectly and still vanish because a segment three levels up compared a field against the wrong constant. For systematic cases, SAP ships a DMEE Trace Tool (SAP Note 3138271, and 3077367 for DMEEX) built for exactly these questions — why a node or level is missing, or why a value arrives formatted differently than expected.

---

# SAP Electronic Bank Statement: Posting Rules and Algorithms

Source: https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-08-03
Updated: 2026-09-25
Reviewed: 2026-09-26
Summary: How SAP electronic bank statement (EBS) processing imports, posts and clears, and the config behind it: transaction codes, posting rules, algorithms.

**Electronic bank statement (EBS) processing in SAP imports bank statements — MT940, camt.053 and the like — and automatically interprets and posts them, mapping each transaction to the right accounting and clearing the matching open items. Underneath, every implementation is the same four configuration objects: external transaction codes, posting rules with their posting specifications, account symbols, and interpretation algorithms — plus search strings for when the algorithms aren't enough.** EBS is where a huge amount of a treasury's daily value lives, and where a huge amount of configuration pain lives, and they're the _same place_. Get the posting rules right and the statement posts and clears itself every morning while everyone sleeps. Get them wrong and someone spends their day in post-processing, hand-matching what the system should have done.

This page starts with what the pipeline does, then goes down to configuration level — the part you want open when you're actually in the IMG. It follows the house method: search for this topic and you'll find forum threads listing algorithm numbers nobody can source, so every config object, algorithm number and behaviour below is checked against SAP's own documentation, and the ones I couldn't verify are named at the end rather than silently included.

## What EBS does

Without EBS, someone reads the bank statement and keys the transactions — slow, error-prone, and unthinkable at scale. EBS automates the whole chain:

1. **Import** the statement, in a [standard format](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) — [MT940](https://gravam.com/blog/mt940-format-tags-explained), [camt.053](https://gravam.com/blog/camt-053-structure-and-fields), [BAI2](https://gravam.com/blog/bai2-file-format-explained).
2. **Interpret** each transaction — work out what it is and how it should post.
3. **Post** to the general ledger and subledgers.
4. **Clear** the matching open items (the outgoing payment, the incoming receipt).

Whatever fails a step lands in **post-processing**, where a person finishes the job. Done well, most of a statement flows through all four steps untouched. The rest of this page is about the configuration that decides which lines do.

> **Figure — A bank statement going through SAP's electronic bank statement processing**
>
> A bank statement enters EBS, drawn as a machine with four numbered steps: import, interpret, post and clear. Two arrows leave it. One goes to a ledger marked with a tick, labelled cleared. The other goes to a tray holding a single sheet, labelled post-processing.
>
> Four steps, and one exit for whatever fails one of them: post-processing, where a person finishes the job.

## The chain, end to end

SAP's documentation describes the determination as a search sequence, and it's worth memorising because every "why did it post there?" investigation walks it backwards:

1. From the **bank key and bank account** on the statement, the system finds the **transaction type** in the Customizing table.
2. From the transaction type plus the **external transaction code** — the bank's business transaction code on the statement line — it determines the **posting rule** key.
3. From the posting rule, it reads the **posting specifications** and the **account determination** you configured.

Separately, the interpretation algorithm assigned to that external transaction decides how the note to payee is searched for **clearing** information — document numbers, reference numbers, check numbers. Posting and clearing are different problems, and the config treats them as such.

All of it lives in one place: Customizing for Bank Accounting, under Business Transactions → Payment Transactions → Electronic Bank Statement → **Make Global Settings for the Electronic Bank Statement**. Per SAP's Defining Posting Rules page, that activity is where you create the account symbols, define the account determination per symbol, and create the posting specifications for the two posting areas.

## External transaction codes: what the bank sends

SAP defines external transactions — also called business transaction codes — as bank-specific codes for business transactions, each representing a different type of payment. The bank puts them on the statement; the system uses them to identify what the line _is_, and converts them to its own internal posting rules. SAP's documented examples: 020 transfer order, 051 transfer credit memo, 052 recurring entry credit memo, 072 bill of exchange presentation, 206 foreign bank transfer. What actually arrives depends on the format — the code sits in the statement line of an [MT940](https://gravam.com/blog/mt940-format-tags-explained) or a [camt.053](https://gravam.com/blog/camt-053-structure-and-fields) — and, more importantly, on the bank's own dialect, which is why the mapping is maintained per transaction type rather than globally.

Two details from the assignment activity that carry real weight:

- **The +/- sign.** External codes are differentiated by sign: `+` marks a cash receipt, `-` a disbursement. Plenty of banks reuse one code for both directions, and this is the mechanism that splits them into different posting rules.
- **The interpretation algorithm is assigned here too.** The mapping row isn't just code → rule; it's code → rule → algorithm. Choosing the algorithm per external transaction is the design decision, not an afterthought.

The completeness of this mapping is the single biggest lever on EBS success. Every transaction type your accounts see needs a rule, and the ones without one are exactly the items that drop to manual post-processing every day. Map what your banks actually send — not what the standard config assumes they send.

## Posting rules and the two posting areas

A posting rule specifies how a business transaction from the statement posts in your system, and each rule can carry **two sets of posting specifications**:

- **Posting area 1** — G/L account (or bank account) postings.
- **Posting area 2** — subledger postings.

You define one or both, depending on what the transaction needs. SAP's own example is the cleanest explanation I know: a **check credit memo** needs only posting area 1, because the customer item was cleared when the check was deposited; an incoming **bank transfer** needs posting area 2 as well, so the system can clear the customer's open item. The documentation's process description makes the same point as a two-level posting: cash receipt to a clearing account first (the bank posting), then locate the customer and clear the item (the subledger posting).

A posting specification itself is small: posting key and account symbol for one or two line items — a debit and a credit entry. That's it. The complexity of an EBS implementation is not in any single rule; it's in having a correct rule for everything your banks actually send.

## Account symbols: the indirection that makes it portable

Posting specifications never name G/L accounts directly — they name **account symbols**, and the system replaces the symbol with the right account at posting time. SAP's example is an account symbol `BANK` standing in for account 113100. You define the symbols yourself in Customizing and define account determination rules for each.

The prerequisite chain matters more than it looks: account symbols resolve against the house bank setup, so every account you hold at a house bank needs a G/L account in the system, and the currency key in that G/L account's master record must match the currency of the actual bank account. SAP's documentation carries an explicit caution here — if a house bank account has no G/L account, the system cannot post the electronic statement at all. It is an easy miss to make at the start of a test cycle: the rules are fine, the symbols are fine, and one new bank account has no G/L account behind it.

> When a posting lands on the wrong account, resist the urge to start editing posting rules. Walk the documented sequence instead: which transaction type did the bank key resolve to, which posting rule did the external code map to, and which account did the symbol resolve to for that chart of accounts. More often than not the rule is right and the symbol's account assignment — or the house bank data under it — is what's wrong.

## Interpretation algorithms: the documented list

Posting answers "which accounts"; interpretation answers "which open item". The note to payee fields of the statement carry document numbers, reference document numbers or check numbers, and the interpretation algorithm determines how the system reads them. One warning from SAP's documentation before the list, because it explains half of all interpretation failures: the information must already be known to the system **in exactly the same form and with exactly the same number of characters** — leading zeros included. Bank statement data that is _almost_ the reference number finds nothing.

These are the algorithms SAP's documentation describes, with the documented behaviour. Numbers you may have seen elsewhere that are not in this table are covered in the exclusions section — I only print what I could verify.

| Algorithm | SAP's name | Documented behaviour |
| --- | --- | --- |
| 000 | No interpretation | Standard interpretation off — for when you use your own algorithms via functional enhancements (user exits) instead |
| 001 | Standard algorithm | Reads note-to-payee values as document or reference document numbers, checks them against the BELNR/XBLNR intervals entered at statement import, and only then searches for items to clear |
| 011 | Outgoing check, check number not identical to document number | For pre-numbered checks: the bank returns the check number, the algorithm finds the document number from it |
| 012 | Outgoing check, check number identical to document number | For checks printed without pre-printed numbers, where the document number serves as check number; needs the document number ranges at import, like 001 |
| 013 | Outgoing check, identical or not identical | Finds the check number per algorithm 011 or 012, whichever applies |
| 015 | Clearing transaction: selection via assignment number | Selects items to clear by assignment number if the rule permits clearing; otherwise writes the bank reference into the assignment of the posting on account, for later automatic clearing via report SAPF123W |
| 019 | DME administration reference number | For statement lines confirming a payment run total: finds the DME reference in the note to payee and uses it to find and clear all line items of that payment medium |
| 020 | Document number search | Like 001, but interprets note-to-payee content as document numbers only |
| 021 | Reference document number search | Like 001, but reference document numbers only |
| 022 | BZÜ method with document number (Germany) | Reads the 13-digit BZÜ coding-line number, cuts the check digit, interprets the rest right-aligned as a document number |
| 023 | BZÜ method with reference document number (Germany) | Interprets the BZÜ number, including its check digit, as a reference document number |
| 026 | Reference number with leading zeros | For ten-digit references arriving without leading zeros: reads candidates like 021, pads to ten digits with leading zeros, then compares |
| 027 | Reference number TITO | Searches for the payment reference of the Finnish TITO statement format |
| 028 | Reference number per MultiCash conversion | Same as 027 for files imported in MultiCash format, using the BELNR number range |
| 029 | Payment order number | Searches by payment order number, using the XBELNR number range |
| 030 | Brazil | For Brazilian statements: searches for document number, fiscal year and line item number within the accounting document |
| 031 | Document number search, customer number in line item | Works like 020, plus: can add customer bank details from the statement to master data, and is the algorithm under the payment advice notes the import creates when it can't clear everything — items for several partners only auto-assign correctly with 031 |
| 120 | Document number search with no check | Searches by document number without checking the document exists — only that it's inside the import number range; documented as the way to clear open items in a different bank company code |
| 121 | Reference document number search with no check | The 120 behaviour for reference document numbers only |

A few reality notes on the ones that generate the support tickets:

- **001 (and 012, 020, 021) fail quietly when nobody fills the number ranges.** The intervals for document and reference document numbers are entered on the _import_ selection screen — a runtime input, not a config setting. An import variant without them turns the standard algorithm into a no-op, and the symptom is "EBS posts but never clears".
- **015 is the pragmatic fallback** when the statement carries no usable document reference: post on account with the bank reference in the assignment field, clear later via SAPF123W. The documented catch is that the assignment is a text field fed from the bank reference or the start of the note to payee — if that field doesn't carry what you think it carries, check before building a process on it. SAP's documented escape is the customer exit that fills the check number field (FEBEP-CHECT) — one of the [FEBEP](https://gravam.com/blog/sap-treasury-tables) fields this whole machinery reads and writes.
- **031 over 021 for mixed remittances.** Where one statement line pays documents of several business partners, SAP documents that only 031 assigns the payment advice items to the right partners automatically; with 021 you correct them by hand.
- **The set still grows, by localization.** SAP S/4HANA Cloud Public Edition 2508 added algorithm 805, which filters open bank statement items by Polish KSeF reference numbers from the memo line — assigned in the same Assign External Transactions step as everything else. If you work in a localized environment, check the release notes for your country before concluding the standard set is all there is.

## Search strings: the escape hatch

The algorithms all share one documented assumption: the reference arrives **unchanged**. SAP's documentation is blunt about the failure mode — if figures or characters have been added or removed from the document number, the algorithms cannot find it, and the transaction goes to manual post-processing. Its examples are exactly what you see in real statements: customers dropping a constant leading `18000` from invoice numbers, splitting numbers with spaces, periods or dashes (`540 6423`, `6.032946`, `60-67132`), or burying the reference in `001*0050*0000851333`.

**Search strings** supplement the interpretation algorithms for that case, without programming. Three parts, per the documentation:

- **The search string** — a pattern that recognises the mangled reference. It can be any length and mixes literal characters with pattern characters: `|` for alternation, `( )` for grouping, `+` and `*` for repetition, `?` as a single-character wildcard, `#` for any digit 0–9, `\` to escape a special character, `^` and `$` for start and end of line.
- **The mapping string** — a character-by-character transformation that strips or replaces the excess, reconstructing the actual document number from what the pattern matched. If nothing needs replacing, search and mapping strings are identical, and the system proposes the search string as the default mapping.
- **Test and simulate.** You can test an individual search/mapping string against a value, and — the part worth building into your cutover plan — simulate a whole set of definitions against statement imports, comparing what posted automatically before and after. That turns search-string tuning from folklore into a measurable loop: define, simulate, adjust, until items that fell out post automatically.

The Customizing activities SAP names for this are Define Search String for Document Numbers and Simulate Document Number Search Using Strings, in Customizing for Bank Accounting. My working rule: exhaust the standard algorithms first, reach for search strings when the diagnosis is specifically "the reference is there but deformed" — and treat every search string as a small program that deserves the simulation step before it goes anywhere near production.

Everything the algorithms and search strings fail to clear lands in post-processing, and that queue is the step worth redesigning rather than staffing. The queue has its own page — [FEBAN post-processing](https://gravam.com/blog/feban-bank-statement-post-processing) covers how to work it in FEBAN, FEB_BSPROC or the Fiori app and how to shrink it by cause; this page stays with the configuration that decides what lands there. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) takes it apart the same way this chain does: what stays deterministic (the algorithm's own rules — amount, reference, tolerance), what an AI step can read (the note-to-payee text no search string anticipated), and what stays with a named human (the clearing decision on the residue).

## Auto-clear is the metric

Posting is the easier half; **clearing** is where EBS earns its keep, and where data quality bites. If the reference the bank returns doesn't carry a clean match key, the item posts but doesn't clear, and someone reconciles it by hand. The [virtual-account](https://gravam.com/blog/virtual-account-management-structures) and reference-discipline tricks from the cash-management side are, in large part, about making auto-clear actually work.

So the measure of a good EBS setup is its **auto-post and auto-clear rate** — how much of the statement flows through without a human. That's [straight-through processing](https://gravam.com/blog/straight-through-processing-in-treasury) applied to bank statements, and every manual item is a small tax of effort and error. Improving EBS is the ongoing work of pushing that rate up: mapping the external codes that keep falling out, tightening the search strings, fixing the reference data upstream. And note what the rate really measures: everything it does not clear becomes somebody's queue, and a workflow is only as good as [the path it gives those exceptions](https://gravam.com/blog/designing-the-exception-path).

## Monitor it like any interface

The bank statement is a feed, and feeds fail silently. A statement that doesn't arrive, or arrives for only some accounts, produces a wrong or incomplete cash picture without any error. EBS needs the same [interface monitoring](https://gravam.com/blog/interface-monitoring-and-reconciliation) as any treasury integration: confirm a statement came in from every account, every day, and alert when one didn't. A missing statement is a hole in the position, and it doesn't announce itself.

## Why bank statement items drop to manual

- **Incomplete external-code mapping.** Bank transaction types with no posting rule, so they drop to manual every day.
- **Missing house bank G/L accounts.** One new bank account without a G/L account behind it, and the statement can't post at all.
- **Poor auto-clear.** Weak or missing payment references and untested search strings, so items post but don't clear.
- **Standard config assumptions.** Assuming the bank sends what the template expects, when real banks vary.
- **No feed monitoring.** Not checking that a statement arrived from every account, so a missing one silently understates cash.

## What I couldn't verify, and left out

Same discipline as the rest of this [SAP treasury guide](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) — the gaps are named, not papered over:

- **Algorithms 040 and 041.** SAP's page references algorithm 040 without describing it, and describes 041 ("Treasury: Search for loan, then standard search") only as the reverse order of 040. A description defined relative to an undescribed sibling isn't something I'll print as behaviour, so both stay off the table above.
- **Forum-circulated algorithm numbers.** Numbers you'll find in threads and slide decks that are not on SAP's Interpretation Algorithms page are not listed here. That's not a claim they never existed in some release — only that SAP's current documentation, which is my bar, doesn't describe them.
- **Search strings targeting other fields.** Consultant lore says search strings can also derive posting rules, cost centers and other fields from note-to-payee text. The SAP Help pages I could fetch document the document-number string search; I couldn't verify the broader target-field mechanism there, so it's excluded rather than asserted.
- **Configuration transaction codes.** The IMG activity names above are documented; specific config tcodes for them are not printed because the pages I verified don't name them. The runtime codes — FF.5 to import, FEBA_BANK_STATEMENT to post-process — are covered in the [transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes).
- **S/4HANA versus ECC differences.** The interpretation algorithms documentation in the S/4HANA Financial Operations set is the same document SAP published for SAP ERP, and I found no documented behavioural difference in these config objects between the two — the documented movement is additive and localized, like Cloud's algorithm 805. Absence of documented difference isn't proof of identical behaviour in your release; it's the reason the scope note on this page says verify against yours.

The config objects on this page are small and old and stable — a mapping table, two posting areas, a list of algorithms, a pattern matcher. What makes EBS configuration hard was never the objects; it's that the statement data they run against is someone else's export. Which is why the two ends of the chain deserve most of your attention: the external-code mapping at the front, against what your banks [actually send](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2), and the interpretation settings at the back, against how your customers actually write reference numbers. Get those two honest, and the middle of the chain mostly just works.

***

_See also [SAP bank account management](https://gravam.com/blog/sap-bank-account-management-s4hana) and [SAP treasury tables](https://gravam.com/blog/sap-treasury-tables)._

## Primary sources

Configuration objects as documented in SAP's Bank Accounting (FI-BL) documentation, which SAP republishes in the S/4HANA Financial Operations documentation set. Verify against your release and edition — SAP S/4HANA Cloud Public Edition extends the algorithm set through release updates (e.g. algorithm 805 in 2508).

- SAP Help — Electronic Bank Statement (FI-BL, SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/94c6440a9b80427d9292651d32634b0d.html
- SAP Help — Defining Posting Rules (Bank Accounting, FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/1761d0531d8b4208e10000000a174cb4.html
- SAP Help — Posting Specifications and Account Determination (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/ed60d0531d8b4208e10000000a174cb4.html
- SAP Help — Account Symbols and Account Assignment (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/fc60d0531d8b4208e10000000a174cb4.html
- SAP Help — External Transactions (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/e660d0531d8b4208e10000000a174cb4.html
- SAP Help — Assigning External Transactions (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/1461d0531d8b4208e10000000a174cb4.html
- SAP Help — Interpretation Algorithms (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/4dc5efb40c381c36e10000000a42189b.html
- SAP Help — Interpreting the Note to Payee Fields (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/4dc15dc6e3062cc0e10000000a42189b.html
- SAP Help — Electronic Account Statement: Posting and Clearing (FI-BL) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/05dc2c5c52894be09936e58818161108/4dc9159f44cf0b63e10000000a42189b.html
- SAP Help — String Search for Document Numbers (FI-BL, SAP ERP EHP8) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_ERP/daf0f4e552e248d0bf0db2bb5f322192/5061d0531d8b4208e10000000a174cb4.html
- SAP Help — Interpretation Algorithms (SAP S/4HANA Financial Operations) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/4dc5efb40c381c36e10000000a42189b-2488.html
- SAP Help — Interpretation Algorithm for KSeF Reference Numbers (What's New in SAP S/4HANA Cloud Public Edition 2508) — accessed 2026-08-03 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/3329c9d695224f4eb67a7a8b540e27d6.html

## Questions this article answers

**Q: What is electronic bank statement processing in SAP?**

Electronic bank statement (EBS) processing in SAP is the import and automatic handling of bank statements — typically in formats like MT940 or camt.053 — so that each transaction on the statement is interpreted, posted to the correct accounts, and matched against open items. Rather than someone keying bank transactions by hand, EBS reads the statement, applies configured rules to determine the accounting for each line, posts to the general ledger and subledgers, and clears the corresponding open items where it can.

**Q: How does SAP decide how to post a bank statement item?**

Through configuration that maps each type of bank transaction to accounting treatment. The bank identifies transaction types on the statement (external transaction codes), and SAP configuration links those to posting rules that define the accounts and postings to generate — using account symbols so the rules are independent of specific G/L accounts. Interpretation algorithms and search strings then find the open items to clear. Getting this mapping complete and correct is what determines how much of the statement posts and clears automatically versus dropping to manual post-processing.

**Q: What is straight-through processing for bank statements?**

Straight-through processing for bank statements is the goal of having as much of the statement as possible post and clear automatically, without manual intervention. A well-configured EBS setup interprets each transaction, posts it, and matches it to the right open item on its own, so only genuine exceptions fall to a person. A poorly-configured one leaves large volumes in post-processing, which is slow and error-prone. The auto-post and auto-clear rate is a direct measure of how well the bank-statement configuration and the underlying data quality are working.

**Q: What is the difference between posting area 1 and posting area 2 in SAP EBS?**

Posting area 1 holds the posting specifications for G/L and bank account postings; posting area 2 holds the specifications for subledger postings. Each posting rule carries one or both, depending on what the transaction needs — SAP's own example is that a check credit memo needs only posting area 1, because the customer item was already cleared when the check was deposited, while an incoming bank transfer needs posting area 2 as well, so the system can find the customer and clear the open item. In practice, area 1 is where cash hits the bank and clearing accounts, and area 2 is where the receivable or payable actually closes.

**Q: Where do you assign an interpretation algorithm to a posting rule?**

In the same configuration activity where external transaction codes are mapped: Assign External Transactions to Posting Rules, inside Make Global Settings for the Electronic Bank Statement in Customizing for Bank Accounting. For each external transaction code — differentiated by a plus sign for cash receipts and a minus sign for disbursements — you enter the posting rule and the interpretation algorithm. The algorithm setting determines whether, and with which logic, the system searches the note to payee lines of that transaction for clearing information.

**Q: Why does interpretation algorithm 001 find no documents?**

Usually because of the number intervals, not the algorithm. Algorithm 001 interprets note-to-payee values as document or reference document numbers, but it checks them against the BELNR and XBLNR number ranges entered on the selection screen when the statement is imported — if those intervals are missing or wrong, nothing matches. The second documented trap is leading zeros: if the reference was stored in the system with leading zeros, the statement must deliver it with those zeros, in exactly the same form and length, or the item will not be found.

**Q: When should you use a search string instead of an interpretation algorithm in SAP EBS?**

When the reference information arrives changed. Interpretation algorithms need the document number transmitted unchanged; SAP's documentation is explicit that if characters have been added or removed, the algorithms cannot find the document. Search strings supplement the algorithms for exactly that case — customers who drop leading digits, split numbers with spaces or periods, or wrap the reference in other text. You define a search string with pattern characters to recognise the mangled number, a mapping string to reconstruct the real one, and you can test and simulate the definitions against imported statements before relying on them.

---

# SAP TRM Product Types and Transaction Types, Explained

Source: https://gravam.com/blog/sap-trm-product-types-and-transaction-types
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-08-02
Reviewed: 2026-08-02
Summary: How SAP Treasury classifies deals: fixed product categories, configurable product types like 51A and 60A, transaction types, and the layers below.

**Every deal in SAP Treasury is classified before it is captured, and the classification has three layers: the product category (fixed by SAP — 550 Interest Rate Instrument, 600 FX Transaction, 040 Bond), the product type (yours to configure — 51A Fixed-Term Deposit, 60A Foreign Exchange), and the transaction type (what you're doing under that product type — 100 Investment, 200 Borrowing, 101 Spot, 102 Forward).** Underneath sit flow types and update types, classifying every movement the deal generates. That's the whole model, and this page walks down it layer by layer — with the delivered codes checked against SAP's documentation, because this is a corner of TRM where forum lore and real configuration have drifted apart.

Why it's worth a page of its own: the classification is not labeling. It's the key everything downstream reads. Which activity chain the deal walks through, which flows it may carry, how its [position updates, how it posts](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture), whether it can be excluded from a valuation area, even which planning level it lands on in Cash Management — all of it is configured against product category, product type and transaction type. When the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) takes a deal from capture to accounting, this classification is the thread it follows. And it's chosen in the first seconds of the deal's life: before you can enter a single amount in [FTR_CREATE](https://gravam.com/blog/sap-treasury-transaction-codes), you've picked a product type and a transaction type — SAP's documentation lists defined product types, transaction types, flow types and condition types as prerequisites for creating financial transactions at all.

## The three layers at a glance

| Layer | Who defines it | What it does | Verified examples |
| --- | --- | --- | --- |
| **Product category** | SAP — predefined, you can't add to it | Classifies the kind of instrument; controls its processing | 550 Interest Rate Instrument, 600 FX Transaction |
| **Product type** | You, in configuration (SAP delivers examples) | Segments a category to company-specific requirements | 51A Fixed-Term Deposit, 60A Foreign Exchange |
| **Transaction type** | You, assigned to your product types | Determines how the transaction is processed; groups directions | 100 Investment / 200 Borrowing, 101 Spot / 102 Forward |

The textbook mnemonic: SAP owns the nouns, you own the vocabulary. The categories are the fixed set of things a treasury system can conceptually hold; the product types are your names for the ones you actually trade; the transaction types are the verbs — invest, borrow, buy, sell, spot, forward — allowed on each.

## Product categories: SAP's layer, and it's numbered

SAP's definition is compact: the product category is "a predetermined classification of the financial products in the transaction management" — an internal key, predefined in the system, and "the product category controls the processing of the financial instruments created based on the product types." You assign each product type to exactly one category; the categories themselves are not yours to extend.

They come as numbered families, and the numbering is worth learning because you'll meet it in configuration and in the [database tables](https://gravam.com/blog/sap-treasury-tables) alike. From SAP's S/4HANA documentation, the available categories include:

- **Money market** — 530 Commercial Paper, 540 Cash Flow Transaction, 550 Interest Rate Instrument, 560 Facility, 580 Current Account-Style Instrument
- **Foreign exchange** — 600 FX Transaction (with 760 OTC Options listed for the FX area too)
- **Securities** — 010 Stock, 020 Fund, 030 Subscription Right, 040 Bond, 042 Installment Bond, 060 Bond with Warrant, 070 Convertible Bond, 111–114 warrant categories, 160 Shareholding
- **OTC derivatives** — 610 Cap and Floor, 620 Swap, 630 Forward Rate Agreement, 640 Total Return Swap, 740 Forward Securities Transaction, 760 OTC Option, 770 Securities Lending, 780 Forward, 790 Forward Loan
- **Listed derivatives** — 700 Future, 750 Listed Options
- **Trade finance** — 850 Letter of Credit, 860 Bank Guarantee
- **Special** — 690 External Account, plus 990 Exposure and 991 Exposure Item for Exposure Management and hedge accounting

One reality check that surprised me while verifying: the list is **edition-dependent**. SAP's S/4HANA Cloud Public Edition documentation publishes a visibly shorter set — the securities family stops at 160 Shareholding with no warrant or convertible categories, and the derivatives family is essentially 620 Swap and 760 OTC Options. Same concept, smaller menu. If your instrument isn't in your edition's category list, no amount of configuration will book it, which makes this one of the first pages to check in a [deployment-model decision](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison).

Above the categories sits one more key you'll trip over in flow-type configuration: the **contract type**, an internal key for the application areas themselves — 2 securities, 4 foreign exchange, 5 money market, 6 derivatives, T trade finance, plus E for exposure positions and X for external accounts. File it away; it comes back in a moment.

## Product types: your layer, with SAP's examples in the box

SAP's own definition, from the current Cloud documentation: "Product types are used to further segment financial instruments assigned to a product category according to company-specific requirements. Each product type is assigned to exactly one product category." The product type is where you hang the structural characteristics — which condition types and flow types the instrument carries — and control parameters for transaction management, "such as processing categories and status transfers." The on-premise terms documentation gives the canonical example of what "segment to company requirements" means: splitting stock into domestic stock and foreign stock.

You don't start from nothing. The ERP documentation says it plainly — "Alternatively, you can use the product types provided by SAP" — and the S/4HANA Cloud documentation publishes the delivered list outright: 33 predefined product types. A representative cut, verbatim from that table:

| Product type | Product category | Area |
| --- | --- | --- |
| 51A Fixed-Term Deposit | 550 Interest Rate Instrument | Money market |
| 53A Commercial Paper | 530 Commercial Paper | Money market |
| 55A Interest Rate Instrument | 550 Interest Rate Instrument | Money market |
| 58A Current Account-Style Instr. | 580 Current Account-Style Instrument | Money market |
| 60A Foreign Exchange | 600 FX Transaction | Foreign exchange |
| 60B Non-Deliverable Forward | 600 FX Transaction | Foreign exchange |
| 62A Interest Rate Swap | 620 Swap | OTC derivatives |
| 62B Cross-Currency Interest Swap | 620 Swap | OTC derivatives |
| 76A OTC Currency Option | 760 OTC Option | OTC derivatives |
| 01A Stock | 010 Stock | Securities |
| 04A Bonds | 040 Bond | Securities |
| 85A Normal Letter of Credit | 850 Letter of Credit | Trade finance |
| 86A Bank Guarantee | 860 Bank Guarantee | Trade finance |

Read the codes against the categories and the naming convention shows itself: the delivered product type usually takes the leading digits of its category — 53A under 530, 60A under 600, 62A under 620, 04A under 040. Usually, not always: 51A Fixed-Term Deposit and 52B Deposit at Notice both sit under category 550 Interest Rate Instrument in the current table, a fossil of instrument history that's worth knowing precisely because it breaks the pattern people assume. Two other delivered families worth noting from the same page: the intercompany-flavored types with an "- INT" suffix (60I, 60J, 55I, 58I), and the special-purpose ones — product types for exposures under category 990/991, and 20A Bank Account under category 200 for Bank Account Management, which is how even bank accounts get positions in the treasury machinery.

The delivered examples above are the Cloud edition's published list. On-premise systems ship standard-delivery product types the same way, but I couldn't find a page in the current on-premise documentation that publishes the full delivered table — so what's printed here is what's verifiable, and your system's own configuration is the authority for the rest.

## Transaction types: what you're allowed to do with it

A product type alone doesn't make a deal — SAP's FX configuration documentation ends its product-type definition with exactly that: "The financial transaction is finally set up by combining the product type with a transaction type."

The definition stack has a subtlety here that the forum explanations flatten. There is a predefined layer even inside this: the **transaction category** — fixed in the system per product category, e.g. fixed-term deposit investment versus fixed-term deposit borrowing — and then the **transaction type**, which "determines how a financial transaction is processed" and can "group transaction categories according to company-specific requirements." In other words: SAP predefines that an interest rate instrument can be invested or borrowed; you define the transaction types that expose those directions to your dealers. The configuration activities say it directly: "you define your transaction types and assign them to your product types," and specify with them the administrative functions and processes each combination supports.

The delivered examples SAP names, again verbatim from its intercompany-trading documentation:

- **60I Foreign Exchange - INT** with transaction types **101 Spot Transaction** and **102 Forward Transaction** — also used, as 101/102, for FX swaps
- **60J Non-Deliverable Forward - INT** with transaction type **110 Non-Deliverable Forward**
- **55I Interest Rate Instrument - INT** with transaction types **100 Investment** / **200 Borrowing**
- **58I Current Account-Style Instrument - INT** with transaction type **300 Investment/Borrowing**

That's the shape to remember even outside the intercompany context: FX transaction types distinguish spot from forward; money market transaction types distinguish investment from borrowing; and where a single position can run both ways, one combined type (300) covers it.

One more thing rides on the transaction type, and it's the consequential one: the **processing category**. SAP's terms documentation puts it in one sentence — "the processing category assigned in the transaction type definition decides on the activity chain of a financial transaction." Whether a deal goes through order and contract stages, whether it needs settlement — that's the activity chain, and it's fixed the moment the transaction type is chosen. The same field even polices intercompany mirroring: SAP requires that a mirror transaction's transaction type have "the same processing category" as the original. When back-office people argue about why one deal type demands settlement and another doesn't, this is the field they're arguing about, whether they know it or not.

## The layer below: flow types and update types, briefly

Deals generate flows — "flows document changes to the transactions," carrying date, amount and calculation data — and the classification continues down into them. Two type systems, one gotcha each:

- **Flow types** classify a transaction's flows: each flow has exactly one, defined in configuration along with characteristics like posting relevance and inclusion in cash management. The gotcha, straight from SAP's documentation: a flow type is only unique per contract type — "flow type 1000 for contract type 2 is different from flow type 1000 for contract type 4." The same four digits mean different things in securities and FX. If you're comparing flow-type configuration across product areas, you are not comparing like with like. Assignment is per deal classification: to the transaction types of your product types you assign "all flow types necessary for a complete portrayal of the financial instruments" — SAP's phrase, and a good bar for completeness testing.
- **Update types** classify the flows that update positions in parallel position management — and their definition, unlike flow types, "is not limited to the contract type." They're the currency of the [position management and valuation](https://gravam.com/blog/sap-trm-position-management-and-valuation) layer: flow types map to update types in configuration, update types get flagged as posting-relevant and payment-relevant, and position updates are assigned per product type and transaction type — an update type for open and close transactions for each combination. SAP's example update type is worth quoting for flavor: V152, "one-step rate/price valuation: write-up foreign exchange." Where update types go from there — posting specifications, account symbols, G/L accounts — is the [posting architecture's](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) story, not this page's.

## What the classification drives downstream

Everything. But concretely, these are configuration activities SAP documents that key on the classification you chose at capture:

- **The activity chain** — via the processing category on the transaction type, as above.
- **Position updates** — update types for open/close assigned per product type and transaction type.
- **Default valuation class** — a general valuation class assigned "for each combination of company code, product type, and transaction type," defaulted onto the deal at entry.
- **Valuation-area scope and posting scope** — product groups, categories and types can be excluded from parallel valuation areas, and product types excluded from the Financial Accounting update per valuation area and accounting code.
- **Cash Management integration** — planning levels assigned per company code, product type and activity, or derived by substitution rules.
- **Credit risk** — limit product groups "group different product and transaction types" for limit utilization, and product categories drive the default risk data of financial objects.

That list is why I called the classification the backbone: change a product type after go-live and you're not renaming a label, you're re-keying half a dozen downstream determinations — and the deals already captured keep the old key, sitting in [VTBFHA](https://gravam.com/blog/sap-treasury-tables) with their product type and transaction type stamped on them. The practical discipline that follows: resist product-type proliferation. Every new product type is a new row in every one of those determination tables, times valuation areas, times company codes. Add one when instruments genuinely process or post differently — that's what the layer is for — not to give each desk its own label; reporting dimensions are cheaper everywhere else.

The standing caveat, as always in this [SAP treasury guide](https://gravam.com/blog/what-is-sap-treasury-and-risk-management): the concepts here are stable, but the delivered lists are not — categories and predefined types differ between on-premise releases and the cloud editions, and the tables above quote specific documentation versions. Before you build a design on a delivered code, open your system's own configuration and check it's actually in the box.

***

_See also [SAP Transaction Manager: deals and instruments](https://gravam.com/blog/sap-transaction-manager) and [SAP treasury transaction codes](https://gravam.com/blog/sap-treasury-transaction-codes)._

## Primary sources

Category and type lists verified against SAP S/4HANA on-premise 2025 and SAP S/4HANA Cloud Public Edition 2608 documentation (plus SAP ERP pages where noted). Delivered codes and available categories differ by release and edition — check the list your system actually ships.

- SAP Help — Terms in Financial Transaction Management (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/e806da531198434de10000000a174cb4.html
- SAP Help — Product Categories (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/11521471717f48b7898fb618f90fd31c.html
- SAP Help — Product Categories (SAP S/4HANA Cloud Public Edition) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/11521471717f48b7898fb618f90fd31c.html
- SAP Help — Product Types (SAP S/4HANA Cloud Public Edition) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/f9e36fb87d4a4f13a5f872657fdf4b0f.html
- SAP Help — Configuration Options for Key Users in Treasury and Risk Management (SAP S/4HANA Cloud Public Edition) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/f9894d9f59894e27b2709732eb8c05a3.html
- SAP Help — Overview of Financial Instruments (SAP ERP, Transaction Manager) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/5bf929284e00453ba04be76690e6bed4/4c313dc4ebef3c6de10000000a42189c.html
- SAP Help — Creating Financial Transactions (SAP ERP) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/5bf929284e00453ba04be76690e6bed4/97908c53cc93ed23e10000000a174cb4.html

## Questions this article answers

**Q: What is the difference between a product category and a product type in SAP TRM?**

The product category is SAP's layer: a predefined internal key for the kinds of financial instrument — 550 Interest Rate Instrument, 600 FX Transaction, 040 Bond — that you cannot create or change, and that controls how instruments built on it are processed. The product type is your layer: defined in configuration, assigned to exactly one product category, and used to segment instruments to company-specific requirements — SAP's own example is splitting stock into domestic stock and foreign stock. SAP delivers example product types (51A Fixed-Term Deposit, 60A Foreign Exchange, 62A Interest Rate Swap among them), and you can use those or define your own on top of the categories.

**Q: What does a transaction type do in SAP Treasury?**

The transaction type determines how a financial transaction is processed, and it groups the transaction categories — the predefined business directions like fixed-term deposit investment versus borrowing, or purchase versus sale — under a product type. You define transaction types and assign them to your product types, and the processing category assigned in the transaction type definition decides the activity chain the deal walks through. SAP's delivered examples include 101 Spot Transaction and 102 Forward Transaction under FX product type 60I, and 100 Investment / 200 Borrowing under money market product type 55I.

**Q: What is the difference between a flow type and an update type in SAP TRM?**

Flow types classify the flows of a financial transaction — each flow has exactly one — and they are only unique per contract type, so flow type 1000 in securities is a different thing from flow type 1000 in foreign exchange. Update types classify the flows that update positions in parallel position management, and unlike flow types their definition is not limited to a contract type. The two layers are wired together in configuration: you assign the corresponding update types to the flow types used in transaction management, and separately mark which update types are relevant for posting and for payment.

**Q: Can you use SAP's delivered product types instead of defining your own?**

Yes — SAP's documentation says so directly: you define product types in Customizing, or 'alternatively, you can use the product types provided by SAP.' S/4HANA Cloud Public Edition documents a table of predefined product types (33 of them across FX, money market, derivatives, securities and trade finance, plus special ones for exposures and bank accounts), and the standard delivery in on-premise systems ships example product types the same way. In practice most on-premise projects copy the delivered types into their own codes and adjust; in the cloud edition the predefined list is the starting point by design.

---

# SAP Treasury Fiori Apps: What Replaces Which Transaction

Source: https://gravam.com/blog/sap-treasury-fiori-apps
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-08-02
Reviewed: 2026-09-26
Summary: A verified map of the Fiori apps for SAP Treasury and Cash Management in S/4HANA — F6157 to F2332 — with the classic transaction each replaces or complements.

**SAP Treasury Fiori apps are the S/4HANA launchpad apps — native ones carry F-numbers such as F6157 and F2332 — that replace, shadow or quietly outgrow the classic transaction codes for deal, cash, bank account and bank statement work; this page is the verified map of which app does what.** It is the companion to the [SAP Treasury transaction codes](https://gravam.com/blog/sap-treasury-transaction-codes) reference I published first, and the verification rule is the same, because the problem is the same: search for "SAP treasury Fiori apps" and you get scraped catalogs with invented app IDs. Every app on this page is checked against the SAP Fiori apps reference library and SAP Help; where I could verify an F-code app ID I print it, where I couldn't the app appears without one, and anything I couldn't verify at all is named in the exclusions section rather than silently included.

One structural thing to understand first, because it explains most of the confusion in this topic: **app IDs come in three flavors.** Native Fiori apps carry F-numbers (F6157, F2332) unrelated to any transaction. Classic transactions wrapped for the launchpad keep their transaction code as the app ID — TBB1 is both a tcode and, in the app library, an app. And a few classic reports are listed under their tcode with a "- Classic" suffix, SAP's own label for "still here, not the future". Once you can read the three flavors, the catalog stops looking random.

## The deal desk: Manage Financial Transactions (F6157)

The Transaction Manager's front-office and back-office codes — FTR_CREATE, FTR_EDIT, FTR_00 — get one Fiori counterpart that matters: **Manage Financial Transactions (F6157)**. SAP describes it as the place to manage financial transactions across all instrument groups in one list, with navigation into the display and processing apps per deal. In practice it competes with FTR_00 for the back-office worklist role, and SAP publishes a feature comparison between the two precisely because the supported product categories differ — the comparison is linked from the same documentation set as the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) apps catalog, and it's the document to read before a back office standardizes.

What F6157 is not: a replacement for deal entry. Creating and editing still runs through the classic transactions on-premise, wrapped GUI apps in the cloud. The honest summary is that F6157 replaces the _overview_ habit, not the _capture_ habit.

## Reading what happened: the F1754/F1755/F1867 trio

This is the cleanest classic-to-Fiori mapping in the whole module, and the one I'd actually retrain a team on:

| Fiori app (ID) | Classic transaction | What it does |
| --- | --- | --- |
| Display Treasury Position Values (F1867) | TPM12 (Treasury Position Values - Classic) | Positions in the treasury subledger with component values on any key date |
| Display Treasury Position Flows (F1754) | TPM13 (Treasury Position Flows - Classic) | Position flows behind those values, operative and derived |
| Display Treasury Posting Journal (F1755) | TPM20 (Treasury Posting Journal - Classic) | Accounting information for every posted flow |
| Treasury Position History (F3966) | — (no classic equivalent) | How accounting key figures moved over a period, by entity/currency/asset |

The "why did it post that?" walk I described in the transaction-codes reference — journal, flows, position — works identically here: F1755, then F1754, then F1867. The difference is availability: the F-apps are listed for both on-premise and Cloud Public Edition, while the "- Classic" tcode apps are the ones with an expiry date in their name. F3966 is the genuinely new member — a period-over-period reconciliation view that classic TPM12 never gave you, and the kind of thing the [treasury tables](https://gravam.com/blog/sap-treasury-tables) used to be the only way to build.

## Hedge management: where Fiori is the only way even on-premise

The newer Hedge Management and Accounting of Net Open Exposures has no classic-transaction heritage to map to — it was built launchpad-first, which is why the [hedge management article](https://gravam.com/blog/hedge-management-in-sap) treats it as a different discipline from THMEX-era hedge accounting. Two apps carry the daily work: the **Hedge Management Cockpit** (app ID TOENE — a wrapped ABAP app, no F-number exists) for the overview of FX exposures and hedge requests, and **Process Hedge Requests** (TOEHREQO) for working them. The balance-sheet FX variant has its own pair, including **Process Hedge Requests - Balance Sheet FX Risk (F4764)**. If your team still asks "what's the tcode for the cockpit," the answer is that TOENE _is_ the identifier, and it only exists as a launchpad app — this corner of TRM is Fiori-only everywhere, not just in the cloud.

## Cash position and forecasting

Cash management is where the Fiori story has the most layers, because SAP rebuilt this area around [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) and then iterated the apps on top of it:

| Fiori app (ID) | Classic counterpart | What it does |
| --- | --- | --- |
| Cash Flow Analyzer (F2332) | FF7AN/FF7BN territory | The working analysis surface: cash position and liquidity trend in one |
| Cash Position (F1737) | FF7A → FF7AN | Forecasted cash position by country, company, bank, currency |
| Liquidity Forecast (F0512A) | FF7B → FF7BN | 90-day liquidity trend from memo records and One Exposure |
| Short-Term Cash Positioning (F5380) | — (no classic equivalent) | Position from direct bank balances, driven by cash position profiles |
| Check Cash Flow Items (F0735) | — (no classic equivalent) | The data audit: track problematic and missing flows behind the position |
| Manage Memo Records (F2986/F2986A) | FF63/FF65 — SAP-documented replacement | Manual cash advices; 2.0 adds spreadsheet import |

Two notes worth the table space. First, the memo records line is the one SAP states outright: the 1809 release notes say Manage Memo Records **replaces** the FF63/FF65 apps — the strongest replacement language anywhere in this module, which is why I keep citing it. Second, the practical center of gravity has drifted to **Cash Flow Analyzer**: SAP's current release notes keep enhancing F2332 as the integration point for the newer cash functions, and the library lists the Smart Business pair (F1737/F0512A) for on-premise releases while the analyzer runs everywhere. If you're building a cash manager's launchpad today, F2332 is the tile they'll live in — the [S/4HANA Cash Management overview](https://gravam.com/blog/sap-cash-management-s4hana) covers the data model underneath it.

Rounding out daily cash operations: **Make Bank Transfers (F0691)** with its template sibling (F3760), **Manage Cash Concentration (F3265)** taking over from classic FF73, and **Process Trade Requests (TPITRO)** for working cash trade requests — the mechanism that turns a funding or investment decision into an instrument, extended in S/4HANA 2020 to cover money-market fixed-term deposits and loans.

## Banks and bank accounts: the master-data cluster

This cluster answers the "manage banks fiori" search, and it needs one deprecation warning up front:

| Fiori app (ID) | Status / classic counterpart | What it does |
| --- | --- | --- |
| Manage Banks - Cash Management (F1574A) | Successor of Manage Banks (F1574), now deprecated | Bank master data relevant to cash management, ratings, contacts |
| Manage Banks - Master Data (F6437) | Bank directory maintenance | Create and display banks as master data |
| Manage Bank Accounts (F1366A) | The BAM working surface | Create, edit, close, reopen bank accounts; lifecycle and signers |
| Manage Bank Accounts - Hierarchy (F1366) | — | The same inventory viewed as a bank hierarchy |

The pattern to internalize: **F1574 (Manage Banks) is the answer you'll find on older lists, and it's the wrong one now** — SAP's own documentation files it under "Manage Banks (Deprecated)" and recommends the split successors F1574A and F6437. Manage Bank Accounts (F1366A) is the front door of [SAP Bank Account Management](https://gravam.com/blog/sap-bank-account-management-s4hana), where bank accounts became governed master data instead of configuration — the shift that article walks through in detail. There is no classic transaction that maps cleanly onto F1366A, which is exactly the point: this is the part of S/4HANA cash management where Fiori isn't an alternative UI, it's where the process lives.

## Bank statements and payments

| Fiori app (ID) | Classic counterpart | What it does |
| --- | --- | --- |
| Manage Bank Statements (F1564) | FF67 (manual statement) | Manage manual and electronic statements; spreadsheet upload |
| Manage Incoming Payment Files (F1680) | FF.5 (import) | Bring statement files into the system |
| Reprocess Bank Statement Items (F1520) | FEBA_BANK_STATEMENT | Post-process items that didn't clear automatically |
| Bank Statement Monitor (F6388) | — (no classic equivalent) | Central view of statement arrival and errors, with history |
| Approve Bank Payments (F0673A) | BNK_APP | Review, approve, reject, defer payment batches; mass approval |
| Monitor Payments (F2388) | BNK_MONI's job | Track payment batches after release |

The [bank statement pipeline](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) keeps its shape — import, post, repair — with F1680, F1564 and F1520 as the Fiori stations. F6388 is the addition worth adopting even in a GUI-habit shop, because "which accounts haven't sent a statement today" was always an awkward question for the classic transactions to answer. On the payments side, F0673A is the Fiori counterpart of the BNK_APP habit — documented in SAP's Cash and Liquidity Management pages, including mass approval of batches as a background job, the feature I flagged in the transaction-codes post as changing the approval conversation at volume. How the batches get there in the first place is [Bank Communication Management](https://gravam.com/blog/bank-communication-management-bcm-sap)'s story.

## Cloud Public Edition: Fiori-only, with a precise footnote

In the transaction-codes reference I gave the planning rule: SAP S/4HANA Cloud Public Edition is Fiori-only, and classic codes don't apply there. That's still the right planning assumption — but this page is where the precise version belongs. There is no SAP GUI client in Cloud Public Edition; everything is a launchpad app. What SAP ships there, alongside the native F-apps, is a set of classic treasury functions **wrapped as launchpad apps whose app ID is the old transaction code**: the Cloud documentation lists Fix, Pay, and Post Flows with app ID TBB1, and the best-practice scripts open Fix, Pay and Post Flows (TBB1), Process Business Transactions (TPM10), Post Derived Business Transactions (TPM18) and Treasury Posting Journal - Classic (TPM20) straight from the launchpad. Cloud even gets scheduling apps the on-premise catalog doesn't list: Schedule Treasury Accountant Jobs (F2770), Schedule Treasury Back Office Jobs (F2771) and Schedule Treasury Middle Office Jobs (F2772), for running exactly these period-end steps as jobs.

So the muscle memory transfers better than the "Fiori-only" slogan suggests — but the wrapper is a compatibility measure, not a direction. Which deployment model puts you on which side of this line is the subject of the [deployment and edition comparison](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison).

An AI agent reaching these apps through their APIs is bounded by the same authorisations a user is; [what an agent may actually post in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) is the AI-side reading of this list.

## What I left out, on purpose

- **F0733.** It's in the target list of half the scraped catalogs, usually attached to a bank app. The Fiori apps reference library has no app with that ID — the numbering goes F0731, F0732, then F0735 — and SAP Help doesn't document one. Excluded, and worth calling out precisely because it spreads.
- **Retired apps that still circulate**: Manage Banks (F1574), Cash Position Details (F0737), Track Bank Transfers (F0692) and Bank Statement Monitor - End of Day (F1734) are all real, all in the library for older releases, and all absent from the current ones. They're history, not recommendations, so they don't get table rows.
- **Apps I couldn't pin an ID to.** Where SAP documents an app name but I couldn't verify its app ID in the library or on SAP Help, the app appears above without an ID (the Hedge Management Cockpit's TOENE being the honest edge case — verified, but not an F-number). No app ID on this page is inferred.

Same closing caveat as the [transaction-codes reference](https://gravam.com/blog/sap-treasury-transaction-codes), which remains the classic-side half of this pair: catalogs drift by release and edition, and this page states its verification scope in the frontmatter rather than pretending to be timeless. For what SAP Treasury actually is underneath both UIs, start with the [module guide](https://gravam.com/blog/what-is-sap-treasury-and-risk-management).

***

_See also [SAP Transaction Manager](https://gravam.com/blog/sap-transaction-manager) and [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana)._

## Primary sources

Verified against the SAP Fiori apps reference library for SAP S/4HANA 2025 / 2025 FPS01 (on-premise) and SAP S/4HANA Cloud Public Edition 2602/2608, plus SAP Help pages for those releases. Availability notes are per those releases and will drift.

- SAP Fiori apps reference library — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/
- SAP Fiori apps reference library — Manage Financial Transactions (F6157) — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps('F6157')/S32OP
- SAP Fiori apps reference library — Display Treasury Posting Journal (F1755) — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps('F1755')/S32OP
- SAP Fiori apps reference library — Cash Flow Analyzer (F2332) — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps('F2332')/S32OP
- SAP Fiori apps reference library — Manage Bank Accounts (F1366A) — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps('F1366A')/S32OP
- SAP Fiori apps reference library — Approve Bank Payments Version 2 (F0673A) — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps('F0673A')/S32OP
- SAP Fiori apps reference library — Hedge Management Cockpit (TOENE) — accessed 2026-08-02 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/detail/Apps('TOENE')/S32OP
- SAP Help — Apps for Treasury and Risk Management (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/2cb817564e8ff708e10000000a441470.html
- SAP Help — Manage Banks - Cash Management (Cash and Liquidity Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/a4e4d58b503d4ab69f63d7ec92f3b1f9.html
- SAP Help — Manage Banks (Deprecated) (Cash and Liquidity Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/917f0e56a686fb37e10000000a44147b.html
- SAP Help — Approve Bank Payments (Cash and Liquidity Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c401ac923da649359cb8052438b0d9be.html
- SAP Help — Business Function: Cash and Liquidity Management — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c7999f525c5b224fe10000000a445394.html
- SAP Help — Manage Bank Statements — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/e74a1f567afbdf21e10000000a4450e5.html
- SAP Help — Subitems of Bank Statement Items (What's New in SAP S/4HANA Cloud 2408, App ID F1564) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/0124564a69284414af9722440aa13df3.html
- SAP Help — Basic Cash Operations (What's New in SAP S/4HANA 1809) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/55421ea96597486784ecc3b581175cb5.html
- SAP Help — Fix, Pay, and Post Flows (SAP S/4HANA Cloud Public Edition, App ID TBB1) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/4219c55368511d4be10000000a174cb4.html
- SAP Help — Post to General Ledger (SAP S/4HANA Cloud Best Practices, TBB1 and TPM10 as Fiori apps) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD_BEST_PRACTICES/5d9bad597842a831529297b394f69f2f/d233811780d24b7c801abbf7cb7084ad.html
- SAP Help — New Filters in Cash Flow Analyzer (What's New in SAP S/4HANA Cloud 2602, F2332) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/247fdb44b04c48e0aa088cd7d4c91b61.html
- SAP Help — EMIR Fields Added to Manage Financial Transactions App (What's New in SAP S/4HANA Cloud 2502, F6157) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/40a426d12639482bba418270ca535430.html
- SAP Help — New Options for Automated Payment Runs (What's New in SAP S/4HANA Cloud 2508, F2770/F2771) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/1575a437b85a49d3ba50091fb772efc8.html
- SAP Help — Cash Trade Requests for Money Market (What's New in SAP S/4HANA 2020) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/ba3315584a8d4e3990fd214e5e0e64aa.html

## Questions this article answers

**Q: What is Fiori app F0733 in SAP Cash Management?**

As far as SAP's own records go, nothing. F0733 appears on circulating app lists, but the SAP Fiori apps reference library has no app under that ID — its numbering runs F0731, F0732, then jumps to F0735 (Check Cash Flow Items) — and SAP Help doesn't document an F0733 either. The bank apps people are usually reaching for are Manage Banks - Cash Management (F1574A), Manage Banks - Master Data (F6437) and Manage Bank Accounts (F1366A). If a list you're holding says F0733, treat the rest of that list with suspicion too.

**Q: Which Fiori apps replace TPM12, TPM13 and TPM20 in S/4HANA?**

The Fiori-native reporting siblings are Display Treasury Position Values (F1867) for TPM12, Display Treasury Position Flows (F1754) for TPM13, and Display Treasury Posting Journal (F1755) for TPM20. The classic transactions still exist — SAP's app catalog lists them with a '- Classic' suffix — but the F-apps are the ones available across both on-premise and Cloud Public Edition, so they're the ones worth standardizing an investigation routine on.

**Q: Can you use TBB1 or TPM10 in SAP S/4HANA Cloud Public Edition?**

Yes, with a caveat: TBB1 and TPM10 are not SAP GUI transactions in Cloud Public Edition, because there is no SAP GUI client there, but SAP ships them as launchpad apps whose app ID is the old transaction code. SAP's Cloud documentation lists Fix, Pay, and Post Flows with app ID TBB1, and its best-practice test scripts tell you to open Fix, Pay and Post Flows (TBB1) and Process Business Transactions (TPM10) from the Fiori launchpad. The function survives; the GUI habit doesn't.

**Q: Do SAP Fiori apps use the same app ID as the transaction they replace?**

Only sometimes, and the pattern is worth knowing. Native Fiori apps carry F-numbers (F6157, F2332, F1755) that have no relation to any transaction code. Classic transactions that SAP wraps for the launchpad keep the transaction code as their app ID — TBB1, TPM10, TOENE for the Hedge Management Cockpit — and some classic reports get listed under their tcode with a '- Classic' name, like Treasury Posting Journal - Classic (TPM20). So an app ID that looks like a tcode is a wrapped classic screen, and an F-number is a genuine Fiori rebuild.

---

# SAP Treasury Tables: Where Deals, Flows and Positions Live

Source: https://gravam.com/blog/sap-treasury-tables
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-08-02
Reviewed: 2026-08-02
Summary: The database tables behind SAP Treasury and Risk Management — the VTBFHA deal family, FEBKO/FEBEP, FQM_FLOW and the FI link — verified against SAP Help.

**Every SAP Treasury deal you capture ends up as rows in a handful of tables: the deal in VTBFHA, its flows in VTBFHAPO, its conditions in VTBFINKO — and from there the trail runs through the Treasury subledger into BKPF, BSEG and ACDOCA on the FI side, with FQM_FLOW and FEBKO/FEBEP carrying the cash and bank-statement view.** This page is the map of those tables. It exists for the same reason as its sibling, the [treasury transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes): search for "SAP treasury tables" and you get scraped dictionary dumps listing hundreds of names with no indication which ones a treasury system actually writes to — or whether they exist at all. So, same method: every table below is verified against SAP's own documentation, and anything I couldn't verify there didn't make the page. That cuts the list down, and the cuts are documented at the end, because knowing what's _not_ verifiable is half the value.

One scope note first: table names are an on-premise and private-edition concern. That's where you have SE16N, query tools and interfaces reading the database. SAP S/4HANA Cloud Public Edition gives you released APIs and CDS views instead of table access, so if that's your target, read this page as background, not as a query plan.

> **Figure — Where one SAP Treasury deal is stored**
>
> One deal fans out into three tables. VTBFHA holds the deal, VTBFHAPO its flows and VTBFINKO its conditions. From them an arrow leads to the FI side, drawn as a ledger listing BKPF, BSEG and ACDOCA.
>
> One deal, three Treasury tables, and from there the trail into FI.

## The deal: the VTBFHA family

| Table | What SAP's documentation puts there |
| --- | --- |
| VTBFHA | The financial transaction itself — contract data for every Transaction Manager product type |
| VTBFHAZU | Activity-level data — contract date (DVTRAB), FX transaction rate (KKURS), swap rate (KSWAP) |
| VTBFHAPO | The flows — SAP's migration documentation calls it the source of "main flow information" |
| VTBFINKO | The conditions of a transaction — interest and repayment terms |
| VTBZV | Payment details |
| VTBPA | Partner assignments — which business partner plays which role on the deal |

The best evidence that VTBFHA is _the_ deal table is how consistently SAP's own S/4HANA migration objects point at it: fixed-term deposits, deposits at notice, FX spot/forward contracts, FX swaps, FX options, interest rate swaps, interest rate instruments, commercial paper, stocks, bonds, investment certificates, [letters of credit and bank guarantees](https://gravam.com/blog/bank-guarantees-and-letters-of-credit) all "automatically select" their contract data "from the VTBFHA table". One table, every [product type](https://gravam.com/blog/sap-trm-product-types-and-transaction-types) — which is exactly why FTR_CREATE can capture a money market deal and an FX forward through the same transaction. Changes to a deal are tracked under a change document object that SAP also names VTBFHA.

The satellites divide the deal up the way the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) thinks about it. VTBFHAZU carries the data of each activity — SAP's trade repository documentation reads the contract date from VTBFHAZU-DVTRAB, and its FX documentation reads the transaction exchange rate (KKURS) and swap rate (KSWAP) from the same table. VTBFHAPO carries the flows; the migration object for main flows selects from it, and SAP's data-protection documentation looks for the payer and paying bank there, which tells you payment-relevant detail sits at flow level. VTBFINKO holds the conditions, VTBZV the payment details, VTBPA the partner assignments. When you trace a deal in SE16N, that's the read order: VTBFHA for the deal, VTBFHAZU for what happened to it, VTBFHAPO for what it pays, VTBFINKO for why it pays that.

For securities, one master-data table belongs in this group: **VWPANLA**, the class data of the security. SAP's extraction documentation selects ID numbers from it, and the data-protection documentation locates the issuer there. It's the table behind the FWZZ class master, the same way BP sits behind the counterparty on the deal.

## Positions: where the dump sites bluff

Here's the section that surprised me while verifying: **SAP Help does not name the physical tables of the Treasury position subledger.** The dump sites list names for them anyway. I couldn't verify those names in any SAP documentation, so they're not here — and I'd treat any list that includes them as unreviewed until you've checked SE11 yourself.

What SAP documents instead are the access paths, and honestly they're what you should be using anyway:

- **The position reports** — TPM12 for position values, TPM13 for position flows, TPM20 for the posting journal. The working trio from the [transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes). Their Fiori-native siblings — F1867, F1754, F1755 — are in the [Fiori apps reference](https://gravam.com/blog/sap-treasury-fiori-apps).
- **Logical databases** — FTI_TR_POSITIONS ("evaluate positions in the Transaction Manager for a given key date") and FTI_TR_PERIODS for period evaluations, both documented in the TRM information system. If you're building a custom position report, this is SAP's sanctioned read path.
- **CDS extraction views** — in S/4HANA Cloud, SAP documents treasury-ledger transaction flow views for data extraction, which is the direction position reporting is moving generally.
- **Archiving object TRTM_TPM** — positions are archived in "position groups", and SAP's archiving documentation describes the grouping rules in detail without ever naming the underlying tables.

The one treasury-ledger table SAP does name is **TRLT_INIT_VAL_SE**, and only in a narrow role: when you initialize a new parallel valuation area, the position determined from the leading valuation area is saved there as the target structure for building the new one. Real table, documented purpose, and almost certainly not what you were looking for when you searched "SAP treasury position table". What positions [mean and how valuation writes them](https://gravam.com/blog/sap-trm-position-management-and-valuation) matters more than their physical storage — which is presumably the point of SAP not documenting it.

## The FI border: BKPF, BSEG, ACDOCA

Treasury postings become accounting documents, and SAP's documentation is plain about what that means at the database level: **BKPF** is the accounting document header, **BSEG** the accounting document segment — the line items. The [BKPF/BSEG join](https://gravam.com/blog/02-bkpf-bseg-join) has its own article here, including the four-field key that people get wrong and the SHKZG sign handling; tracing what TBB1 posted for a specific deal lands you exactly on that join.

Two qualifications from the S/4HANA side. First, **ACDOCA**: SAP's documentation calls the universal journal table "the single source of truth for all processes and reports in accounting" — so balance and reporting queries belong on ACDOCA, and the BKPF/BSEG join stays for document-level detail. Second, the classic open/cleared-item index tables — BSIS/BSAS for G/L accounts, BSID/BSAD for customers, BSIK/BSAK for vendors, the tables behind the FBL3N/FBL5N/FBL1N line item lists in SAP's own support documentation — are an ECC-era pattern; on S/4HANA the universal journal carries that load. The treasury-side view of the same postings is TPM20, and the [posting architecture article](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) explains how the subledger and the general ledger relate.

## Cash management: FQM_FLOW ate the old tables

S/4HANA cash management reads one table where classic Cash Management read several. SAP's documentation states it directly: "SAP S/4HANA Finance for cash management consumes data from the One Exposure from Operations table (database table FQM_FLOW)" — and One Exposure aggregates flows from FI, TRM, Loans Management and integrated remote systems into that single store. This site has a full article on [One Exposure and FQM_FLOW](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), and a second on [reconciling it when the numbers look wrong](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting), so here I'll only place the table among its neighbors:

- **FDES**, the classic memo record table, is documented as replaced: memo records "are no longer stored in table FDES", and SAP ships the migration report FCLM_MIGR_FDES2FQM to move existing ones into FQM_FLOW. If your interface still writes FDES on S/4HANA, this is the documentation to wave at its owner.
- **FDSB**, the classic Cash Management summary balance table, survives long enough that SAP documents a reconciliation view comparing "data stored in table FDSB of Classic Cash Management" against FQM_FLOW — a sentence that quietly confirms both tables' roles.
- **PAYRQ**, the payment request table, holds the settlement-side objects treasury generates for F111; SAP documents it as the segment of archiving object FI_PAYRQ, and One Exposure carries forecasted flows from payment requests under a certainty level named after it.

## Bank statements: FEBKO, FEBEP and the ring around them

For once, SAP publishes exactly the table you'd want: a technical FAQ for SAP Cash Application that lists the bank statement tables by name and purpose.

| Table | SAP's description |
| --- | --- |
| FEBKO | Bank statement header |
| FEBEP | Bank statement item |
| FEBRE | Notes to payee / memo line |
| FEBRE_ORIG | Original notes to payee / memo line |
| FEBCL | Clearing assignment — proposals are stored here |
| FEBCL_EXT | Clearing assignment with machine-learning fields |

The shape to remember: one FEBKO entry per imported statement, one FEBEP entry per transaction line, FEBRE hanging off the item with the unstructured note-to-payee text that your [search strings](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) parse. When the electronic bank statement run posts or fails to post, the evidence is in FEBEP's posting fields — SAP's own troubleshooting content walks through FEBEP fields like BELNR and INTAG when a statement misbehaves. And a nicely current detail: SAP Cash Application's proposal status lives in FEBEP-ML_STATUS, so even the machine-learning layer reports into the same thirty-year-old table family.

## Banks, accounts and BAM

| Table | What SAP's documentation puts there |
| --- | --- |
| BNKA | Bank master data — SAP's Bank API is "built using CDS views based" on it |
| T012 | House banks |
| T012K | House bank accounts |
| FCLM_BAM_AMD | Bank account master data — the S/4HANA Bank Account Management table |
| FCLM_BAM_ACLINK2 | Named alongside FCLM_BAM_AMD in SAP's BAM replication configuration |

The division of labor: BNKA knows the bank exists, T012/T012K know your company banks there, and FCLM_BAM_AMD is the [SAP Bank Account Management](https://gravam.com/blog/sap-bank-account-management-s4hana) layer S/4HANA put on top — the table you extend (SAP documents appending structure CI_AMD_EXT to it for custom fields) and the table that's gaining authority over time: a recent release note makes FCLM_BAM_AMD-CONTROL_KEY "the single source of control keys", removing the field from the house bank account UI. That's the migration from T012K-centric to BAM-centric bank account data happening one field at a time, in public.

## Payments and rates

Two FI table groups that every treasury investigation eventually touches. The payment run — F110 or treasury's F111 — creates entries in **REGUH** (payment data per payee) and **REGUP** (the paid items); SAP's support documentation states the pair is written when the run executes, and the S/4HANA documentation still carries the classic guide to displaying REGUH/REGUD/REGUP fields for payment forms. When a settlement leaves [Bank Communication Management](https://gravam.com/blog/bank-communication-management-bcm-sap) and someone asks "what exactly went into that batch", REGUH/REGUP is the answer at table level — and when the question moves from the batch to the file itself, the [DMEE format tree](https://gravam.com/blog/sap-dmee-payment-file-format-tree) that built it is the next layer down. Checks get their own register, PAYR, which is also where the bank's [positive pay](https://gravam.com/blog/positive-pay-in-sap) issue file comes from.

And **TCURR**, the exchange rate table behind OB08 — documented by SAP with its siblings TCURV (rate types), TCURF (conversion factors) and TCURX (decimal places). Treasury valuation reads it constantly, which is why it appears in the [market data article](https://gravam.com/blog/sap-treasury-market-data-management) and in every "why is TPM1 producing nonsense" call.

These are also the tables an AI agent would read — and, if you let it, write. [What actually posts when an agent acts in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) draws the line between reading them and changing them, table by table.

## What I left out, on purpose

The exclusions are the part the dump sites can't give you, so here they are explicitly:

- **The Treasury position subledger tables.** Not named in SAP Help, as covered above. The names circulating on dump sites for the position and flow layer may even be right — but I couldn't verify them, so they're out. Verified access paths (TPM12/TPM13, the FTI_TR_* logical databases, TRTM_TPM) are in.
- **Hedge accounting tables.** SAP documents hedge management [functionally](https://gravam.com/blog/hedge-management-in-sap) — hedging relationships, designation, TPM100 and its siblings — without naming the underlying tables anywhere I could verify. Same rule, same outcome.
- **The Analyzer tables, mostly.** SAP's data-protection documentation names a set of Risk Management tables — JBRDBKO, JBRSVKO, VTBLS, KLNT01, KLMAXLIMIT among them — but only as a list of places business partner data appears, with no statement of what each table does. Names verified, purposes not documented, so they don't get rows in the tables above.
- **Loans Management (FS-CML) and In-House Cash.** Different components with their own table families; mixing them in is how the 400-row dumps became unusable.

The standing caveat from the [transaction codes post](https://gravam.com/blog/sap-treasury-transaction-codes) applies double here: releases move things. FDES lost its job to FQM_FLOW, T012K is losing fields to FCLM_BAM_AMD, and BSEG-first reporting gave way to ACDOCA. If you're carrying interfaces that read these tables into an S/4HANA migration, the [ECC to S/4HANA article](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana) covers which of those reads survive — because a table still existing is not the same as it still being the right place to look.

***

_See also [Joining BKPF and BSEG without losing your mind](https://gravam.com/blog/02-bkpf-bseg-join) and [SAP Treasury Transaction Codes: The Ones That Matter](https://gravam.com/blog/sap-treasury-transaction-codes)._

## Primary sources

Table names verified against SAP S/4HANA on-premise/private edition and SAP ERP documentation. SAP S/4HANA Cloud Public Edition gives you no direct table access — there, this page is background knowledge, not a query target.

- SAP Help — Business Partner End of Purpose (EoP) Check in TRM - Transaction Manager (SAP S/4HANA Security Guide) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/5550be7056c34ee6ada730c35e41e967/70a6be01eb6e48f4a0ee2adaaf03255d.html
- SAP Help — Business Partner End of Purpose (EoP) Check in TRM - Transaction Manager (SAP ERP) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/4d6b9b32599844ee81b23a443efedb7f/4a44d32c0cb04191b7e141ea7a9147a6.html
- SAP Help — TRM - Foreign exchange spot/forward contract (SAP S/4HANA Data Migration) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/4b332d2c85f84656b435491ca0fe65dd.html
- SAP Help — TRM - Main flow detail (SAP S/4HANA Data Migration) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/4c42b3ed80f54fac88ccf640358f3266.html
- SAP Help — TRM - Condition detail (SAP S/4HANA Data Migration) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/85d859c44f394f35b2ac5c66cd5cda3f.html
- SAP Help — TRM - Payment detail (SAP S/4HANA Data Migration) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/70e1337b41fe4792b15ea56f80962d4a.html
- SAP Help — Fields of the Trade Repository Object (SAP ERP, Transaction Manager) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/5bf929284e00453ba04be76690e6bed4/86d52b513e422314e10000000a44176d.html
- SAP Help — FX Transaction: One Currency to be Converted (Banking Services from SAP) — accessed 2026-08-02 — https://help.sap.com/docs/BS_CA/45ad80a96f0840ab85a43d672151699b/83c58d5377a0ec23e10000000a174cb4.html
- SAP Help — Treasury: Change Documents for Transaction (SAP S/4HANA Cloud) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/b707da531198434de10000000a174cb4.html
- SAP Help — Futures Extraction for Global Trade Management (SAP ERP) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/4d6b9b32599844ee81b23a443efedb7f/d2df3750e82e1e26e10000000a44538d.html
- SAP Help — Information System (Treasury and Risk Management, logical databases) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/2becc753b1081d4be10000000a174cb4.html
- SAP Help — Archiving Data in Treasury and Risk Management — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/f8ba83ff72c04364b2162459761ee521.html
- SAP Help — Initialization in the Area of Securities (SAP ERP, parallel valuation areas) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/5bf929284e00453ba04be76690e6bed4/0107da531198434de10000000a174cb4.html
- SAP Help — Detection Method: OTA Uses Bank Account of Regular Vendor (BKPF/BSEG at database level) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/9b03947b033f4432ba0261c94b73ea45/d8a956539a2f4e3fe10000000a441470.html
- SAP Help — JVA on ACDOCA (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/f049a59301a94f1c9bb60ca8394db217/06421bf5a2ad4af28c8d1f6904a214ec.html
- SAP Help — Low performance of FBL1N, FBL3N and FBL5N (SAP Support Content) — accessed 2026-08-02 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361880330.html
- SAP Help — Set Up Cash Management Data (SAP S/4HANA, One Exposure) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/1ab55956b967c841e10000000a44147b.html
- SAP Help — Manage Memo Records (What's New in SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/490aa596da004737bdc9bbbe3e99135f.html
- SAP Help — Bank Account Balance Reconciliation (SAP S/4HANA Cloud, FDSB vs FQM_FLOW) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/cc30a2046b044871be668366dab7ba5d.html
- SAP Help — Archiving Object - Payment Request (FI_PAYRQ, SAP ERP) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/94d7b08d330a430e952eb46244e5f781/5904c5536a51204be10000000a174cb4.html
- SAP Help — FAQs for Technical References (SAP Cash Application, bank statement tables) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_CASH_APPLICATION/60e4f6eb9b6a427db1963afb7e9791b5/df9f7ade30474c529ca03e223e7c6684.html
- SAP Help — Bank (Version 0001) API (BNKA, SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/d4eb54ea54944b04923af573b28a1e7d/e4d5cefbf71847b899b169a4706c9921.html
- SAP Help — FI - House bank (SAP S/4HANA Data Migration) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/ae4c6961faa14462848f11b0ad0c4465.html
- SAP Help — FI - Bank account (SAP S/4HANA Data Migration, T012K) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/4fac9b4a140a40f28233abca147abce1.html
- SAP Help — Enhancing Template and Validation Schema for Custom Fields (FCLM_BAM_AMD) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/4a9ecf54e81e6374e10000000a44538d.html
- SAP Help — Consolidation of Bank Control Keys (What's New in SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/36f8b14578624daabcc46ba4297cf1fe.html
- SAP Help — General procedures and Tables in Automatic payment run (SAP Support Content) — accessed 2026-08-02 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361878657.html
- SAP Help — Displaying Fields from REGUH, REGUD, and REGUP (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/f103c55368511d4be10000000a174cb4-2540.html
- SAP Help — Configuration Data, Inbound Integration (SAP IBP, TCURR and related tables) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_INTEGRATED_BUSINESS_PLANNING/3010d35b0dbe43b985b58c1e5a82da8f/84dbd256500b5667e10000000a441470.html
- SAP Help — Deletion of Personal Data (SAP ERP, TRM and Analyzer tables) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/b1f00e6e67d64c4d9218c3247f57de23/37e28453e535c110e10000000a44176d.html

## Questions this article answers

**Q: Which tables hold deal data in SAP Treasury and Risk Management?**

The VTBFHA family. VTBFHA holds the financial transaction itself — SAP's migration objects for fixed-term deposits, FX forwards, swaps, options, commercial paper and securities all select their contract data from it. Around it sit VTBFHAZU with activity-level data such as the contract date and FX rates, VTBFHAPO with the main flows, VTBFINKO with the conditions, VTBZV with the payment details, and VTBPA with the partner assignments. All six names are taken from SAP's own documentation, not from table-dump sites.

**Q: What is the difference between FEBKO and FEBEP in SAP?**

FEBKO is the electronic bank statement header — one entry per imported statement, carrying the statement number, date and house bank keys. FEBEP holds the statement items, one per transaction line, including the posting fields the import fills and the ML_STATUS field that SAP Cash Application uses. SAP's documentation names four more tables in the same ring: FEBRE and FEBRE_ORIG for the note-to-payee lines, and FEBCL and FEBCL_EXT for clearing assignments and proposals.

**Q: Where are treasury positions stored in S/4HANA?**

SAP Help does not name the physical position tables of the Treasury subledger — which is worth knowing, because dump sites confidently list names you cannot verify. What SAP documents instead are the access paths: the position reports TPM12 and TPM13, the logical databases FTI_TR_POSITIONS and FTI_TR_PERIODS for key-date and period evaluations, treasury-ledger CDS extraction views in S/4HANA Cloud, and the archiving object TRTM_TPM that archives positions in position groups. The one treasury-ledger table SAP names is TRLT_INIT_VAL_SE, and only for initializing parallel valuation areas.

**Q: Do treasury deals post to BKPF and BSEG or to ACDOCA?**

Both views exist for treasury postings. When treasury flows are posted to the general ledger, the results are accounting documents, and SAP documents BKPF as the accounting document header and BSEG as the accounting document segment at the database level. In S/4HANA, SAP's documentation calls the universal journal table ACDOCA the single source of truth for all processes and reports in accounting, so reporting belongs there — while the treasury-side view of the same postings is the TPM20 posting journal.

---

# SAP Treasury Transaction Codes: The Ones That Matter

Source: https://gravam.com/blog/sap-treasury-transaction-codes
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-08-02
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: A verified reference of SAP Treasury and Risk Management transaction codes — FTR_CREATE to TPM20 — grouped by working area and checked against SAP Help.

**If you work in SAP Treasury and Risk Management, you live in perhaps forty transaction codes: FTR_CREATE and FTR_EDIT for the deals, TBB1 and the TPM family for postings and period-end, TPM12/TPM13/TPM20 for finding out what actually happened, and a ring of cash, hedge, market-data and payment codes around them.** That's the whole list, and this page is a reference for it. The reason it exists: search for "SAP treasury tcodes" and you get 400-row table dumps, scraped from each other, listing codes that were retired two releases ago next to codes that never belonged to TRM in the first place. So I did it the slow way — every code below is checked against SAP's own documentation, and anything I couldn't verify there didn't make the page. A shorter list you can trust beats a longer one you have to re-verify yourself.

Grouping is by working area, the way the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) itself is organized, with a note per group on what a consultant actually opens daily versus what exists but rarely gets touched.

One scope note before the tables: these are the GUI transactions of S/4HANA on-premise and private edition (and their ECC ancestors). SAP's app catalog now lists several of them with a "- Classic" suffix, which tells you where the Fiori-first direction is heading — and in S/4HANA Cloud Public Edition the classic codes aren't available as GUI transactions at all; the [Fiori apps reference](https://gravam.com/blog/sap-treasury-fiori-apps) maps what stands in for each of them. More on that at the end.

## The deal desk: FTR_* and the master data under it

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| FTR_CREATE | Create Financial Transaction | Enter a deal — money market, FX, derivatives, securities, commodities |
| FTR_EDIT | Process (Edit) Financial Transaction | Change, settle or work an existing deal |
| FTR_DISPLAY | Display Financial Transaction | Look at a deal without touching it |
| FTR_00 | Collective Processing: Transaction Management | The back-office worklist — settle and confirm deals in bulk |
| BP | Maintain Business Partner | Counterparties — every deal needs one before FTR_CREATE will save it |
| FWZZ | Securities class master data | The security (class) a securities deal references |
| FTR_COMONI | Correspondence Monitor | All correspondence objects — outgoing confirmations and their matching |

The honest usage split: a front office lives in FTR_CREATE and FTR_EDIT; a back office lives in FTR_00. [Business partner setup](https://gravam.com/blog/business-partner-configuration-sap-treasury) via BP is the thing that blocks the first deal on every new implementation, so it belongs in this group even though it's not a treasury-only code. FTR_COMONI is the one people forget exists until an auditor asks how confirmations are matched — the correspondence monitor is the answer, and SAP documents it as the overview of all correspondence objects.

S/4HANA note: SAP documents a Fiori app, Manage Financial Transactions (app ID F6157), alongside FTR_00, including a feature comparison between the two — the comparison is worth reading before you decide which one your back office standardizes on, because the supported product categories differ.

## Posting and period-end: TBB1 and the TPM family

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| TBB1 | Treasury: Post Flows | Post the flows of financial transactions to the general ledger |
| TPM10 | Fix, Post or Reverse Transactions | Fix, post, reverse business transactions from positions (S/4HANA app name: Process Business Transactions) |
| TPM18 | Fix and Post Derived Business Transactions | Post derived business transactions — e.g. at contract close in FX hedge accounting |
| TPM1 | Execute Valuation | Key-date valuation of positions, per valuation area |
| TPM2 | Reverse Valuation | Undo a valuation run |
| TPM44 | Run Accrual/Deferral | Accrue and defer expenses and revenues at period end |
| TI10 | Create Adjustment - Rates/Prices | Interest rate adjustment (fixings) for variable-rate deals |
| TPM60 | Calculate Net Present Values | NPV calculation feeding valuation and reporting |

This is the period-end backbone, and it's the group where the confusion concentrates, because three codes have names that sound like the same job. The working distinction: **TBB1 posts your deals' flows; TPM10 and TPM18 handle the business transactions the system derives from positions.** SAP ERP documentation names TPM10 "Fix, Post or Reverse Transactions" and puts it in the period-end closing process; the S/4HANA app catalog calls the same code "Process Business Transactions". TPM18 appears throughout SAP's hedge accounting documentation — contract close in FX hedge accounting runs through it. If your close checklist has only TBB1 on it, positions will quietly drift from the ledger; the [posting architecture](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) article explains what each of these actually writes.

TPM1 is the other daily-critical one: valuation runs per valuation area, one per accounting principle, and [position management](https://gravam.com/blog/sap-trm-position-management-and-valuation) decides what it values. TPM2 exists because you will need it — a valuation run with wrong market data is a matter of when, not if.

A current-release detail worth knowing: SAP S/4HANA 2025 documents new payment-control options in what it now calls the "Fix, Pay and Post Flows (TBB1)" app — same code, growing job.

## Reading what happened: the reporting trio

| Code | SAP's name (S/4HANA app catalog) | What you use it for |
| --- | --- | --- |
| TPM12 | Treasury Position Values - Classic | Position list — what you hold, at what value |
| TPM13 | Treasury Position Flows - Classic | Position flow list / subledger cash flow |
| TPM20 | Treasury Posting Journal - Classic | Every posting the treasury subledger generated |

These three are what I open on any "why did it post that?" call (the [tables behind them](https://gravam.com/blog/sap-treasury-tables) have a reference of their own), in reverse order: TPM20 to see the posting, TPM13 to see the flows behind it, TPM12 to see the position they belong to. Since S/4HANA 1909, TPM20 can show reversals and the postings they reversed on separate lines, which sounds cosmetic and saves real time in a messy close. Note the "- Classic" suffix in all three official app names — SAP's label, not mine, and a clear signal about the direction of travel.

## Market data

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| TBDM | Market Data File Interface: Import Rates and Prices | Import rates and prices from a file |
| TBEXN | Market Data Transfer from Spreadsheet | Pull market data in from a spreadsheet |
| TBD4 | Request Current Market Data - Datafeed | Request current data through the datafeed interface |
| OB08 | Maintain Currency Exchange Rates | The exchange rate table (TCURR) everything reads |

Nobody plans time for market data and everybody loses time to it: TPM1 fails or produces nonsense, and the cause is a missing rate, a stale curve, or a datafeed translation entry — the [market data article](https://gravam.com/blog/sap-treasury-market-data-management) covers the plumbing. OB08 is plain FI rather than TRM, but treasury valuations read it constantly, so it earns its row. One correction to the usual dump lists: the spreadsheet transfer code SAP's current S/4HANA documentation names is **TBEXN** — the older TBEX appears on tcode sites, not in the S/4HANA documentation I checked.

## Hedge management and hedge accounting

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| THMEX | Hedge Plan / Hedge Plan List | Hedge plans and hedging relationships (Hedge Accounting for Exposures, E-HA) |
| THM80 | Hedging Relationships: Effectiveness Test | Run and review effectiveness tests (E-HA) |
| TPM100 | Hedging relationships processing | Check and release designated hedging relationships |
| TPM120 | Release Hedging Business Transactions | Release hedging business transactions for posting |
| TPM121 | Reverse Release of Hedging Business Transactions | Undo that release |
| FTREX1 | Raw Exposures (Exposure Management 2.0) | Enter and process the raw exposures you hedge against |

Which of these you touch depends entirely on which hedge accounting flavor you run — the distinction the [hedge management article](https://gravam.com/blog/hedge-management-in-sap) is built around. THMEX and THM80 belong to classic Hedge Accounting for Exposures; the newer Hedge Management and Accounting of Net Open Exposures is Fiori-first (the Hedge Management Cockpit is an app, not a tcode), with the TPM1xx codes doing the release-and-post mechanics underneath. FTREX1 is easy to overlook because it sits in Exposure Management rather than the Transaction Manager, but without released raw exposures there's nothing to designate against.

## Analyzers and limits

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| JBRX | Analyze NPV | Single-position NPV analysis in the Market Risk Analyzer |
| AISGENKF | Key Figure Analysis | Market Risk Analyzer information-system report on key figures |
| RAEP1_KFSET | Calculate Market Risk Key Figures | Batch calculation of market-risk key figures |
| TBL1 | Manage Limits | Maintain counterparty/limit structures |
| TBLB | Review Limit Utilizations | What's using the limits right now |
| KLNACHT | End-of-Day Processing | The Credit Risk Analyzer's end-of-day run |

The risk team's corner, and the least-opened group on this page — which is the point of listing it honestly. On most corporate installations JBRX gets opened when someone challenges a valuation, TBLB gets opened when a dealer hits a limit warning, and KLNACHT is scheduled as a background job that nobody looks at until it fails. The [Credit Risk Analyzer](https://gravam.com/blog/sap-credit-risk-analyzer) article covers what that end-of-day run actually maintains.

## Cash management

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| FF7AN | Display Cash Position (S/4HANA) | Today's cash, from One Exposure and memo records |
| FF7BN | Display Liquidity Forecast (S/4HANA) | The medium-term view from the same data |
| FF7A / FF7B | Cash Position / Liquidity Forecast | The classic ECC pair the above replaced |
| FF63 / FF65 | Create / Display Memo Record | Manual cash advices — classic; Fiori Manage Memo Records replaced these apps |
| FF67 | Manual Bank Statement | Key in a statement by hand |
| FF.5 | Import Electronic Bank Statement | Load MT940/CAMT.053 statement files |
| FEBA_BANK_STATEMENT | Reprocess Bank Statement Items | Post-process what the import couldn't clear |

Strictly this is [Cash Management](https://gravam.com/blog/sap-cash-management-s4hana), not TRM — but no treasury consultant gets to ignore it, and the tcode-dump sites mix the two indiscriminately, so better to draw the line deliberately. The S/4HANA story matters here more than anywhere else on this page: FF7AN and FF7BN read One Exposure, and SAP's release notes are explicit that the Fiori Manage Memo Records app replaced the FF63/FF65 apps. Day-to-day reality is bank-statement processing: FF.5 in the morning, FEBA_BANK_STATEMENT for the items that didn't clear — the [SAP electronic bank statement guide](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) walks through that pipeline and its configuration layer — posting rules, algorithms, search strings.

## Payments and bank communication

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| F110 | Payment run (AP/AR) | The standard payment program for vendors and customers |
| F111 | Payment run for payment requests | The treasury one — pays the payment requests TRM deals generate |
| BNK_APP | Approve Payments | Release payment batches in Bank Communication Management |
| BNK_MONI | Batch and Payment Monitor | Track what happened to every batch after approval |

F111 versus F110 is a distinction worth being pedantic about: treasury settlements flow as payment requests, and F111 is the program that pays them — plenty of go-live payment incidents reduce to "someone ran the wrong one." BNK_APP and BNK_MONI are the working pair of [Bank Communication Management](https://gravam.com/blog/bank-communication-management-bcm-sap); S/4HANA also documents an Approve Bank Payments app that can mass-approve batches as a background job, which changes the approval workflow conversation on bigger volumes.

If an AI agent is ever going to call any of these, the question is not which transaction but what it may post — [AI agents in SAP: what actually lands in the system](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) takes that apart posting by posting, with the same authorisation model these codes run under.

## What I left out, on purpose

Three categories didn't make the page, and the reasons are the useful part:

- **Codes I couldn't verify in SAP's current documentation.** TBEX is the clearest case — S/4HANA documentation names TBEXN for the spreadsheet transfer. FEBAN is a different case: the transaction is real and still runs on S/4HANA on-premise, but the code SAP's S/4HANA documentation names for statement post-processing is FEBA_BANK_STATEMENT, so that is the one in the table. When a dump site and the SAP Help disagree on the documented code, believe the Help. The [bank statement post-processing guide](https://gravam.com/blog/feban-bank-statement-post-processing) puts FEBAN, FEBA_BANK_STATEMENT, FEB_BSPROC and the Fiori app side by side.
- **Configuration transactions.** The IMG side (posting specs, valuation areas, [product types](https://gravam.com/blog/sap-trm-product-types-and-transaction-types)) is a different discipline with a different audience, and mixing it into a working-tcode list is how those 400-row dumps got unusable.
- **The long tail that exists but you'll rarely open** — securities corporate actions, archiving runs, migration utilities. Real, documented, and not what this page is for.

And the standing caveat, same as everywhere in this [SAP treasury guide](https://gravam.com/blog/what-is-sap-treasury-and-risk-management): codes and app availability differ by release and edition. On-premise and private edition keep the GUI transactions; SAP S/4HANA Cloud Public Edition is Fiori-only, and if that's your target, this page is a translation table, not a map. If you're mid-move, the [ECC to S/4HANA migration article](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana) covers what changes underneath these codes — because the codes surviving the migration doesn't mean their behavior did.

***

_See also [SAP Transaction Manager](https://gravam.com/blog/sap-transaction-manager) and [SAP TRM accounting and posting architecture](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture)._

## Primary sources

SAP S/4HANA on-premise/private edition (classic transactions noted against SAP ERP/ECC where the documentation is ECC-specific). SAP S/4HANA Cloud Public Edition is Fiori-only; most codes here do not apply there.

- SAP Help — Apps for Treasury and Risk Management (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/2cb817564e8ff708e10000000a441470.html
- SAP Help — Apps for Processing Financial Transactions (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/0f19c55368511d4be10000000a174cb4.html
- SAP Help — Feature Comparison for Collective Processing Apps for Financial Transactions — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/ef7f3a881b514f24a826becbfa43c3b6.html
- SAP Help — Negative Prices in Commodity Futures and Commodity Swaps (Finance) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/888cbe952a0e4a729f8b823d69860929/86d627cacd2a4f9ab591d7984cba962f.html
- SAP Help — Securities Lending (Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/ac15da531198434de10000000a174cb4.html
- SAP Help — Free Text Search (Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/cc369a51021a9302e10000000a44538d.html
- SAP Help — Correspondence Monitor (Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/6d0cda531198434de10000000a174cb4.html
- SAP Help — Term End-Postings after Migration — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/8308e6d301d54584a33cd04a9861bc52/27647bfe638d4a9c82607b298c2e62d6.html
- SAP Help — New Options for Automated Payment Runs (What's New in SAP S/4HANA 2025) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/f5d3e1005efd4e86acf9a65abf428082/34169a4b185546b5b7ff094d3953b0e5.html
- SAP Help — Period-End Closing (SAP ERP Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/4d6b9b32599844ee81b23a443efedb7f/7a237f586d809344e10000000a4450e5.html
- SAP Help — Hedge Accounting for Positions (P-HA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/49bff48439731b93e10000000a42189b.html
- SAP Help — Reverse Valuation (Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/8719c55368511d4be10000000a174cb4.html
- SAP Help — Parallel Processing in the Transaction Manager — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/8d76795346efe747e10000000a441470.html
- SAP Help — Net Payment for Cross-Currency Interest Rate Swaps (What's New in SAP S/4HANA 2021) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/c061826edf44483e844260408523224b.html
- SAP Help — Reporting on Forward Loan Purchases — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/4991557524454b6ba6538867d3c38e57.html
- SAP Help — Mass Price Adjustment for Raw Exposures — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/a103b06b87c64e6c80a761489a2e26c7.html
- SAP Help — DCS Based Market Data Provision — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/8308e6d301d54584a33cd04a9861bc52/81a2268a15a149888b4180b9bb4c83b4.html
- SAP Help — Activate Additional Checks in Translation Table for Currencies, Datafeed (What's New in SAP S/4HANA 2025) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/f5d3e1005efd4e86acf9a65abf428082/a12437ba25b444a0a9cd8e1fc4979581.html
- SAP Help — Exchange Rate (SAP S/4HANA Data Migration) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/3f7a1a6504ea4a6f966bf196ffde5518.html
- SAP Help — Archiving Effectiveness Tests with TRTM_HMLOG — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/4ea2a1515a2f4f58e10000000a42189e.html
- SAP Help — Releasing Commodity Hedging Relationships (TPM100) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/8308e6d301d54584a33cd04a9861bc52/e4fec81d50b94021a6b92515fa578fe9.html
- SAP Help — Exposure Management 2.0 — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/4c3af7c7b48f1ca9e10000000a42189e.html
- SAP Help — TRM, New Apps on SAP Fiori Launchpad (What's New in SAP S/4HANA 1709) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/4c6c3c99e6e94a92a626f424add61cba/c49666453f6b491aabf024aa34c611b7.html
- SAP Help — Cash Position (SAP ERP Cash and Liquidity Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/495b05f6dbb24b1da46e4027d3a28fef/65a264947e934a059eaa44d1e06267af.html
- SAP Help — Liquidity Forecast (SAP ERP Cash and Liquidity Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/495b05f6dbb24b1da46e4027d3a28fef/3219206619b44cd6aeeb2cec9dd6c137.html
- SAP Help — Display Cash Position (What's New in SAP S/4HANA 1610) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/26fd967701b1417f9c7b70da543e924d.html
- SAP Help — Display Liquidity Forecast (What's New in SAP S/4HANA 1610) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/ac2dcd9d87844a368f0b1b13df64074e.html
- SAP Help — Basic Cash Operations (What's New in SAP S/4HANA 1809) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/55421ea96597486784ecc3b581175cb5.html
- SAP Help — Payment Application Hierarchy (Loans Management, FS-CML) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/99fb46a79ab241d5984df80fe7a9aa32/59a8ce7064a54238b7dbca7d900dac87.html
- SAP Help — Down Payment Integration with SD (Central Finance) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/26c2d5e366bc44c1a98f2a9212a0c49d/66e9a64f930a4117a764d937f1cda9b4.html
- SAP Help — Merge Payments (Payments and Bank Communication) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/367ad0531d8b4208e10000000a174cb4.html
- SAP Help — Approve Payments, BNK_APP (SAP ERP, Roles in SAP Business Client) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_ERP/5cea947f5ec44813bdb75bc2d5115450/ca43348438e5430b971bf4843a8a6214.html
- SAP Help — Unique End-to-End Transaction Reference (UETR) Reporting (Financial Operations) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/3cb1182b4a184bdd93f8d62e3f1f0741/10a228aed3184d388cfb3102db01389a.html
- SAP Help — Approve Bank Payments (What's New in SAP S/4HANA 2022) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/29eae0d6e321430a989134ef649b9d37.html

## Questions this article answers

**Q: What transaction code do you use to create a deal in SAP TRM?**

FTR_CREATE (Create Financial Transaction) creates deals across the Transaction Manager's product areas — money market, foreign exchange, derivatives and securities. FTR_EDIT changes an existing transaction, FTR_DISPLAY shows it, and FTR_00 is the collective-processing worklist the back office uses to settle and confirm deals in bulk. In S/4HANA, SAP additionally documents the Manage Financial Transactions Fiori app (app ID F6157) alongside the classic transactions.

**Q: What is the difference between TBB1 and TPM10 in SAP Treasury?**

TBB1 (Post Flows) posts the flows of your financial transactions to the general ledger, and SAP's own documentation calls it Treasury: Post Flows; in recent S/4HANA releases it surfaces as the Fix, Pay and Post Flows app. TPM10 is what SAP ERP documentation calls Fix, Post or Reverse Transactions and the S/4HANA app catalog lists as Process Business Transactions — it fixes, posts and reverses the business transactions generated from positions. TPM18 (Fix and Post Derived Business Transactions) is its sibling that SAP's hedge accounting documentation uses, for example at contract close. A period-end close typically runs more than one of them, which is exactly why people mix them up.

**Q: Are classic SAP treasury transaction codes replaced by Fiori apps in S/4HANA?**

Partly, and SAP is explicit about the direction. The same GUI codes still run in S/4HANA on-premise and private edition, but the app catalog lists several under names like Treasury Posting Journal - Classic (TPM20), and SAP documents Fiori successors for specific cases: Manage Memo Records replaced the FF63/FF65 apps, FF7AN and FF7BN carry the cash position and liquidity forecast, and Manage Financial Transactions (F6157) sits alongside FTR_00. In SAP S/4HANA Cloud Public Edition the classic transactions are not available at all, so a Fiori-first habit is worth building now.

**Q: Which transaction code shows what treasury posted to the general ledger?**

TPM20, the Treasury Posting Journal, is the first stop: it lists the postings the Treasury subledger generated, and since S/4HANA 1909 it can show reversals and reversed postings on separate lines. TPM13 (position flows) shows the flows behind those postings, and TPM12 (position values) shows the position they belong to. On a posting investigation you typically walk exactly that chain: journal, flows, position.

---

# SAP TRM vs a Standalone TMS: Embedded or Best-of-Breed?

Source: https://gravam.com/blog/sap-trm-vs-standalone-tms
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-29
Updated: 2026-07-30
Reviewed: 2026-07-30
Summary: Run treasury inside SAP (TRM) or buy a standalone TMS? A vendor-neutral look at the embedded-vs-best-of-breed trade-off, the real drivers, and who each fits.

**SAP TRM vs a standalone TMS is the embedded-vs-best-of-breed decision, and it turns on one question: how much is integration with your ERP worth to you?** If you already run SAP, treasury can live inside it — [SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) — or you can buy a dedicated treasury system and integrate it. One isn't better than the other; they optimise for different things. This is the vendor-neutral way to tell which fits, without a feature-count contest and without naming a winner.

## Two philosophies, not two products

An **embedded** approach (SAP TRM) treats treasury as part of your core system: the deals, valuations, cash and postings share one record with the accounting they feed. A **best-of-breed** approach treats treasury as a specialised discipline that deserves a system built only for it, connected to your ERP through an interface. Everything else is a consequence of that choice.

|  | SAP TRM (embedded) | Standalone TMS (best-of-breed) |
| --- | --- | --- |
| **Core strength** | Integration — one record with accounting and cash | Depth — treasury-specific capability and workflow |
| **Data model** | Shared S/4HANA spine, no interface to reconcile | Its own model, integrated to your ERP |
| **You adopt** | SAP's treasury model and roadmap | A treasury vendor's model and roadmap |
| **The cost** | Fitting your needs to the embedded module | Building and owning an ERP integration + another vendor |

## What the embedded option actually buys you

The case for SAP TRM is almost entirely integration. Treasury sits next to the general ledger, so a deal's [posting and valuation](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) flow through the same system, cash management and exposures share the same spine, and there's no separate system to reconcile at every close. If you're ERP-centric and already invested in SAP, that "one record" is a genuine, recurring saving — and it's the option you should try to _disprove_ before you shop, because starting from what you already run is usually the cheaper path when it fits. The [deployment and edition](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison) choice then sits underneath it.

It helps to know what "SAP TRM" concretely contains. It isn't one monolith but a set of components, each documented on SAP Help:

| Component | What it covers |
| --- | --- |
| **Transaction Manager** | Front-to-back deal processing — money market, FX, derivatives, securities and debt, from capture through settlement to posting |
| **Market Risk Analyzer** | Market-risk analytics on those positions — sensitivities, scenario analysis, value at risk |
| **Credit Risk Analyzer** | Counterparty risk — limit setting, monitoring and utilisation |
| **Exposure Management** | Collects the operating FX and commodity exposures from the business (One Exposure) that hedging works from |
| **Hedge Management** | Hedge relationships — designation, effectiveness and hedge accounting, feeding the postings above |

(There is also a Portfolio Analyzer for performance analysis.) The point of listing them: "embedded" doesn't mean "thin". The question is whether these components reach _your_ requirements, not whether they exist.

The honest limit: you adopt SAP's model. Where your treasury needs something the embedded module doesn't reach, you're customising or working around it rather than buying a system that already does it.

## What a standalone TMS actually buys you

The case for best-of-breed is depth and independence. A dedicated treasury system — think Kyriba, FIS Quantum, ION Reval or Ripple Treasury (formerly GTreasury), to name four of the best-known; examples, not endorsements — is built around treasury's own workflows, which can mean deeper capability at the hard edges (connectivity breadth, forecasting, risk analytics), a treasury-shaped user experience, and a roadmap that isn't tied to your ERP programme. When complexity is high enough — many entities, many banks, real hedging and risk — that specialisation is worth paying for.

The honest limit: you own an integration. Treasury data now lives outside your ERP, so you build and maintain the interface, reconcile across two systems, and manage a second vendor. That's the same [best-of-breed vs one-integrated-system](https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets) trade every finance function faces, applied to treasury. And choosing best-of-breed opens a second fork — one treasury suite, or a core system extended module by module — which is the [modular vs monolithic TMS](https://gravam.com/blog/modular-vs-monolithic-treasury-management-system) decision.

## How to decide

Run it as two moves, not a bake-off:

1. **Scope what treasury actually needs to do**, then see how much of it the embedded option covers. The [SAP Treasury module selector](https://gravam.com/tools/sap-treasury-module-selector) maps your needs to the SAP components that address them, so you can judge the embedded fit honestly before assuming you need to buy.
2. **If the gap is real, score the standalone options** on your own weighted priorities — connectivity, forecasting, risk, usability, total cost — with a [vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard) rather than a feature count, and inside the broader [build-vs-buy](https://gravam.com/blog/build-vs-buy-treasury-management-system) frame.

The drivers that push you toward standalone are complexity, treasury-specific depth, and a wish to decouple from your ERP roadmap. The drivers that keep you embedded are integration value, an existing SAP investment, and moderate needs. Weigh those honestly and the "vs" resolves itself.

## The honest answer

There's no universal winner between SAP TRM and a standalone TMS — there's a fit. Embedded wins when integration is the point; best-of-breed wins when treasury depth and independence are. Disprove the embedded option first because it's usually cheaper when it fits, and only pay for a separate system once you can name the specific gap it closes.

***

_Scope the embedded fit with the [SAP Treasury module selector](https://gravam.com/tools/sap-treasury-module-selector), or score standalone options with the [TMS vendor scorecard](https://gravam.com/tools/tms-vendor-scorecard)._

## Primary sources

- SAP Help — Treasury and Risk Management (SAP S/4HANA) — accessed 2026-07-29 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/3b3e7e53c4d1cc26e10000000a4450e5.html
- SAP Help — Treasury Accounting (SAP S/4HANA Cloud) — accessed 2026-07-29 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/bc153a383f0d4c39a34a26523af97751.html
- SAP Help — One Exposure from Operations: Source Applications (SAP S/4HANA) — accessed 2026-07-29 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/abd32554225fea6fe10000000a423f68.html
- ACT, The Treasurer — Treasury management systems: A double-edged sword? (ERP-integrated vs standalone trade-off) — accessed 2026-07-29 — https://www.treasurers.org/hub/treasurer-magazine/treasury-management-systems-double-edged-sword
- AFP — Treasury Management System: Overview, Functionalities and Benefits — accessed 2026-07-29 — https://www.financialprofessionals.org/glossary/treasury-management-system
- AFP — Best Practices in Treasury Connectivity (channels, formats, vendor-maintained bank connections) — accessed 2026-07-29 — https://www.financialprofessionals.org/training-resources/resources/articles/Details/best-practices-in-treasury-connectivity
- Kyriba — Liquidity Performance Platform (vendor site) — accessed 2026-07-30 — https://www.kyriba.com/
- FIS — Treasury and Risk Manager, Quantum Edition (vendor site) — accessed 2026-07-30 — https://www.fisglobal.com/products/fis-treasury-and-risk-manager-quantum-edition
- ION — Treasury and Risk Management Solutions (Wallstreet Suite, Reval and others) — accessed 2026-07-30 — https://iongroup.com/treasury/
- Ripple Treasury (formerly GTreasury) — vendor site — accessed 2026-07-30 — https://treasury.ripple.com/

## Questions this article answers

**Q: Should I use SAP TRM or a standalone TMS?**

SAP TRM versus a standalone TMS is the classic embedded-vs-best-of-breed trade-off, and the honest answer depends on how ERP-centric you are. If you already run SAP and value one integrated record — treasury sitting next to the accounting it posts to, no interface to reconcile — SAP Treasury and Risk Management is the option to disprove first. If your treasury complexity outruns what an embedded module reaches, or you want treasury-specific depth and speed independent of your ERP roadmap, a standalone TMS earns its cost and its integration effort. Neither is universally better.

**Q: What does SAP TRM give you that a standalone TMS doesn't?**

Integration, primarily: treasury data lives in the same S/4HANA system as your accounting and cash, so there's one record rather than an interface to build and reconcile, and postings, valuation and cash flow share a spine. You also avoid running and integrating a separate vendor system. The trade is that you adopt SAP's model and roadmap rather than a system designed only for treasury.

**Q: When is a standalone TMS the better choice?**

When treasury depth and independence matter more than ERP integration: very high complexity, treasury-specific workflows and usability, faster bank-connectivity onboarding via the pre-built bank connections TMS vendors maintain, or a desire to decouple treasury from your ERP programme. The cost is a real integration to your ERP and another vendor to manage — which is exactly what you weigh on your own priorities rather than a feature list.

---

# SAP Treasury Implementation Roadmap & Module Selection

Source: https://gravam.com/blog/sap-treasury-implementation-roadmap-and-module-selection
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Which SAP Treasury modules do you need, in what order? A decision-led roadmap across TRM, Cash Management, BCM, APM and In-House Cash, scoped to release.

**SAP Treasury is modular, and the most expensive implementation mistake is treating it as one thing to switch on.** Teams ask "how do we implement SAP Treasury?" as if it were a single product. It isn't — it's a set of components (Cash Management, Transaction Manager, the analyzers, Bank Communication Management, Advanced Payment Management, In-House Cash) that you select and sequence against real requirements. Get the selection and order right and each phase stands on a solid foundation. Get it wrong — risk analytics before clean positions, a payment hub before connectivity — and you front-load the hardest dependencies into the riskiest phase. This is the roadmap, framed as the decisions it actually is. (It assumes the prior question — [SAP TRM or a standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms) — has already landed on SAP.)

> **Scope first.** Module availability, the business functions you activate (on-premise, via transaction SFW5) and the Fiori apps all differ by release and by edition — on-premise, Private Cloud, Public Cloud. This roadmap is the decision logic; verify the exact scope for your target system against SAP's documentation, and read it alongside the [deployment & edition comparison](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison).

## Select by requirement, not by catalogue

The first discipline is refusing to implement a module because it exists. Every module should trace to a requirement you can state in one sentence. Map need → module before anything else:

| If you need to… | The module(s) | Depends on |
| --- | --- | --- |
| Manage bank accounts and signatories centrally | **Bank Account Management (BAM)** | — |
| See the cash position and liquidity forecast | **Cash Management** (One Exposure) | BAM, bank statements |
| Manage FX, MM, securities, derivatives | **Transaction Manager** (part of TRM) | Cash Mgmt foundation |
| Measure and limit market / credit risk | **Market / Credit / Portfolio Analyzer** | Positions in TRM |
| Apply hedge accounting | **Hedge Management** | Transaction Manager |
| Approve and monitor outgoing payment batches | **Bank Communication Management (BCM)** | Payment run, banks |
| Run a central, orchestrated payment hub | **Advanced Payment Management (APM)** | Connectivity, formats |
| Run an internal bank / POBO / intercompany | **In-House Cash (IHC)** | Central treasury |

If a row has no requirement behind it, it isn't in your roadmap. That single rule kills more scope creep than any governance forum. (To run this mapping on your own requirements, the [SAP Treasury Module Selector](https://gravam.com/tools/sap-treasury-module-selector) does exactly this — tick your needs and it returns the component list, each linked to its guide.)

## The dependency ladder: implement bottom-up

Modules depend on each other, and the order that works is the order of dependency — foundation first, then what builds on it. Each layer needs the one beneath it to be clean before it can be trusted.

1. **Foundation — visibility and positioning.** Bank Account Management and Cash Management (with [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow)) give you accounts, bank statements, balances and the cash position. Almost every treasury needs this, and everything else reads from it.
2. **Instruments — Transaction Manager.** Once you have a clean cash foundation, add the instruments you actually trade, and their [position management, valuation and accounting](https://gravam.com/blog/sap-transaction-manager). Instruments valued on shaky positions are just faster wrong numbers.
3. **Risk — the analyzers.** Market Risk, Credit Risk and Portfolio Analyzer measure and limit risk _on the positions Transaction Manager holds_. They're meaningless without the layer below.
4. **Payments & structures — BCM, APM, IHC.** Formalise how money moves — batch approval and monitoring (BCM), a central payment hub (APM), and internal banking (IHC) — once the core is stable and connectivity exists.

> Sequence by dependency, not by enthusiasm. Risk analytics before clean positions, or a payment hub before bank connectivity, moves the hardest problems into the phase least able to absorb them. Log each cross-module dependency with an owner and a date — the D in a [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) — so a slipping foundation is visible before the layer above it starts.

## Phasing: scope each phase to a real go-live

The ladder isn't a single big-bang. Each layer is a phase with its own requirement, its own scope, and its own go-live — because a treasury that can see its cash is already delivering value before instruments or risk are live. Phasing lets you:

- **Bank value early.** Visibility and positioning (phase 1) pays back on its own.
- **Contain risk.** Each phase is a smaller, testable change than "all of treasury at once."
- **Learn before you commit the hard parts.** The organisation gets fluent in the foundation before you layer risk analytics or a payment hub on top.

The anti-pattern is scoping the whole of treasury into one programme and discovering the dependencies during cutover. Treat module selection and phasing as the same decision: _what do we need, and what must be true before we can build it?_

## Where release and edition change the answer

Module selection isn't purely functional — it's constrained by your platform. What's available, how it's activated, and how extensible it is depends on the edition:

- **On-premise / Private Cloud** preserve the fullest scope and extensibility; several enterprise treasury functions are switched on via **business-function activation (SFW5)**, and you control the configuration depth.
- **Public Cloud** is standardised — some modules, extensions or configuration depth may not be available or may work differently.

So a module that's clearly in scope on one edition may be constrained on another. This is exactly why the roadmap has to be read against your [deployment choice](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison), and why "verify against your release and edition" isn't boilerplate — it's the difference between a roadmap that survives contact with your system and one that doesn't.

## Sequencing mistakes in SAP treasury roadmaps

- **Big-bang everything.** All modules in one programme, so every dependency lands at once in cutover.
- **Modules without requirements.** Installing an analyzer or a payment hub because it's there, then carrying the config and support cost for something nobody uses.
- **Risk before positions.** Standing up risk analytics on positions that don't yet tie — measuring risk on numbers you can't trust.
- **Edition surprises.** Designing for on-premise capability on a Public Cloud platform, and discovering the constraint mid-build.
- **Ignoring the ECC history.** Coming from ECC and not deciding conversion vs re-implementation per the [migration path](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana), so old complexity is carried or lost by accident.

## Which SAP treasury modules to start with

Start with the foundation — Bank Account Management and Cash Management — for almost any treasury, and prove visibility and positioning before adding anything. Add Transaction Manager only when there are instruments to manage, and the analyzers only when there's a real risk-measurement and limit requirement. Treat BCM, APM and In-House Cash as their own decisions driven by payment volume, centralisation and structure — not as automatic add-ons. And scope every module to a one-sentence requirement and a real go-live. A smaller SAP Treasury that answers real needs beats a complete one that carries modules nobody asked for.

***

_See also [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) and [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana)._

## Primary sources

SAP S/4HANA. Module names, availability, business functions (activated via SFW5 on-premise) and Fiori apps differ by release and edition (on-premise / Private Cloud / Public Cloud). Confirm the exact scope for your target system against SAP's documentation.

- SAP Help — Treasury and Risk Management (SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/3b3e7e53c4d1cc26e10000000a4450e5.html
- SAP Help — Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/e7d3a052c3ad224fe10000000a445394.html

## Questions this article answers

**Q: Which SAP Treasury modules does a company need?**

Only the ones that map to a real requirement — SAP Treasury is modular, not all-or-nothing. Bank Account Management and Cash Management (with One Exposure) are the common foundation almost every treasury needs for visibility and positioning. Transaction Manager (part of Treasury and Risk Management) is needed when you manage financial instruments — FX, money market, securities, derivatives — and want them valued and posted. The analyzers (Market Risk, Credit Risk, Portfolio) are added when you need to measure and limit risk. Bank Communication Management, Advanced Payment Management and In-House Cash are payment- and structure-specific. The roadmap is driven by requirements, not by installing everything.

**Q: What is the right order to implement SAP Treasury?**

Foundation first, then instruments, then risk, then payment and in-house structures — because each layer depends on the one below it. Bank Account Management and Cash Management give you accounts, balances and the cash position; Transaction Manager adds instruments and their accounting on top of that foundation; the analyzers measure risk on the positions Transaction Manager holds; payment hubs and In-House Cash formalise how money moves once the core is in place. Trying to implement risk analytics before you have clean positions, or a payment hub before you have bank connectivity, front-loads the hardest dependencies. Sequence by dependency, and scope each phase to a real requirement and a real go-live.

**Q: Is SAP Treasury all-or-nothing?**

No. SAP Treasury is a set of components you activate and configure to fit your requirements — on-premise, several enterprise functions are switched on via business-function activation (transaction SFW5), and the available modules and Fiori apps differ by release and edition. A company might run only Cash Management and Bank Account Management for visibility, or add Transaction Manager and the analyzers for a full front-to-back treasury. The mistake is treating it as one monolith to switch on; the discipline is selecting the modules that answer your requirements and sequencing them by dependency.

---

# SAP Payments: BCM, APM & Output Management Boundaries

Source: https://gravam.com/blog/sap-bcm-apm-output-management-architecture
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Where does payment output management end, Bank Communication Management begin, and Advanced Payment Management fit? Boundaries in SAP's outgoing-payment stack.

**"SAP payments" isn't one thing — it's a stack of layers, and most confusion comes from not knowing which layer owns what.** Output management, Bank Communication Management, Advanced Payment Management: teams treat these as competing options or interchangeable names, when they're actually distinct responsibilities in the journey of an outgoing payment. Format generation is not approval; approval is not routing; routing is not transmission. Get the boundaries clear and you can design, troubleshoot and explain the payment stack precisely. Blur them and you'll spend every payment incident arguing about which component "should have" handled something it was never responsible for. This is the boundary map.

> **Architectures differ.** The outgoing-payment stack, and exactly where each responsibility sits, depends on your release, edition, and whether you run a classic payment-run design (F110 + PMW + BCM) or an APM-centric hub. This article maps the _responsibilities_; confirm how they're arranged in your own system against SAP's documentation.

## The layers of an outgoing payment

Follow one payment from ledger to bank and the distinct responsibilities separate cleanly:

| Layer | Component (typical) | Owns |
| --- | --- | --- |
| **Payment data** | Payment run (e.g. F110) | Deciding what to pay, to whom, from which bank |
| **Medium generation** | **Payment Medium Workbench + DMEE** | Producing the payment file in the bank's format |
| **Approval & monitoring** | **Bank Communication Management** | Batching, approval/release workflow, status monitoring |
| **Central orchestration** | **Advanced Payment Management** | Receiving, standardising and routing group-wide payments |
| **Transmission** | Connectivity (host-to-host/SWIFT/MBC) | Actually sending the file and receiving status |

Two boundaries cause most of the confusion, so name them precisely.

## Boundary 1: output management vs BCM

**Output management makes the file. BCM governs its journey.**

The Payment Medium Workbench (PMW), using [DMEE format trees](https://gravam.com/blog/sap-dmee-payment-file-format-tree), evaluates the payment data and generates the payment medium — the DME file — in the format the bank requires. Payment methods can even use different formats per house bank and company code, so the _same_ payment method produces the _right_ file for each bank. That's output management's job: correct medium, correct format.

Bank Communication Management doesn't generate the file — it wraps the process around it: grouping payments into batches, driving the **approval and release** workflow (who signs off before money moves), and **monitoring the status** of batches to and from the bank. When a payment is "stuck for approval," that's BCM. When a payment file is "in the wrong format," that's output management. Different layer, different owner, different fix.

> Output management answers "is the file right?" BCM answers "is the batch approved, and where is it now?" Confusing the two turns a two-minute triage into a two-team argument.

## Boundary 2: BCM vs APM

**BCM governs a batch. APM is the hub for all payments.**

Advanced Payment Management operates at a different altitude. It's a **central [payment hub](https://gravam.com/blog/payment-hub-vs-payment-factory)**: it receives payment requests from across the group — SAP and non-SAP sources — standardises them, and routes them to the right bank channel, so every outbound payment flows through one controlled, monitored layer. That's the [payment factory](https://gravam.com/blog/what-is-a-payment-factory) pattern realised in SAP.

BCM is narrower and process-level: the approval and status-monitoring of payment batches. You can run BCM without APM (classic design) and APM changes where orchestration and routing sit. In an APM-centric architecture, the hub becomes the central point payments pass through; in a classic architecture, the payment run, PMW and BCM carry the flow. **Which you have determines where format generation and routing actually happen** — so the boundary between BCM and APM is partly an architecture decision, not a fixed line.

## Where In-House Cash sits

[In-House Cash (IHC)](https://gravam.com/blog/sap-in-house-cash-ihc) is adjacent, not part of this stack: it's the internal bank that handles intercompany and payments-on-behalf-of (POBO), generating the payment requests that then flow _into_ this outgoing stack. IHC decides the internal leg; the stack above handles the external leg to the bank. Keeping that separation clear stops IHC and APM being conflated — one is internal banking, the other is the outbound payment hub.

## Blurring the BCM, APM and output layers

- **Treating the components as alternatives.** "Should we use BCM or output management?" is a category error — you need medium generation _and_ approval/monitoring; they're different layers.
- **Assuming one universal architecture.** Designing as if APM, BCM and PMW always divide the same way, when the split depends on release, edition and whether you run a hub.
- **Troubleshooting at the wrong layer.** Chasing a format problem in BCM, or an approval delay in output management, because the boundary was never made explicit.
- **Conflating IHC with the payment hub.** Treating internal banking and outbound orchestration as one thing.

## Choosing between a payment hub and a classic run

Map your own stack first — for one real payment, name which component owns each layer (data, medium, approval, orchestration, transmission). That single diagram resolves most design and support disputes before they start. Choose an APM-centric hub when you genuinely need one controlled path for all group payments across SAP and non-SAP sources; keep the classic payment-run + PMW + BCM design when a hub would be more machinery than the payment volume justifies. Either way, hold the boundaries explicitly, and verify against your release and edition — because the one thing that's always true is that "SAP payments" is a stack, and every layer has an owner.

***

_See also [Bank Communication Management (BCM) in SAP](https://gravam.com/blog/bank-communication-management-bcm-sap) and [SAP Advanced Payment Management (APM)](https://gravam.com/blog/sap-advanced-payment-management-apm)._

## Primary sources

SAP S/4HANA. The outgoing-payment stack (PMW/DMEE, BCM, APM, connectivity) and how responsibilities divide differ by release, edition and whether you run a classic F110+PMW+BCM design or an APM-centric hub. Confirm the exact architecture for your target system against SAP's documentation.

- SAP Help — Payment Medium Workbench (PMW) / DMEE — accessed 2026-07-28 — https://help.sap.com/docs/SUPPORT_CONTENT/fiaccounting/3361880730.html
- SAP Help — Bank Communication Management (SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/95a8510ebc24461f87c65d2eb3c62288.html
- SAP Help — Advanced Payment Management (SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/2945c7d799ac46f0bdb0267f9fd7a289.html

## Questions this article answers

**Q: What is the difference between BCM and output management in SAP?**

Output management (the Payment Medium Workbench and DMEE) generates the payment file — it evaluates the payment data from the payment run and produces the payment medium in the bank's required format. Bank Communication Management sits around that: it batches outgoing payments, drives the approval/release workflow, and monitors the status of the batches as they go to and return from the bank. Put simply, output management makes the file; BCM controls and tracks the file's journey. They're complementary layers, not alternatives — one produces the medium, the other governs and monitors it.

**Q: What does SAP Advanced Payment Management (APM) do that BCM doesn't?**

APM is a central payment hub: it receives payment requests from across the group (SAP and non-SAP sources), standardises and orchestrates them, and routes them to the right bank channel — a single controlled layer for all outbound payments. BCM, by contrast, is focused on the approval and status-monitoring of payment batches within the payment process. APM operates at the architectural level of 'all payments flow through one hub'; BCM operates at the level of 'this batch is approved and tracked.' Many landscapes use both, and the exact division depends on whether you've adopted an APM-centric hub or a classic payment-run design.

**Q: How do PMW, BCM and APM fit together?**

Think of the outgoing payment as passing through layers: the payment run produces payment data; the Payment Medium Workbench (with DMEE formats) generates the payment medium in the bank's format; Bank Communication Management approves and monitors the batch; a connectivity layer transmits it to the bank; and status messages come back. Advanced Payment Management can sit above this as a central hub that receives and routes payments across the group. Which components you use, and exactly where format generation and routing happen, depends on your release, edition and whether you run a classic or hub-centric architecture — so map your own stack rather than assuming one universal picture.

---

# SAP Treasury Deployment & Edition Comparison

Source: https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: On-premise, S/4HANA Cloud Private or Public Edition — how the deployment choice shapes SAP treasury: extensibility, upgrade control, TCO and the real drivers.

**For SAP treasury, the deployment decision is made above your head — and then shapes everything you can do.** Treasury doesn't get its own deployment model; it runs on whichever S/4HANA edition the enterprise chose. But that choice — on-premise, Cloud Private Edition, or Cloud Public Edition — quietly sets the boundaries of your [SAP treasury](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) build: how much you can extend, how you connect to banks, who controls the upgrade calendar, and what the whole thing costs to run. Understanding those boundaries is how treasury shows up to the deployment conversation with real requirements instead of discovering the constraints after go-live. This is the comparison, framed as the decision it actually is. (And if the deeper question is whether treasury should run in SAP at all, that's the [SAP TRM vs standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms) decision — this article assumes SAP.)

> **Verify the specifics.** This article compares the _dimensions_ of the choice. The exact availability of individual treasury features (TRM, Cash Management, connectivity options) by edition is release-specific and evolves — always confirm against SAP's current Feature Scope Description and product documentation for your target release before committing.

## The three models, at the level that matters

| Dimension | On-premise | Cloud Private Edition (RISE) | Cloud Public Edition |
| --- | --- | --- | --- |
| **What it is** | You own and run it | Dedicated single-tenant, subscription | Standardized multitenant SaaS |
| **Scope & flexibility** | Full; extend freely | Largely on-premise scope & flexibility | Standardized; limited customization |
| **Upgrades** | You plan and run them (high effort) | Customer-paced, within mainstream support; you manage the process | SAP-driven, fixed and mandatory |
| **Infrastructure** | Yours to buy and maintain | Managed (RISE) | Managed by SAP |
| **ECC conversion** | System conversion, keep config | System conversion, retain config & extensions | Typically a re-implementation ("new") |
| **Cost profile** | Capex + high upgrade/maintenance | Subscription; single-tenant cost | Usually most affordable, lowest maintenance |
| **Best when…** | Maximum control, heavy custom | On-prem flexibility, cloud operating model | Standard processes, lowest TCO |

The pattern the table encodes: **flexibility and cost trade against each other, with upgrade control as the hinge.** On-premise and Private Edition preserve extensibility and let you choose _when_ to upgrade; Public Edition gives that up for lower cost and lower maintenance, with SAP driving the calendar.

## The three questions that actually decide it — for treasury

Treasury's requirements land hardest on three dimensions. Answer these honestly and the edition largely chooses itself.

### 1. How much do you need to extend and customize?

Treasury is one of the more configuration- and often custom-logic-heavy areas of finance — bespoke instruments, complex account determination, tailored reporting, integration glue. Public Edition's standardized, limited-customization model can be a genuine constraint here; Private Edition and on-premise preserve the room to extend. The question isn't "do we have customizations" (everyone thinks they do) but "which are _essential_, and does the standardized model actually cover them?" — a question only SAP's feature scope for your release can answer.

### 2. Who controls the upgrade calendar?

Treasury sits on hard external deadlines — period close, regulatory dates, bank changes. **Mandatory, SAP-timed upgrades** (Public Edition) mean the platform can change under you on SAP's schedule, not yours; **customer-paced upgrades** (Private Edition, on-premise) let you sequence change around treasury's calendar — at the cost of owning the upgrade work. For a treasury that can't absorb a surprise change mid-close, upgrade control is not a minor line item.

### 3. What's your bank connectivity and integration reality?

Treasury's riskiest surface is [bank connectivity and integration](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics). Deployment shapes what's possible and how it's operated — the connectivity options, the middleware, the control you have over the technical setup. This is often where a Public Edition assumption meets a treasury reality, so it deserves explicit checking against the edition's supported connectivity rather than an assumption that "the cloud handles it."

> For treasury the deployment choice is really a control choice: how much can you extend, and who owns the upgrade calendar. Cost follows from those, not the other way around.

## Where migration meets deployment

If you're coming from ECC, the edition choice and the [migration path](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana) are entangled. On-premise and Private Edition support a **system conversion** that retains configuration and extensions — attractive when treasury carries years of embedded logic. Public Edition typically means a **fresh re-implementation** of standardized processes — a bigger change for treasury, but a chance to shed accumulated complexity. Neither is universally right; the point is to decide it deliberately, knowing which your treasury's history and requirements favour.

## What good looks like

- **Treasury shows up to the deployment decision with real requirements** — essential extensions, upgrade-timing constraints, connectivity needs — not after it.
- **Feature scope is verified against SAP's documentation for the target release**, not assumed from a general "cloud vs on-prem" picture.
- **The choice is framed as control vs cost**, with upgrade autonomy as the deciding hinge, and treasury's calendar sensitivity weighed explicitly.
- **The migration path is chosen with the edition** — conversion (keep config) vs re-implementation (standardize) — as one decision, not two.

The deployment model isn't a treasury decision, but living with it is a treasury reality. Understand the three models as a trade between flexibility, control and cost — and verify the specifics against SAP's own documentation for your release — and treasury enters the conversation able to protect what it actually needs. (The [SAP Treasury Module Selector](https://gravam.com/tools/sap-treasury-module-selector) pairs this edition trade-off with the component mapping, if you want both on one screen.) Skip that, and you'll meet the boundaries of the edition the hard way: mid-project, when they're most expensive to work around.

***

_See also [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) and [migrating SAP Treasury from ECC to S/4HANA](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana)._

## Primary sources

SAP S/4HANA. Deployment models and their boundaries evolve; exact treasury (TRM / Cash Management) feature availability by edition MUST be verified against SAP's Feature Scope Description / product documentation for your target release and edition. This article compares the decision dimensions, not a fixed capability list.

- SAP Help — Treasury and Risk Management (official product documentation; verify edition feature scope here) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/3b3e7e53c4d1cc26e10000000a4450e5.html
- SAP — SAP S/4HANA Cloud and On-Premise Deployment Options (SAP-authored) — accessed 2026-07-28 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-s-4hana-cloud-and-on-premise-deployment-options/ba-p/13410008
- SAP — Functional differences between SAP S/4HANA Cloud Private Edition and SAP S/4HANA (On-premise) (SAP-authored) — accessed 2026-07-28 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/functional-differences-between-sap-s-4hana-cloud-private-edition-and-sap-s/ba-p/13568237

## Questions this article answers

**Q: What are the SAP S/4HANA deployment options for treasury?**

Three, and the treasury module runs on the same platform choice as the rest of the ERP: on-premise (you own and run it, full scope and extensibility, but you own the upgrades and infrastructure); S/4HANA Cloud Private Edition (a dedicated instance, largely on-premise scope and flexibility delivered as a subscription under RISE with SAP, with customer-paced upgrades within mainstream support); and S/4HANA Cloud Public Edition (a standardized multitenant SaaS, most affordable and lowest-maintenance, but with limited customization and SAP-driven, mandatory upgrades). The treasury decision is really the ERP deployment decision, viewed through treasury's specific needs for extensibility and control.

**Q: Which SAP edition is best for treasury?**

The best SAP edition for treasury depends on how much extensibility, integration control and upgrade autonomy your treasury needs — there's no universal best. Treasuries with heavy custom logic, complex bank connectivity, and a need to control upgrade timing tend toward Private Edition or on-premise, which preserve on-premise scope and flexibility. Treasuries that can adopt standardized processes and want the lowest maintenance and cost lean toward Public Edition, accepting less customization and SAP-driven upgrades. The honest answer for any specific treasury is: map your real requirements to the edition boundaries, and verify the exact feature scope for your target release against SAP's documentation before deciding.

**Q: What is the difference between S/4HANA Cloud Private Edition and Public Edition?**

Private Edition is a single-tenant, dedicated instance that keeps much of the scope and flexibility of on-premise — you can extend and customize more, retain configuration when converting from ECC, and choose your upgrade pace within mainstream support, but you manage that upgrade process; it's the RISE with SAP subscription model. Public Edition is a multitenant SaaS where you share infrastructure, customization is limited, and upgrades are standardized and mandatory (applied by SAP to all tenants). Private trades higher cost and more responsibility for flexibility and control; Public trades flexibility for lower cost and lower maintenance.

---

# SAP TRM Accounting & Posting Architecture

Source: https://gravam.com/blog/sap-trm-accounting-and-posting-architecture
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: How a treasury deal becomes a G/L posting in SAP TRM: account determination via symbols, valuation areas for parallel accounting, and ledger reconciliation.

**In SAP TRM, a deal isn't an accounting entry — it's the start of a chain that _becomes_ one.** Capture a deal in Transaction Manager and you've created a business fact. Between that fact and a line in the general ledger sits an architecture most treasury projects underestimate: a position, its flows, valuation under one or more accounting principles, and an account-determination mechanism that turns abstract intent into real G/L accounts. Get that architecture right and the ledger reconciles quietly, close after close. Get it wrong and you spend every period-end chasing why the subledger and the G/L disagree.

This is the part the [position-and-valuation](https://gravam.com/blog/sap-trm-position-management-and-valuation) view sets up and the standard documentation treats as scattered configuration. Here it's one picture: how a deal becomes a posting, and where it reconciles.

## The lifecycle: deal → position → flows → valuation → posting

Every accounting-relevant thing TRM does moves through the same stages. Knowing the stage a number is at tells you which configuration governs it.

| Stage | What it is | What governs the accounting |
| --- | --- | --- |
| **Deal** | The business transaction captured in Transaction Manager | Product & transaction type; nothing posts yet |
| **Position** | The holding the deal contributes to | Position management; the account assignment reference |
| **Flows** | The datable cash and accounting events the deal generates | Flow types / update types — which events are relevant |
| **Valuation** | Period-end measurement under an accounting principle | Valuation area and its valuation rules |
| **Posting** | The transfer of relevant flows and valuation results into FI | Account determination (symbols → assignment reference → G/L) |
| **Reconciliation** | Proving the subledger and the G/L represent the same events | All of the above, working together |

The discipline this buys you: when a number is wrong, you don't ask "why is the posting wrong?" — you ask _which stage_. A missing accrual is a flow/relevance question; a wrong account is determination; a valuation that only hit one ledger is a valuation-area question. Same as [debugging cash flows](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting): localise the stage, then fix the cause. The close itself runs through a small family of codes — TBB1, TPM1, TPM10, TPM18 — and [the treasury transaction-code reference](https://gravam.com/blog/sap-treasury-transaction-codes) maps which does what.

## Account determination: symbols, references, accounts

This is the heart of it, and the part that most rewards understanding _why_ it's built the way it is. TRM never posts to a hard-coded G/L account. It posts to an **account symbol** — an abstract placeholder for a _role_ in the entry: the position account, interest revenue, an accrual/deferral account, a bank clearing account, a payment account.

Each symbol resolves to a real G/L account depending on the **account assignment reference** — a key that groups positions which should post to the same accounts. The reference is _derived_ for a position (via substitution rules) at the moment the position is created, and from then on it drives every posting for that position.

So the chain is always:

```text
Business event  →  Account symbol  →  Account assignment reference  →  G/L account
   (a flow)         (the role)          (the grouping key)              (the real account)
```

Two consequences worth internalising:

- **The reference is set at position creation and drives everything after.** If it derived wrong, later postings inherit the mistake. You can maintain the account assignment reference manually on the position indicator when derivation fails — but only **before the first posting** for that position; once something has posted, it's locked. That single rule explains a large share of "we can't fix the account now" situations.
- **Symbols keep the chart of accounts out of the treasury logic.** The same TRM configuration works across company codes with different accounts, because the account lives at the end of the chain, not inside the deal.

## Parallel accounting: one deal, many ledgers

A single instrument rarely has one "value." Under local GAAP and IFRS it can be measured differently — amortised cost here, fair value there, different accrual treatment. TRM handles this with **valuation areas**: each area carries its own valuation rules and **posts its results separately**, so one deal produces parallel valuation and accounting entries under each principle without being entered twice.

> The deal and the position are shared. The valuation and its postings are per valuation area. That single split is what lets one treasury book satisfy two accounting worlds from one entry.

This is also where accrual/deferral and period-end valuation live: the accruals that spread interest across periods and the valuation runs that mark positions at period-end are executed per valuation area and posted through the same account-determination chain. When one ledger is right and another is wrong, the fault is almost always a valuation-area configuration gap — not the deal.

## Hedge accounting sits on top, not beside

[Hedge accounting](https://gravam.com/blog/hedge-accounting-explained) doesn't replace this architecture — it constrains it. A designated hedge relationship changes _which_ valuation and posting treatment applies (deferring fair-value movements to a reserve rather than P&L, for instance), but it still flows through valuation areas and account determination to reach the ledger. Treat hedge accounting as a layer that changes the _rules_ a valuation area applies, not a separate posting path, and it stops feeling like a bolt-on.

## Reconciling to the ledger

Because Transaction Manager transfers the accounting-relevant results into FI, the subledger (deals and positions) and the G/L are two views of the same events. Reconciliation is proving they still agree — and when they don't, the break is almost never in the ledger. Work it in this order:

1. **Unposted flows.** An accrual, payment or valuation result that's relevant but hasn't posted. The subledger "knows" about an event the G/L hasn't seen.
2. **Account determination.** A missing or wrong account assignment reference sending a symbol to the wrong (or no) account — the classic source of a position that posts "somewhere odd."
3. **Valuation-area gaps.** A principle that valued but didn't post, or posted to one ledger and not the parallel one.
4. **Timing / date basis.** A flow posted in a different period than the view you're reconciling.

The through-line with the rest of the module is the same: **the ledger is faithfully recording what it was told.** The fix is upstream — in relevance, determination or valuation config — not in a manual G/L correction that papers over the cause until next close.

## What good looks like

- **Account assignment references derived, not maintained by hand.** Manual maintenance is the escape hatch for a derivation gap, not the operating model — and it's impossible once a position has posted, so fix the derivation.
- **Valuation areas mapped deliberately to your accounting principles**, each posting its own results, so parallel accounting is by design rather than reconciled after the fact.
- **A per-stage mental model.** When a number's wrong, name the stage — flow, valuation, determination, timing — before touching anything.
- **Reconciliation as evidence, not a hunt.** Subledger-to-G/L agreement proven each period, with breaks traced to a stage, not smoothed over in the ledger.

Understand TRM's posting architecture as one chain — deal to position to flows to valuation to posting — and treasury accounting stops being a black box between the front office and the close. It becomes what it should be: a set of rules you can read, in the order the system reads them. It is also the chain that decides what anything automated leaves behind — write around it and the row looks right while every control that makes a posting defensible never fired, which is the first thing to check about [an AI agent posting in SAP](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts).

***

_See also [SAP TRM position management & valuation](https://gravam.com/blog/sap-trm-position-management-and-valuation) and [hedge accounting explained](https://gravam.com/blog/hedge-accounting-explained)._

## Primary sources

SAP S/4HANA — Transaction Manager, valuation areas and account-determination apps/customizing differ by release and between on-premise and Cloud; verify against the documentation for your system.

- SAP Help — Treasury and Risk Management (SAP S/4HANA) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/3b3e7e53c4d1cc26e10000000a4450e5.html
- SAP Help — Treasury Accounting (SAP S/4HANA Cloud) — accessed 2026-07-28 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/bc153a383f0d4c39a34a26523af97751.html

## Questions this article answers

**Q: How does account determination work in SAP Transaction Manager?**

Postings are made to account symbols — abstract placeholders like position, interest revenue, accrual or bank clearing — and each symbol resolves to a real G/L account depending on the account assignment reference. The account assignment reference is derived for a treasury position (via substitution rules) when the position is created, and it groups positions that should post to the same accounts. So the chain is: business event → account symbol → account assignment reference → G/L account. If derivation fails and no reference is found, you can maintain it manually on the position indicator — but only while no posting has yet been made for that position.

**Q: What are valuation areas in SAP TRM used for?**

Valuation areas let you value and post the same financial instruments in parallel under different accounting principles — for example local GAAP and IFRS — at the same time. Each valuation area carries its own valuation rules and posts its results separately, so one deal produces parallel sets of valuation and accounting entries without being entered twice. This is how TRM supports parallel accounting: the deal and position are shared; the valuation and its postings are per valuation area.

**Q: How does SAP TRM reconcile to the general ledger?**

Transaction Manager transfers the accounting-relevant results of the deal lifecycle — postings for positions, payments, accruals/deferrals and valuation — into Financial Accounting through account determination, so the subledger view (the deals and positions) and the G/L view are two representations of the same events. Reconciliation is proving they still agree: that every accounting-relevant flow and valuation posted, posted once, and posted to the intended accounts. Breaks usually trace to a missing or wrong account assignment reference, an unposted flow, or a valuation-area configuration gap — not to the ledger itself.

---

# FQM_FLOW Reconciliation & Troubleshooting in S/4HANA

Source: https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
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.

---

# SAP TRM Position Management and Valuation

Source: https://gravam.com/blog/sap-trm-position-management-and-valuation
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: How SAP TRM turns captured deals into managed positions and values them under parallel accounting bases, posting the results to Financial Accounting.

**SAP TRM position management and valuation is the layer that turns captured deals into managed positions and values them — under one or several accounting bases at once — before posting the results into Financial Accounting.** The [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) gets the deal in; this is what happens next, and it's where the numbers that matter to the close are actually made. Here's the earned version: deal capture demos beautifully, but positions and their valuation are where the project's real weight sits. As I put it in the [foundations piece](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), TRM projects live and die in the Transaction Manager and the accounting behind it — and _the accounting behind it_ is precisely this.

## From deals to positions

A deal is an event. A position is a running holding — the aggregate the system builds and maintains from all the deal events that touch a given instrument or exposure over time. When a dealer strikes an FX forward or buys a bond, that single deal is captured in the Transaction Manager; but the thing TRM then values and accounts for isn't the raw deal record, it's the _position_ those deals roll up into.

This distinction sounds academic until go-live, and then it's the whole game. Valuation doesn't price your deals one by one in isolation — it works on positions. Foreign-currency revaluation acts on the position's currency exposure. NPV valuation prices the position's future flows. The position is the unit of account, and it's the genuine bridge between a captured deal and its eventual line in the [general ledger](https://gravam.com/blog/what-is-sap-treasury-and-risk-management). Get the position logic wrong and every downstream number inherits the error — quietly, and usually not until a reconciliation two months later.

## Valuation areas: the same position, more than one truth

Here's the concept that separates people who've done TRM from people who've read about it: **valuation areas**. A valuation area is the frame through which a position is valued under a particular accounting basis. The reason it exists is that one instrument routinely has to be reported _differently for different purposes at the same time_. A hedging derivative might be measured one way for your local statutory books and another for [IFRS](https://gravam.com/blog/hedge-management-in-sap); an operational view and an IFRS view of the identical position can, and often must, diverge.

TRM handles this with **parallel valuation areas** — the same underlying position, valued simultaneously under different rule sets, producing different figures for different sets of books. This is not a niche feature you can defer. Most serious treasuries need at least two parallel valuations, and the moment you have two, you have twice the valuation rules to configure, twice the postings to design, and twice the "why don't these two numbers agree?" conversations. They're _supposed_ to disagree — that's the entire point of parallel valuation — but explaining that convincingly, to auditors and to your own accountants, is real work.

> Parallel valuation areas aren't a feature you switch on. They're a second full set of accounting rules the same position has to satisfy at once — and reconciling two views that are meant to differ is most of the job.

## Key-date valuation: where the gains and losses are born

Positions don't just sit there. At period-end you run **key-date valuation** — the revaluation that produces the gains and losses the close has to recognise. Conceptually it's a few related things happening against your positions as at the valuation date:

- **NPV valuation** — discounting the position's future cash flows [on the relevant curves](https://gravam.com/blog/sap-treasury-market-data-management) to a net present value, so financial instruments are carried at a current fair measure rather than yesterday's number.
- **Foreign-currency valuation** — revaluing foreign-currency positions at current rates, producing the FX gains and losses that fall out of holding exposure across a period.
- **Amortisation** — where relevant, spreading premiums, discounts or similar over the life of the instrument rather than taking them in one hit.

Each of these runs _per valuation area_. That's the multiplier again: an NPV valuation and an FX revaluation aren't single runs, they're single runs _times your number of parallel accounting bases_, each with its own rules about what gets recognised and how. The output is a set of valuation results — unrealised gains and losses, revaluation adjustments — waiting to be posted. This is closely related to how the [Market Risk Analyzer](https://gravam.com/blog/sap-market-risk-analyzer) measures value and market risk; valuation for accounting and valuation for risk measurement draw on the same underlying pricing, which is elegant right up until the two need to reconcile.

## Posting to FI: the point of the whole exercise

All of it — the position results, the key-date valuation gains and losses — posts to **Financial Accounting** as accounting documents. This integration isn't a downstream detail bolted on at the end; it _is_ the reason TRM lives inside SAP rather than beside it. And it is, without much competition, where a TRM implementation actually spends its time and its arguments.

I've watched more project weeks disappear here than anywhere else. The question that eats them is always some version of **"why did it post _that_?"** — why this account, why this amount, why in this valuation area and not the other, why a gain here and a loss there. Every product type, every position event, every valuation area needs its posting behaviour designed, configured and tested, and the people who own the answer — treasury and accounting — often don't agree until they're in a room together looking at the same posted document. Deal capture is a demo; the posting logic is the project.

## Why parallel valuation takes longest

The documentation describes valuation areas and key-date valuation in a handful of confident, tidy sentences. What those sentences don't convey is that **parallel valuation and the posting logic behind it are the hardest and most under-estimated part of a TRM build.** Not the deal entry — that's visible and quick. The under-estimated work is: getting two or more valuation areas to each value the same position correctly, produce the right gains and losses, and post them to the right accounts in a way that reconciles and that an auditor will accept.

If you take one thing into planning, take this: budget for the postings and the parallel valuation as the bulk of the effort, not the tail of it. Treat the position-to-FI path as the core of the project, get treasury and accounting arguing about postings in month one rather than in [UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems), and the valuation layer stops ambushing you. It's a precise, powerful engine — it just asks you to respect that turning a position into the right number in two sets of books is where the real work has always been.

***

_See also [the SAP Transaction Manager](https://gravam.com/blog/sap-transaction-manager) [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), and [SAP Portfolio Analyzer](https://gravam.com/blog/sap-portfolio-analyzer), which reads these positions for returns and benchmarks._

## Primary sources

SAP S/4HANA — verify against your release and edition; behaviour and available apps/tools differ across releases and between on-premise and Cloud.

- SAP Help — Run Valuation (Treasury and Risk Management position valuation), SAP S/4HANA — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/094cee52f0720175e10000000a44538d.html

## Questions this article answers

**Q: What is position management in SAP TRM?**

Position management is the layer of SAP TRM that aggregates individual deals from the Transaction Manager into managed positions — the running holding in an instrument or exposure that the system tracks, values and accounts for over time. A single position is built from many deal events (the original trade, later flows, adjustments), and it's the position, not the raw deal, that valuation and accounting actually work on. It's the bridge between a captured deal and its numbers in the general ledger.

**Q: What is a valuation area in SAP TRM?**

A valuation area is the mechanism SAP TRM uses to value the same position under a particular accounting basis. Because one instrument frequently has to be reported differently for different purposes — a local or operational view and an IFRS view, for example — TRM supports parallel valuation areas that each apply their own valuation rules to the same underlying position at the same time. This is how a single deal produces the different figures that different sets of books require.

**Q: How does SAP TRM post valuations to accounting?**

Key-date valuation revalues positions at period-end — net present value of financial instruments, foreign-currency revaluation and, where relevant, amortisation — and the resulting gains and losses, together with the position results, post to Financial Accounting as accounting documents. This integration with FI is the point of the whole exercise, and it's where most of a TRM implementation's design, testing and cross-team argument actually happens.

---

# Market Data in SAP Treasury: Rates, Curves and Prices

Source: https://gravam.com/blog/sap-treasury-market-data-management
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: SAP treasury market data — FX rates, interest curves, security prices, indexes — is the reference TRM values everything on; its quality drives every number.

**Market data is the external reference SAP TRM values everything on — FX rates, reference interest rates and yield curves, security prices, and indexes — and every valuation and risk number the system produces is only as good as the data feeding it.** That's the honest one-line version. Here's what the documentation never says out loud: market data is treated as plumbing, quietly essential and badly under-owned, right up until a period-end valuation comes out wrong and everyone discovers a rate that never loaded. The [Market Risk Analyzer](https://gravam.com/blog/sap-market-risk-analyzer) gets the attention because it produces the numbers. This is the article about what those numbers are made of.

## What market data actually is here

In TRM, "market data" means the external, market-observed reference values that a valuation applies to a position. It isn't your deals and it isn't your positions — those come from the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager). It's the other half of the calculation: the prices and rates from _outside_ the company that turn a contract into a value. In practice that's four families of data:

- **FX / exchange rates** — the rate at which one currency converts to another, used everywhere from translating a foreign-currency position to valuing an FX deal.
- **Reference interest rates and yield curves** — the reference rates, and the curves built from them, that discounting and interest calculations run on.
- **Security prices** — the market prices of the securities a treasury holds.
- **Indexes** — the reference indexes that certain instruments and calculations point at.

None of this is exotic. It's the standard external reference data any treasury system consumes. What's easy to underestimate is how _much_ of TRM's output is really just this data, applied.

## How it gets in

Two routes, and most implementations use both.

For small volumes, market data can be **entered manually** — a few exchange rates keyed in to close a period, a price captured by hand. That's fine at low scale and dangerous as a habit, because manual entry is exactly where a typo becomes a valuation.

For anything real, market data comes through a **market-data / datafeed interface** that imports rates, curves and prices automatically from an external provider. Automation isn't just about volume; it's about consistency and timing — the same rates, on the same schedule, without a human deciding which ones to type today.

Underneath both routes sits the concept of the **rate type**: SAP lets the same currency pair or reference rate be held under different rate types for different purposes, so you can distinguish, say, a rate used for one calculation from the one designated as the **official** rate used for valuation. That distinction is not bureaucracy. It's how you make sure the number that hits the accounts is the number you _chose_ for that job, not whichever one happened to be lying around.

## The right rate, at the right time

Here's the whole discipline in one sentence: valuation and risk inherit whatever rate they're handed, and they never argue.

> The same instrument, valued on the wrong rate or the wrong date, gives a wrong number that looks exactly as confident as the right one — and it flows straight to the accounts and the risk figures without ever raising an error.

That's what makes market data unforgiving. A position valued on yesterday's curve, or on a rate under the wrong rate type, or on a date that's off by one, doesn't fail loudly. It produces a precise, plausible, wrong result. The [valuation run](https://gravam.com/blog/sap-trm-position-management-and-valuation) doesn't know the rate was stale — it only knows what it was given. Getting the _right rate, under the right type, on the right date_ is not a nicety layered on top of valuation; it _is_ the valuation, half of it, and it's the half nobody watches.

## Governance and control

Because the data is so consequential and so quiet, it needs governance that matches:

- **One authoritative source.** When two feeds or two rate types can each answer "what's the rate," calculations stop reconciling and nobody can say which number is _the_ number. Decide the source of truth and make everything defer to it.
- **Controlled updates.** Who can change a rate, when, and on what schedule — market data changed casually is market data you can't trust at close.
- **Completeness.** This is the one that bites. A missing yield-curve point, a price that didn't come through, a rate that never loaded — none of these throw an error. They just quietly corrupt whatever they touch. Completeness has to be _checked_, not assumed, because the system won't volunteer the gap.

## Where it feeds

Everything downstream drinks from this well. The **Analyzers** — [market risk](https://gravam.com/blog/sap-market-risk-analyzer), credit risk and portfolio — all compute on market data. Position **valuation** discounts and marks against these curves and prices. Risk measures, sensitivities and scenarios are all just this data, moved and re-applied. So the reach of a single bad rate is enormous: it isn't one wrong figure, it's every calculation that touched that figure, all wrong the same way.

## The part the docs leave out

The documentation describes market data cleanly — enter it or import it, assign the rate types, run the valuation. What it doesn't tell you is the organisational truth: **market data is under-owned.** It sits between the treasury team who assume "the system has the rates" and IT who assume "the business checks them," and in that gap a feed quietly stops one day and nobody notices until the numbers are already wrong. On more than one project the fix wasn't technical at all — it was giving the data an owner, a checklist, and a completeness check before the valuation run, not after.

Market data is the least glamorous thing in [SAP Treasury](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) and one of the most decisive. Treat it as plumbing and it will behave like plumbing — invisible until it floods. Treat it as the input product that every valuation and risk number is built from, give it one source, control its updates, and check it's complete, and everything downstream gets to be right for the right reason. The vendor-neutral version of these decisions — sourcing, validation at the door, and what "the official rate" has to mean — is [market data in treasury systems](https://gravam.com/blog/market-data-in-treasury-systems).

***

_See also [the SAP Market Risk Analyzer](https://gravam.com/blog/sap-market-risk-analyzer) and [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management)._

## Primary sources

SAP S/4HANA — verify against your release and edition; behaviour and available apps/tools differ across releases and between on-premise and Cloud.

- SAP Help — Data Management in Treasury and Risk Management (market data), SAP S/4HANA — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/4c075fdaeaaa488fae5e59d4690b250b.html

## Questions this article answers

**Q: What market data does SAP Treasury need?**

SAP Treasury and Risk Management needs the external reference data its valuation and risk calculations depend on: foreign-exchange (exchange) rates, reference interest rates and the yield curves built from them, security prices, and indexes. This is the market side of every calculation — the deals and positions come from the Transaction Manager, but the values they carry come from applying this market data to them. Without a complete, current set of rates and curves, valuation has nothing to compute against.

**Q: How is market data loaded into SAP TRM?**

Small volumes can be entered manually — a handful of exchange rates keyed in for a period-end, for example. For anything at scale, market data is imported through a market-data or datafeed interface that loads rates, curves and prices from an external provider automatically. SAP organises rates by rate type, so the same currency pair or reference rate can be held under different types for different purposes, and an official rate can be designated for valuation. The goal either way is the right rate, under the right type, on the right date.

**Q: Why does market data quality matter?**

Because valuation and risk inherit whatever data they are given. The same instrument valued on a wrong rate, a stale price, or the wrong date produces a wrong value — and that wrong number flows straight into the accounts and the risk figures without raising an error, because a wrong valuation still looks like a valuation. A missing yield-curve point or a rate that never loaded corrupts the result silently. That is why market data needs one authoritative source, controlled updates, and completeness checks rather than trust.

---

# SAP Bank Account Management (BAM) in S/4HANA

Source: https://gravam.com/blog/sap-bank-account-management-s4hana
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-10-04
Reviewed: 2026-10-04
Summary: SAP Bank Account Management (BAM) in S/4HANA: house banks and house bank accounts, the Fiori apps, approval modes and what changed from ECC — verified.

**SAP Bank Account Management (BAM) is the part of S/4HANA Cash Management that holds your company's bank accounts as master data — account number, IBAN, the link to the house bank account, payment approvers, overdraft limits — and controls how those accounts are opened, changed, closed and reviewed. A basic version is delivered with S/4HANA; approval workflows, the bank hierarchy view, payment approvers and account reviews need the separately licensed SAP S/4HANA Finance for cash management.** That reads like an administrative footnote. Here's what the projects teach instead: BAM looks like housekeeping and behaves like plumbing. It's the quiet layer under [S/4HANA Cash Management](https://gravam.com/blog/sap-cash-management-s4hana), and when a bank account estate is a mess, that mess doesn't stay in BAM — it surfaces as broken cash visibility and reconciliation two modules downstream, where nobody thinks to blame the account master.

Everything SAP-specific below was checked against SAP Help (S/4HANA 2025, on-premise and private edition), the SAP Fiori apps reference library and, for the history, SAP's Simplification List for S/4HANA 2023; what I couldn't verify is listed near the end.

## What BAM is, and the two scopes it comes in

One naming note first: SAP's current on-premise documentation files this capability under **Bank Relationship Management**, while the application component is still FIN-FSCM-CLM-BAM (Bank Account Management) and every project room still says BAM.

SAP documents two scopes, and the difference decides what you can promise treasury:

| Capability | Basic cash management capability | SAP S/4HANA Finance for cash management |
| --- | --- | --- |
| Manage banks and house banks | Yes — a subset of fields | Yes |
| Define bank accounts and house bank accounts | Yes — common attributes only | Yes |
| List view of bank accounts | Yes | Yes |
| Import, export and replicate bank accounts | Yes | Yes |
| Bank hierarchy view and user-defined hierarchies | No | Yes |
| Payment approvers and overdraft limits on the account | No | Yes |
| Workflow, dual control or two-person verification | No | Yes |
| Bank account reviews | No | Yes |

The basic capability is, in SAP's words, "delivered with SAP S/4HANA": you select **Basic Scope** in the Customizing activity _Define Basic Settings_. The full scope needs the business function **FIN_FSCM_CLM** switched on, **Full Scope** selected in the same activity, and a licence — SAP tells you to contact your account executive first. Don't switch it on speculatively: SAP warns that the activation cannot be reversed in a live system.

In the field the basic version is usually called "BAM Lite", and the name is SAP's own: its Simplification List for S/4HANA defines "Bank Account Management Lite (BAM Lite)" as a basic version of Bank Account Management that is part of the basic cash management capability, for customers without the SAP S/4HANA Finance for cash management licence. The current SAP Help pages don't use it; there the terms are the _basic cash management capability_ and, as scope items, Basic (BFA) and Advanced (J77) Bank Account Management.

## House banks and house bank accounts in S/4HANA

**A house bank is the entity you create in SAP to represent a bank your company has a contract with; a house bank account is one of your company's own accounts at that bank.** Both are, in SAP's words, "required for payment transactions and accounting". Four objects are involved, and keeping them apart solves most of the confusion:

> **Figure — Bank, house bank, house bank account and bank account in SAP**
>
> Four objects in a chain. A bank, held in table BNKA, leads to a house bank, T012, which leads to a house bank account, T012K. The house bank account is joined by a chain link to the bank account — the Bank Account Management master record, FCLM_BAM_AMD.
>
> Four objects, one chain. The link between the last two is what SAP calls house bank account connectivity.

| Object | What it is | Maintained in |
| --- | --- | --- |
| Bank | The bank itself — name, SWIFT/BIC, address | Manage Banks - Master Data, or transaction FI01 |
| House bank | Your relationship with that bank, identified by company code + house bank ID | Manage Banks - Cash Management, or transaction FI12_HBANK |
| House bank account | Your account there as payments and postings see it; an ID of up to 5 characters | Manage Bank Accounts, House Bank Account Connectivity tab |
| Bank account | The BAM master record — IBAN, holder, approvers, limits, lifecycle status | Manage Bank Accounts |

A company code can have several house banks, and one bank can carry several. The S/4HANA-specific part is the last two rows: each house bank account is linked to a bank account master record through **house bank account connectivity**. On the bank account you create a connectivity entry with the ID category _Central System: House Bank Account_, enter the company code, house bank ID and house bank account ID, and assign the G/L account that payment transactions post to. By default SAP allows one such central house bank account per bank account (the check is a configurable message), so that it "can uniquely represent the bank account in payment transactions and postings". Other ID categories link the bank account to a G/L account or to account records in remote SAP or third-party systems.

One thing the app doesn't do for you: after creating or changing a house bank account, SAP tells you to update the Customizing activity _Set Up Bank Determination for Payment Transactions_.

On the SAP GUI side the documentation looks inconsistent: the overview page names only Manage Bank Accounts and SAP NetWeaver Business Client (NWBC) for house bank accounts, while the _Defining House Bank Accounts_ page adds that "alternatively, you can create house bank accounts using transaction FI12". SAP's Simplification List explains the history. Before S/4HANA 1809 "the transaction FI12 House Bank / House Bank Account is not available" and the Fiori apps replace it; with 1809 "the transaction FI12 has been reactivated" for house banks and house bank accounts. For bank accounts there is a condition: FI12 can be used when the bank account activation mode is _Activate Directly_, and with workflow or dual control in place SAP points you to Manage Bank Accounts or NWBC instead. So FI12 exists again, but the app is the path that works in every control mode.

### The tables behind them

- **T012** — house banks. SAP's S/4HANA migration object for house banks selects "all house banks from the T012 table".
- **T012K** — house bank accounts; the bank account migration object selects from it. In S/4HANA, per the Simplification List, the table "is redirected to the new BAM tables".
- **BNKA** — the bank master, keyed by bank country and bank key. SAP's migration object for banks "automatically selects all bank keys from the BNKA table in the source system".
- **FCLM_BAM_AMD** — the bank account master data table. SAP documents appending the structure CI_AMD_EXT to it for custom fields.
- **FCLM_BAM_ACLINK2** — named in SAP's change-document settings for bank account replication, with fields such as HKTID and HKONT. SAP gives no one-line definition of it, but its 2020 release note places the control key "defined with house bank accounts" in FCLM_BAM_ACLINK2-BKONT, which, with those field names, is consistent with it being the link between a bank account and its house bank account. That reading is mine.

SAP is also consolidating fields inside the BAM tables: as of S/4HANA 2020, FCLM_BAM_ACLINK2-BKONT is deprecated and FCLM_BAM_AMD-CONTROL_KEY is the single source of bank control keys. Control keys defined on house bank accounts "are no longer visible", and transaction FCLM_BKONT_MIGRATION consolidates them onto the bank accounts. The wider table map, including the bank master, is in the [SAP Treasury tables reference](https://gravam.com/blog/sap-treasury-tables).

## From configuration to master data: what changes from ECC

The single most important thing to understand about BAM is a shift most migration teams underestimate. In classic SAP ERP/ECC, house banks and their accounts were **configuration** — created in the implementation guide under _Financial Accounting → Bank Accounting → Bank Accounts → Define House Banks_, in my experience transported through the landscape like any other setting, owned by the same people who owned the rest of the config. In S/4HANA, bank accounts are **master data**, managed centrally in Bank Account Management and maintained by business users. SAP's Simplification List says it in one line: house banks and house bank accounts are no longer "configuration data, instead they are maintained as master data".

That sounds like a technical detail. It isn't. It changes _who owns the account_, _where it's edited_, and _how it changes_. Three consequences SAP documents:

- **The migration is mandatory.** SAP's configuration guide says you "must migrate your house bank accounts before using the basic capability of cash management" — so this applies even if you never license the full scope. There are two programs: the classic report (transaction FCLM_BAM_MIGRATION) and the automatic route through _Start and Monitor Data Migration_, which is the default.
- **Bank accounts don't travel by transport.** SAP's best-practice content for S/4HANA Cloud Public Edition puts it flatly: "Since bank accounts are not transportable to the production system, they must be maintained manually there." What SAP provides instead is _Import and Export Bank Accounts_ — an XML spreadsheet template with a test-run option — and replication of house banks, house bank accounts and bank accounts between systems through transaction DRFOUT.
- **Not everything migrates.** SAP's direct-transfer migration object for bank accounts lists overdraft limits and signatories as out of scope.

Teams that treat the S/4HANA move as a straight technical upgrade discover this in testing — the same way they discover Cash Management is a redesign, not an upgrade. The house bank and account concepts survive the crossing; the ownership model does not. The rest of that crossing is in [migrating SAP Treasury from ECC to S/4HANA](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana).

## The apps, with their Fiori IDs

The working surface is the standard **Manage Bank Accounts** Fiori app (F1366A in [the Fiori apps reference](https://gravam.com/blog/sap-treasury-fiori-apps)). The IDs below are from the SAP Fiori apps reference library; the names are as SAP Help spells them.

| App | ID | What it's for |
| --- | --- | --- |
| Manage Bank Accounts | F1366A | Create, copy, edit, close, delete bank accounts; house bank account links |
| Manage Bank Accounts - Bank Hierarchy View | F1366 | The same inventory as a bank hierarchy (a Web Dynpro app) |
| Manage Banks - Cash Management | F1574A | House banks, bank business partners and contact persons on an existing bank |
| Manage Banks - Master Data | F6437 | Create and edit the bank itself |
| Review Bank Accounts | F1370A | Reviewers complete review tasks; initiators track them |
| My Inbox - For Bank Accounts | F2797 | Approve or reject workflow change requests |
| Approve Bank Account Changes - Two-Person Verification | F6264 | Approve or reject changes in two-person verification mode |
| Maintain Payment Approver | F1372 | Replace, add or revoke a payment approver across many accounts (Web Dynpro) |
| Submit / Approve Bank Account Applications | F5861 / F5859 | Request a new account before it exists as a record |

The single **Manage Banks** app (F1574) is the one you'll find on older lists; SAP Help now labels it "Manage Banks (Deprecated)", and its job is split between F1574A and F6437. For the classic transactions around these apps, see the [treasury transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes).

## The bank account lifecycle: open, change, close, review

**A bank account in BAM moves through documented statuses — Inactive (01), Active (02), Marked for Closing (09), Closing Request Sent to Bank (10), Closed at Bank (11) and Closed (15) — and only active accounts can be used in business operations.** The three intermediate closing statuses are optional. When the bank account origination process is enabled, Inactive is not used; the opening side runs through Application Approved (22), Pre-Opening Preparation (24), the optional In Opening Process (26) and Opened at Bank (28) instead. One more status sits outside the main path: Withdrawn (99), for an account that was created from a bank account application which was then withdrawn.

**Opening.** Either create the account directly in Manage Bank Accounts, or have someone submit a bank account application; once that is approved, SAP creates an inactive bank account to be completed in Manage Bank Accounts.

**Changing, with approval.** In the full scope, SAP offers three _bank account control modes_, and they are less alike than the names suggest:

| Mode | Where the approver acts | Can reject? | Approval steps |
| --- | --- | --- | --- |
| Dual control | Manage Bank Accounts — the Activate button | No | One step only |
| Two-person verification | Approve Bank Account Changes - Two-Person Verification | Yes | One step only |
| Workflow | My Inbox - For Bank Accounts | Yes | Configurable in Manage Workflows - For Bank Accounts (F2796) |

All three cover the same six scenarios: opening an account, copying one to create a new one, modifying, closing and reopening it, and changing a payment approver across several accounts. For the workflow mode SAP predefines the Business Object Repository object FCLM_CR and a default workflow scenario, 78500050, which you copy in Manage Workflows - For Bank Accounts to build your own. In dual control a revision nobody activates simply stays inactive, and the account isn't blocked while it waits; in the other two modes it is locked while a change is pending. In dual control and two-person verification, any user authorised to activate bank accounts (authorisation object F_CLM_BAM, activity 63) other than the submitter can approve. In every mode, only changes to fields marked sensitive in _Define Settings for Bank Account Master Data_ trigger the process. The general mode is set in _Define Basic Settings_; _Define Settings for Bank Account Contract Types_ can override it per company code, account type and contract type, which SAP does not support for dual control. One trap: dual control and two-person verification are not supported with NWBC as the user interface.

> BAM's real product isn't the account record. It's the answer to "which accounts do we have, and who can act on them?" — a question most companies can't answer cleanly until something forces them to.

**Signatories.** SAP's current term is **payment approvers**; the older word, signatories, survives in the import template and the migration object. They are held on the bank account and feed the [payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow) for payments made through it. That makes BAM the system record of who can act on what — the kind of thing that lives in a spreadsheet at most companies until an auditor or a fraud scare makes it everyone's problem. They are a full-scope feature, so confirm which scope you have _before_ you promise treasury a full approval workflow.

**Closing.** Only an active account can be closed. You mark it for closing, record that the request has gone to the bank, and confirm once the bank has closed it. Depending on settings, SAP generates a closing request letter and emails it to the bank account contact person. A closed account can be reopened.

**Reviewing.** A review initiator selects active accounts in Manage Bank Accounts and chooses _Initiate Review Process_; reviewers — users with activity 31 on F_CLM_BAM — are notified, check each account in Review Bank Accounts, correct what's wrong and mark it complete. The due date on a review request is, per SAP, for information only; the review notes land in the account's history. It's the natural system anchor for a [bank account rationalisation](https://gravam.com/blog/bank-account-rationalization) exercise.

## Why BAM is the foundation, not a footnote

Here's where the plumbing metaphor earns its keep. BAM sits under three things treasury cares about every single day:

- The **cash position** reads balances against these accounts.
- **Bank statement import** — [electronic bank statement processing](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) — has to match incoming statements to the right account before a single line reconciles.
- **Outgoing payments** and bank connectivity run through the same account definitions, feeding [Bank Communication Management (BCM)](https://gravam.com/blog/bank-communication-management-bcm-sap).

If the account master is wrong — a duplicated account, a stale connectivity link, a closed account still marked open — the failure shows up downstream, in the statement that won't auto-match or the position that doesn't tie out. Engineers spend a day chasing the reconciliation before someone thinks to check the account record. I've watched exactly that day get burned more than once.

## BAM and eBAM — related, not the same

One naming collision worth clearing up, because it confuses people in workshops. **eBAM ([electronic bank account management](https://gravam.com/blog/electronic-bank-account-management-ebam))** is the external, bank-facing standard for opening, closing and maintaining accounts _with the bank itself_ — the messages that flow between a corporate and its banks to actually provision an account. SAP's **BAM** is the internal, in-system master data record and its governance. They're complementary: eBAM is the conversation with the bank; BAM is your own governed inventory. A mature setup uses BAM as the internal book of record and connects it to the eBAM process so opening or closing an account is one governed flow rather than two disconnected ones. Confusing the two — or assuming BAM does the bank-side messaging on its own — is a common early-design mistake.

What SAP documents on the bank-facing side depends on the edition. For S/4HANA 2025 (on-premise and private edition), the _Bank Correspondence_ page describes generated letters — an email with a PDF attachment, sent to a defined contact person — for three scenarios: opening an account, closing it, and updating payment approvers. For S/4HANA Cloud Public Edition (2608), SAP does document eBAM messages in the ISO 20022 format — an account opening request (acmt.007), a request acknowledgement (acmt.010) and an account report (acmt.014), routed through SAP Multi-Bank Connectivity — but for opening _in-house_ bank accounts, where the other side is SAP's own In-House Banking, not an external bank. I found no SAP Help page that documents BAM exchanging acmt messages with an external bank.

## What I couldn't verify

- **eBAM messages with an external bank.** SAP documents them for in-house bank accounts in the Cloud Public Edition; I found nothing for external banks, in either edition.
- **The FI12 conditions on the 2025 release.** SAP Help for 2025 still names FI12; the activation-mode condition is from the Simplification List for S/4HANA 2023, and I found no 2025 edition of that list.
- **Transports in ECC.** SAP confirms house banks were configuration data; that they moved by transport is my experience, not a sentence I found.
- **A separate Fiori ID for Manage Bank Accounts (Basic Cash Management).** SAP Help gives it its own topic; I found no distinct ID in the library.
- **SAP S/4HANA Cloud Public Edition.** Its app set differs in places — the library lists a separate Manage Bank Account Reviews app (F7510) there — and this page isn't verified line by line against that edition.

## The docs-vs-reality summary

The documentation frames Bank Account Management as administration: maintain your accounts, keep your signatories current, done. What a real project discovers is that a messy bank-account estate is the _origin point_ of cash-visibility and reconciliation problems, not a side effect of them. Get BAM clean and governed and the cash position, the statement matching and the payment runs all have solid ground to stand on. Leave it as an afterthought and you'll pay for it every close — in the least visible, hardest-to-diagnose way SAP has to offer. BAM is boring right up until it's the reason nothing reconciles.

***

_See also [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana) and [electronic bank statement processing in SAP](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms)._

## Primary sources

Verified against the SAP S/4HANA 2025 FPS01 documentation (on-premise and private edition) and the SAP Fiori apps reference library; the FI12 history and the BAM Lite definition are from the Simplification List for SAP S/4HANA 2023. Workflow, dual control, two-person verification, the bank hierarchy view, payment approvers and bank account reviews require the full scope (SAP S/4HANA Finance for cash management); the basic scope supports common attributes only. SAP S/4HANA Cloud Public Edition uses partly different apps — verify against your release and edition.

- SAP Help — Business Function: Cash and Liquidity Management (basic scope vs SAP S/4HANA Finance for cash management) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c7999f525c5b224fe10000000a445394.html
- SAP Help — Bank Relationship Management (SAP S/4HANA) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/59d5a052c3ad224fe10000000a445394.html
- SAP Help — Defining Banks, House Banks, Bank Accounts, House Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/3e21f0812797487ba9448539f5afa16d.html
- SAP Help — House Banks (definition) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/79d6056a4a914f868a39e6b737412c24.html
- SAP Help — Defining House Banks (Manage Banks app, FI12_HBANK) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/4460d353c6244308e10000000a174cb4.html
- SAP Help — Defining House Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/579e2d551c03bc06e10000000a441470.html
- SAP Help — Defining House Bank Account Connectivity — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/2abbcf54a14a713be10000000a44176d.html
- SAP Help — House Bank Accounts (configuration settings and connectivity validation) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/a008b2ab60cd4527a45590ff2f22b30a.html
- SAP Help — Defining Bank Accounts (bank account master data attributes) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/f5abb752bf730226e10000000a4450e5.html
- SAP Help — Manage Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/fd6073c2b5db4e8fa19e4efce7629a96.html
- SAP Help — Manage Bank Accounts (Basic Cash Management) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/42b3897f60a2455eaa260bc980bc26b8.html
- SAP Help — Manage Banks - Cash Management (F1574A, feature comparison with Manage Banks - Master Data) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/a4e4d58b503d4ab69f63d7ec92f3b1f9.html
- SAP Help — Manage Banks - Master Data — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/ff4393b5dd1b4c1cbd665ad6b40e91e8.html
- SAP Help — Bank Account Statuses — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c0a95feb9940461a8c2d67f0cb18141d.html
- SAP Help — Opening Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/dda231607f84473799cc73861d069a5e.html
- SAP Help — Closing Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/5180a55e148d4d21b2f4837f5a25c4f8.html
- SAP Help — Approval Processes for Bank Account Management (control modes and their Customizing) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/9bca6156bcb6d154e10000000a441470.html
- SAP Help — Using Approval Processes for Bank Account Management (feature comparison of control modes) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/59adb752bf730226e10000000a4450e5.html
- SAP Help — Using SAP Business Workflow for Bank Account Management — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/dcb2b752bf730226e10000000a4450e5.html
- SAP Help — Using Dual Control for Bank Account Management — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/ce3dba6c727849858fe7e0bc7e6e9480.html
- SAP Help — Using Two-Person Verification for Bank Account Management — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/b627d3af718d46868bf5d2415702b250.html
- SAP Help — Predefined Workflows (BOR object FCLM_CR, scenario 78500050) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/33b96156bcb6d354e10000000a441470.html
- SAP Help — Defining Your Own Workflows (copying the predefined workflow) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/ff3ba9196a844519911cc503928ef1b9.html
- SAP Help — Bank Correspondence (letters for opening, closing and payment approver updates) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/343459a9bd82412a92eb1628554721f3.html
- SAP Help — Reviewing Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/1f0e6c4cbd334dfa96f28c852521bc3b.html
- SAP Help — Review Bank Accounts (app) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/923271e283d2477bb507bda760f1b3ee.html
- SAP Help — Maintain Payment Approver — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/b0438a541e2b0265e10000000a44538d.html
- SAP Help — Import and Export Bank Accounts — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/91b15956b967c841e10000000a44147b.html
- SAP Help — Create Bank Account Master Data (migration tools) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/593d5a5620b4c641e10000000a44147b.html
- SAP Help — Configuration Guide for the Basic Capability of Cash Management (house bank account migration) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/62bf4ce9764f4b06aed815e824e51216.html
- SAP Help — Replicate House Banks, House Bank Accounts, and Bank Accounts (DRFOUT) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/3729a466853745f49fec13367158a1b9.html
- SAP Help — Enhancing Template and Validation Schema for Custom Fields (FCLM_BAM_AMD) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/4a9ecf54e81e6374e10000000a44538d.html
- SAP Help — FI - House bank (SAP S/4HANA Data Migration, T012) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/ae4c6961faa14462848f11b0ad0c4465.html
- SAP Help — FI - Bank account (SAP S/4HANA Data Migration, T012K) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/4fac9b4a140a40f28233abca147abce1.html
- SAP Help — Bank (SAP S/4HANA Data Migration, direct transfer; BNKA) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/dbbb08efc6ce4d4d911c132e00ff0650.html
- SAP — Simplification List for SAP S/4HANA 2023 (PDF; item S4TWL - Cash Management - Bank Accounts, SAP Note 2870766) — accessed 2026-10-04 — https://help.sap.com/doc/c34b5ef72430484cb4d8895d5edd12af/2023/en-US/SIMPL_OP2023.pdf
- SAP Help — Consolidation of Bank Control Keys (What's New in SAP S/4HANA 2020) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e296651f454c4284ade361292c633d69/b755ddfaf0034b76bab366b3bf4bd15d.html?version=2020.000
- SAP Help — Set Change Document Items for Message Type (Treasury Workstation cash integration setup guide for SAP S/4HANA Cloud Public Edition, 2608; BAMMAST; FCLM_BAM_ACLINK2 fields) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_BEST_PRACTICES/889d382cae91add0048b07b971bed17e/5e223c4410ad46da858bd1cc276de2a8.html?version=2608
- SAP Help — Settings for Payments with Orbian Credits (SAP ERP; IMG path Define House Banks) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_ERP/6211bf1accac4f2e813e7f8e5fc19e99/5889d0531d8b4208e10000000a174cb4.html?version=6.18.latest
- SAP Help — Create Bank Account Request (SAP Best Practices for SAP S/4HANA Cloud Public Edition; bank accounts not transportable) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_CLOUD_BEST_PRACTICES/52c4ec1d733ed97d019b42ac7946063e/4f56e0c313534eb0a74165d997ba926d.html?version=2608
- SAP Help — Opening In-House Bank Accounts via Bank Correspondence (SAP S/4HANA Cloud Public Edition 2608; eBAM messages with In-House Banking) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/186460fdc35a4b64a713da9bb00deb1e/7090a5f40d5f408c8f4b127b33def8e9.html?version=2608.500
- SAP Help — Create via eBAM Integration (Option 2) (SAP Best Practices for SAP S/4HANA Cloud Public Edition 2608; acmt.007, acmt.010, acmt.014) — accessed 2026-10-04 — https://help.sap.com/docs/SAP_S4HANA_CLOUD_BEST_PRACTICES/a71048f32c8e699a170b3aeaf95b318a/f228abaeb5fd4b519cbd0d2576ace6ca.html?version=2608
- SAP Fiori apps reference library (app IDs F1366A, F1366, F1574A, F6437, F1574, F1370A, F2797, F2796, F6264, F1372, F5861, F5859, F7510) — accessed 2026-10-04 — https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/

## Questions this article answers

**Q: What is SAP Bank Account Management (BAM)?**

SAP Bank Account Management (BAM) is the part of S/4HANA Cash Management that holds a company's bank accounts as master data and controls how they are opened, changed, closed and reviewed. Each bank account record carries general data such as account number, IBAN and account holder, the link to its house bank account, and, in the full scope, payment approvers and overdraft limits. Users maintain it in the Manage Bank Accounts Fiori app (F1366A). SAP's current on-premise documentation files the capability under the heading Bank Relationship Management; the application component is still FIN-FSCM-CLM-BAM.

**Q: What is the difference between a house bank and a house bank account in SAP?**

A house bank is the entity you create in SAP to represent a bank your company has a contract with; it is identified by company code plus house bank ID and stored in table T012. A house bank account is one of your company's own accounts at that bank, identified by a house bank account ID of up to five characters and stored in table T012K. In S/4HANA every house bank account is linked to a bank account master record through house bank account connectivity, and the house bank account is what payment transactions and postings reference. House banks are maintained in Manage Banks - Cash Management or transaction FI12_HBANK; house bank accounts in Manage Bank Accounts.

**Q: Is Bank Account Management included in S/4HANA?**

A basic version is. SAP documents a basic cash management capability that is delivered with SAP S/4HANA: you can manage banks and house banks, define bank accounts and house bank accounts with common attributes only, see accounts in a list view, and import, export and replicate them. Workflow, dual control or two-person verification for account changes, the bank hierarchy view, payment approvers, overdraft limits and bank account reviews belong to SAP S/4HANA Finance for cash management, which needs its own licence, the business function FIN_FSCM_CLM and the Full Scope setting in the Define Basic Settings Customizing activity.

**Q: How is BAM different from the old house bank configuration?**

In SAP ERP, house banks and their accounts were created in the implementation guide under Financial Accounting, Bank Accounting, Bank Accounts, Define House Banks, so they were Customizing; SAP's Simplification List says they are no longer configuration data and are maintained as master data instead. In S/4HANA, house bank accounts are migrated into bank account master data, either with transaction FCLM_BAM_MIGRATION or automatically through the Start and Monitor Data Migration activity, and that migration is mandatory even for the basic scope. After it, bank accounts are maintained by business users in the Manage Bank Accounts app. SAP's own best-practice content for S/4HANA Cloud Public Edition states that bank accounts are not transportable to the production system and must be maintained there.

**Q: What is the Manage Bank Accounts app?**

Manage Bank Accounts (Fiori app F1366A) is the standard app for bank account master data in S/4HANA. With it you search, create, copy, edit, close and delete bank accounts, attach documents, create the house bank account on the House Bank Account Connectivity tab, and start a bank account review. In the full scope, changes made in this app to open, copy, modify, close or reopen an account are subject to workflow, dual control or two-person verification. A reduced variant, documented as Manage Bank Accounts (Basic Cash Management), covers customers on the basic scope.

---

# SAP Advanced Payment Management (APM)

Source: https://gravam.com/blog/sap-advanced-payment-management-apm
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-26
Summary: SAP Advanced Payment Management (APM) is the S/4HANA payment hub that centralizes payment requests from many systems and orchestrates them toward the banks.

**SAP Advanced Payment Management (APM) is the payment hub inside S/4HANA — the central layer that receives payment requests from across the landscape and orchestrates them toward the banks, routing, aggregating, transforming and preparing them so that payments travel one controlled path instead of many.** That's the clean version. The version I've earned watching large groups try to get their payments under control is blunter: most companies don't have a payments _system_, they have a payments _sprawl_ — a dozen source systems, each with its own connection to its own banks in its own formats — and APM is SAP's answer to pulling that sprawl onto a single spine. It's one of the newer pieces of the S/4HANA payment story, and it solves a genuinely old problem.

## The problem it exists to solve

Walk into a large group and ask a simple question — _how do payments leave this company?_ — and watch the answer fall apart. Payroll leaves one way. Accounts payable payment runs leave another. Treasury settlements leave a third. A handful of local ERPs and bolt-on systems each have their own quiet path to their own house banks. The formats differ, the approval differs, the monitoring differs, and nobody has a single screen that shows _all payments, everywhere, right now_.

That sprawl isn't just untidy — it's expensive and risky. Every source-to-bank connection is a thing to build, maintain, secure and audit. Every format variant is a place formatting bugs hide. And control is only ever as strong as the weakest of those many paths. The whole argument for a **[payment hub](https://gravam.com/blog/payment-hub-vs-payment-factory)** is to collapse the many paths into one: give payments a single central intake, and handle routing, formatting and monitoring consistently in that one place.

## What APM actually is

APM is that central intake and orchestration layer, delivered as an S/4HANA component. Source systems and processes send their **payment requests** to APM rather than each reaching the banks independently. APM then does the orchestration work: it _routes_ each payment according to rules, _aggregates_ where it makes sense, _transforms_ into the required formats, and _forwards_ the result toward the banks — with visibility over status along the way.

The mental model that helps: APM is a switchboard, not a payment run. It doesn't originate the business need to pay — that still happens in AP, in payroll, in [treasury settlements](https://gravam.com/blog/what-is-sap-treasury-and-risk-management). APM is what everything _hands its payments to_, so the decisions about how a payment is handled, formatted and sent live in one governed place instead of being re-implemented in every source system. I'll be honest about scope: this is a comparatively new component, so I'll keep to what it _is_ and the problem it _solves_, and stay away from the config-level specifics that shift release to release.

> **Figure — SAP Advanced Payment Management as the single path for payments**
>
> Three sources — payroll, accounts payable and treasury — each send their payment requests to APM. APM is drawn as a hub with four steps — route, aggregate, transform and forward — and one arrow leaves it for the banks.
>
> Many sources, one hub, one controlled path to the banks.

## Where APM sits versus BCM

APM and [Bank Communication Management (BCM)](https://gravam.com/blog/bank-communication-management-bcm-sap) are not alternatives but neighbours on the same road: APM prepares and orchestrates the payments, BCM (where used) approves and releases them, and the connectivity channel — [SAP Multi-Bank Connectivity](https://gravam.com/blog/sap-multi-bank-connectivity), host-to-host, API or another connector — transmits the file without transforming it. The full boundary, including why "BCM sends everything" is the wrong picture and how an APM-centric landscape moves where routing and format generation happen, is drawn in [BCM vs APM in the payments architecture](https://gravam.com/blog/sap-bcm-apm-output-management-architecture#boundary-2-bcm-vs-apm).

## APM and the payment factory story

Centralizing payments is the same ambition this site keeps returning to under different names. A [payment factory](https://gravam.com/blog/what-is-a-payment-factory) centralizes external payment _execution_; [In-House Cash](https://gravam.com/blog/sap-in-house-cash-ihc) provides the internal-banking backbone — internal accounts and intercompany balances — that payments-on-behalf-of relies on. APM is the orchestration spine that ties the _processing_ side of that together: the single point where the many payment flows converge before they're prepared and sent.

Think of it as three complementary pieces of one centralization story. IHC handles the internal bank. The payment factory model centralizes execution. APM is how SAP lets you funnel the many originating flows through one orchestration layer on the way out. None of the three replaces the others; together they're how a large group stops running payments as a dozen disconnected pipes.

## The capabilities, kept conceptual

Stripped to essentials, a payment hub like APM offers:

- **Central intake** of payment requests from many source systems and processes.
- **Routing** — rules that decide how and where each payment should go.
- **Aggregation and transformation** — bundling where sensible and producing the [required payment formats](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) for the receiving channel; in SAP terms the format itself is still a [DMEE format tree](https://gravam.com/blog/sap-dmee-payment-file-format-tree) or its APM-native equivalent.
- **Connectivity through the bank channels** — the onward path to the banks, working with BCM and the connectivity layer rather than reinventing it.
- **Status and monitoring** — visibility over payments as they move, so a stuck or rejected payment is _seen_ rather than assumed successful.

One more source of payment requests is arriving: an AI step that drafts or proposes them. A hub's intake and routing rules are exactly where [an agent's authority to pay](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment) gets enforced — or quietly assumed.

## Docs-versus-reality

Here's the part the glossy diagram won't tell you. The value of a payment hub is real — **control and standardization**, one governed path instead of many fragile ones — but that value is not what makes the project hard. The hard part is the _migration_: taking every existing payment process, in every source system, with all its accumulated local quirks, and moving it onto the single path _without breaking anything that's currently paying people and suppliers_.

That's the work. Not the concept — the concept is easy to sell. It's the patient, unglamorous business of onboarding one payment flow at a time, proving each still produces the right file to the right bank with the right approval, and retiring the old direct path only once the new one is trusted. A payment hub half-migrated is worse than no hub at all: now you have the old sprawl _and_ a new central layer, and two places for a payment to go wrong. Plan APM as a migration programme with a hub at the end of it, not as a switch you flip, and it delivers what it promises — every payment in the group on one controlled, standardized, monitored path out to the banks. For how APM divides responsibility with BCM and output management, see the [BCM, APM and output-management boundaries](https://gravam.com/blog/sap-bcm-apm-output-management-architecture).

***

_See also [Bank Communication Management (BCM) in SAP](https://gravam.com/blog/bank-communication-management-bcm-sap) and [SAP In-House Cash (IHC)](https://gravam.com/blog/sap-in-house-cash-ihc)._

## Primary sources

SAP S/4HANA — verify against your edition/release. BCM is the (optional, integrated) approval/release layer; the connectivity/output channel (MBC, host-to-host, API) transmits — this split differs by edition.

- SAP Help — Advanced Payment Management (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/2945c7d799ac46f0bdb0267f9fd7a289.html
- SAP Help — Bank Communication Management (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/95a8510ebc24461f87c65d2eb3c62288.html

## Questions this article answers

**Q: What is SAP Advanced Payment Management (APM)?**

SAP Advanced Payment Management (APM) is a payment-orchestration component in S/4HANA — a payment hub. It receives payment requests centrally from many source systems and processes, then routes, aggregates, transforms and forwards them toward the banks. Instead of each system reaching the banks on its own path and in its own format, payments flow through one controlled central layer that decides how each is handled and prepares it for onward processing. It is a newer part of the S/4HANA payment landscape, aimed at organizations centralizing payment processing across a large group.

**Q: How does APM relate to Bank Communication Management (BCM)?**

APM and BCM sit at different points and are commonly used together, though not universally. APM is the orchestration layer: it takes in payment requests from across the landscape, applies routing and formatting logic, aggregates and prepares them, and decides what should flow where. BCM is an approval and release control — payment-order approval, batch release, digital signatures and payment-status monitoring — and SAP documents it as an integration for APM's outgoing payments. What actually transmits the file is the output/connectivity channel (SAP Multi-Bank Connectivity, host-to-host, API or another connector), not BCM itself. So: APM prepares and orchestrates; BCM (where used) approves and releases; the connectivity channel formats and sends.

**Q: What problem does a payment hub solve?**

In a large group, payments originate in many systems and processes, address many banks, and are produced in many formats — scattered, hard to control, hard to standardize, and hard to see end to end. A payment hub centralizes that: it gives payments a single intake point and one controlled path, so routing, formatting, aggregation and monitoring are handled consistently in one place. The value is control and standardization; the hardest part is migrating all those existing payment processes onto the single path without breaking any of them.

---

# Business Partner Configuration for SAP Treasury

Source: https://gravam.com/blog/business-partner-configuration-sap-treasury
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-26
Reviewed: 2026-08-19
Summary: The SAP Business Partner is the master-data object for the counterparties, issuers and banks a treasury deals with — and every TRM deal is captured against it.

**The SAP Business Partner is the master-data object that represents every party your treasury actually deals with — the banks and trading partners you transact with, the issuers whose securities you hold, and the banks that settle the money — and in TRM every deal is booked _against_ one.** That's the mechanical truth the documentation states in a sentence. Here's the one I've earned: Business Partner setup is the least glamorous job in a treasury implementation, it gets rushed because it demos as boring data entry, and a genuinely surprising share of settlement incidents I've been called in to fix trace straight back to it. The deal capture gets all the attention; the master data behind it is where the money quietly goes wrong.

## What the Business Partner is here

In SAP, the Business Partner (BP) is the single, central master-data object for a party — not a treasury invention but the platform-wide way SAP represents a company, bank or person you have a relationship with. Treasury simply uses it for the parties it cares about:

- **Counterparties** — the banks and trading partners you strike deals with.
- **Issuers** — the parties that issue the [securities](https://gravam.com/blog/sap-transaction-manager) you hold.
- **Depository and paying banks** — the banks through which settlement actually flows.

The key idea, and the one people skate past: a [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) deal is not free-floating. It is captured against a Business Partner. The BP is the anchor that says _who_ this money-market deposit is with, _who_ issued this bond, _where_ this FX forward settles. Get the anchor wrong and everything hanging off it inherits the error.

## Roles: how a party becomes usable in TRM

A Business Partner isn't automatically a treasury counterparty just because it exists. It becomes usable in TRM by taking on the relevant **treasury roles** — the counterparty role for a party you deal with, the issuer role for a party whose securities you hold, and so on. The role is what tells SAP "this BP can play _this_ part in a treasury transaction" and unlocks the treasury-relevant data behind it.

I'll deliberately describe these by function rather than reciting codes, because the function is what matters and the codes are what people misremember: a party can carry several roles at once — a bank can be both a counterparty you deal with _and_ a paying bank that settles — and that's normal. One BP, many hats. What you're configuring is which hats each party is allowed to wear.

## Standing instructions: capture once, reuse everywhere

Here's the part that earns the BP its keep. Attached to a Business Partner is a body of reusable data — **standing instructions** — that defaults into every deal booked against it:

- **Payment details / standing settlement instructions** — which bank account settles which flows, in which currency, by which method. This is the "where the money goes" data.
- **Correspondence** — how deals with this party get confirmed and matched, the control that catches booking errors before they become losses.
- **Derived-flow rules** — the charges, taxes and similar flows SAP generates automatically off a deal.

> Standing instructions are where the capture-once efficiency lives — and they are exactly where the risk lives too. The same field that saves a dealer thirty seconds a deal can misroute every one of them.

That duality is the whole point. Maintain a counterparty's settlement data once and a hundred deals inherit it cleanly — real efficiency, real error reduction. But maintain it _wrong_ once, and a hundred deals inherit _that_. The standing instruction doesn't announce itself at deal capture; the dealer sees a normal-looking deal and the wrong account details are riding along underneath, defaulted in and invisible.

## Why it matters: settlement and exposure

Two distinct failure modes make BP data a first-order concern, not a housekeeping detail.

**Wrong data routes real money wrongly.** Because a deal inherits its settlement and payment data from the BP, a wrong standing settlement instruction means a correct-looking deal pays to the wrong account. This is the failure that keeps people up at night, because nothing on the deal itself looks off — the error is upstream, in the master data, and the payment goes out clean and wrong.

**Duplicate BPs fragment exposure.** Set the same counterparty up twice — a merger, a typo, two teams not talking — and your [counterparty exposure](https://gravam.com/blog/sap-credit-risk-analyzer) splits across both records. Limits sit on the Business Partner, so a duplicated party understates its own true exposure and your credit view lies to you. The [Credit Risk Analyzer](https://gravam.com/blog/sap-credit-risk-analyzer) can only be as good as the BP structure it measures against; give it two records for one bank and it will happily under-count the risk. The same applies when [hedges](https://gravam.com/blog/hedge-management-in-sap) reference a counterparty that's been duplicated — the exposure and the hedge can end up on different records.

## Governance: a changed instruction is a payment vector

Because a standing settlement instruction defaults into real payments, changing one is not a data-maintenance task — it's a payment-control event. A single edit to "which account settles this counterparty's flows" reroutes money on every future deal that uses it, silently. That is precisely the mechanism a payment-fraud attempt targets: change the account on the master data and let the system's own efficiency do the rest.

So BP and standing-instruction changes need real control around them — **four-eyes** on creation and, especially, on changes to payment and settlement data. This isn't bureaucracy bolted on; it's the same [segregation-of-duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) principle that governs the deal lifecycle, applied to the master data the deals depend on. If the person who can change a settlement account is the same person who can book and release a deal, you've built a single point of failure into your payments.

## Why Business Partner setup is not plumbing

The official material treats Business Partner setup as prerequisite plumbing — a box to tick before the interesting configuration starts. In practice it's the opposite of low-stakes. It's unglamorous, so it gets handed to whoever's free; it demos as trivial, so it gets rushed; and it's upstream of every deal, so its errors surface last and hurt most. I've watched more than one go-live spend its first tense week not on the [postings](https://gravam.com/blog/sap-transaction-manager) everyone braced for, but on a settlement incident that unwound to a single wrong field on a single Business Partner.

Treat the BP as what it is — the governed, controlled record of _who you deal with and where the money goes_ — and the deals booked against it behave. Treat it as data entry, and it will teach you otherwise at the worst possible time.

***

_See also [SAP Transaction Manager](https://gravam.com/blog/sap-transaction-manager) and [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management)._

## Primary sources

SAP S/4HANA — verify against your release and edition; behaviour and available apps/tools differ across releases and between on-premise and Cloud.

- SAP Help — Business Partners in Treasury and Risk Management — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/da53e5526913456aa0a4aeb849e4e789.html
- SAP Help — Business Partner Roles in TRM — accessed 2026-07-26 — https://help.sap.com/docs/SAP_ERP/20ef72eda4fa4742a1352be75094cd16/4d47d052c04f468de10000000a42189c.html

## Questions this article answers

**Q: What is the Business Partner in SAP Treasury?**

The Business Partner (BP) is SAP's central master-data object representing the parties a treasury deals with — counterparties such as banks and trading partners, the issuers of securities, and the depository and paying banks used for settlement. In Treasury and Risk Management, a BP becomes usable in a deal only once it carries the relevant treasury roles, such as the counterparty role or the issuer role. Every deal in the Transaction Manager is captured against a Business Partner, so the BP is the anchor that ties a financial transaction to a real, identified party and to the settlement and payment data that transaction will inherit.

**Q: What are standing instructions in SAP Treasury?**

Standing instructions are the reusable data attached to a Business Partner that default into the deals booked against it. They typically cover payment details and standing settlement instructions (which bank account settles which flows), correspondence (how deals are confirmed with the counterparty), and derived-flow rules (charges, taxes and similar flows generated automatically). The point is capture-once, reuse-everywhere: you maintain the counterparty's settlement and payment data on the BP once, and every deal inherits it rather than the dealer keying it each time. That efficiency is also where the risk lives, because a wrong standing instruction defaults into every deal that uses it.

**Q: Why does Business Partner data matter for treasury deals?**

Because a deal inherits its settlement and payment data from the Business Partner it is booked against. If that data is wrong, real money settles to the wrong place — and it does so quietly, because the deal itself looks correct. Duplicate Business Partners cause a second, subtler problem: the same counterparty appears twice, so exposure and limits fragment across both records and the credit view understates the true position. Getting the BP right is therefore a settlement-integrity control and a counterparty-risk control at the same time, which is why BP and standing-instruction changes belong under four-eyes governance.

---

# SAP In-House Cash (IHC) and In-House Banking

Source: https://gravam.com/blog/sap-in-house-cash-ihc
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-03
Reviewed: 2026-09-03
Summary: SAP In-House Cash runs an internal bank — bank areas, IHC payment orders, the IHC_DB_PN tables, the BAdIs, and the newer In-House Banking apps, verified.

**SAP In-House Cash (IHC) is SAP's module for running an internal bank — maintaining internal accounts for group subsidiaries and processing payments between and [on behalf of them](https://gravam.com/blog/sap-advanced-payment-management-apm), so the group banks internally instead of externally.** It's the SAP implementation of the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) concept this site covers generally, and it's where a centralized [treasury operating model](https://gravam.com/blog/treasury-operating-model-centralized-vs-decentralized) becomes concrete inside SAP.

SAP's own documentation states the payoff in one sentence, and it's the sentence to quote in a business case: In-House Cash is used for processing internal and external payment transactions within a group, and by using it **"you can reduce the number of external bank accounts you hold and the volume of foreign payments you have to make."** That is the whole thesis. The rest of this page is the named objects underneath it — bank areas, payment orders, tables, BAdIs, archiving objects and the newer In-House Banking apps — verified against SAP Help rather than reproduced from the scraped lists this topic attracts.

## What it is, in SAP's own structure

The main component is the **in-house cash centre**: SAP describes it as "basically a virtual internal bank where subsidiaries hold current accounts". Current account processing depicts the receivables and payables between the centre and its affiliated companies, calculates turnover and balances, and forwards that information **in summarised form to Financial Accounting**. That last clause matters more than it looks: the general ledger sees summarised current-account movement, not one FI document per internal payment, which is why the intercompany reconciliation design has to be deliberate rather than emergent.

Four transaction categories are documented, and getting your scope statement to name them explicitly saves a lot of later argument:

- **Internal payments** — between group entities, across internal accounts
- **Central payments** — the centre pays externally on a subsidiary's behalf
- **Local payments** — settled locally between clearing partners
- **Central incoming payments** — collections arriving centrally and credited internally

Payment orders don't only arrive by hand. SAP documents three automatic origins — an inbound IDoc from a subsidiary system, an external bank statement, or Treasury Management — and tells you where to look when you can't tell which: the **Input Channel** field in the payment order's management data.

You can run more than one centre. SAP is explicit that you "can decide to implement one or more in-house cash centres within your group of companies", which is the usual answer to regional-treasury structures.

## The organisational object: the bank area

If one concept is worth learning before you open the IMG, it's this one, because IHC does not invent its own account infrastructure — it borrows **Bank Customer Accounts (BCA)**:

| Object | What SAP's documentation says |
| --- | --- |
| **Bank area** | Organisational unit of Bank Customer Accounts that allows independent account management; account numbers must be unique within it |
| Bank area count | "The number of bank areas that you define corresponds to the number of cash centres you have" |
| Bank key | Attached to the bank area; with the account number it identifies the internal bank in payment transactions |
| Company code | Exactly one company code per bank area; a company code may have several bank areas |
| FI system | Different financial accounting systems can be assigned to different bank areas |

The bank-area Customizing sits in BCA, not in IHC, and SAP names what you set there: the bank key, the check digit method controlling account-number issuing, the daily posting cut-off time, the exchange rate category, and the country, language and holiday calendar. The holiday calendar is the one that quietly breaks value dating in month one.

One operational consequence worth reading twice: when a feeder system transfers payment items, the bank area is determined **from the bank key**. If a payment item is forwarded to the system by BAPI and the bank area cannot be determined, SAP documents that the BAPI terminates with a system-error return code and **no items are processed** — a whole-batch failure, not a per-item one.

## Configuration: where the settings actually live

| Path | What it configures |
| --- | --- |
| IMG → Financial Supply Chain Management → **In-House Cash** | The module's own Customizing |
| Customizing → Account Management → Payment Processes in In-House Cash → **Define Transaction Types** | The transaction types IHC payment orders carry |
| … → Outgoing Payment Orders → Instructions for FI → **Define Instruction Codes for FI** | Instructions forwarded with outgoing payment orders |
| IMG → FSCM → **Advanced Payment Management** → External Interfaces → Posting Interfaces → In-House Cash (IHC) | The APM-to-IHC posting interface, when APM routes payments |
| SAP Easy Access → Accounting → Financial Supply Chain Management → In-House Cash | Where the functions are on the menu |

That last row is not filler. SAP Help documents this module by **menu path and Customizing node**, not by transaction code — which is precisely why the tcode-dump sites are so confident and so unreliable here. See the exclusions at the end.

## The tables, and how SAP names them

The [treasury tables reference](https://gravam.com/blog/sap-treasury-tables) deliberately excluded In-House Cash, on the grounds that it's a different component with its own family and mixing them is how those 400-row dumps became unusable. Here is that family, taken from the place SAP actually publishes it — the documentation for archiving object `IHC_ARC`:

| Table | SAP's description |
| --- | --- |
| `IHC_DB_PN` | Source document for incoming payment orders |
| `IHC_DB_PN_BP` | Address data of business partners involved in the payment order |
| `IHC_DB_PN_STATUS` | IHC payment order status |
| `IHC_DB_PN_RINFO` | Reference / note-to-payee information |
| `IHC_DB_PN_CONT` | Container fields in the payment order |
| `IHC_DB_PN_ENQ` | Lock table for the payment order |

The same archiving run also touches the generic application-log and change-document tables — `BALDAT`, `BALHDR`, `BAL_INDX`, `CDHDR`, `CDCLS`, `CDPOS_STR`, `CDPOS_UID` — which tells you something useful about IHC's audit trail: the change history is standard change documents, so it is reportable with the tools you already have.

Archiving is where the current-account side becomes visible, because it has its own object set:

| Archiving object | What it archives |
| --- | --- |
| `IHC_ARC` | In-House Cash payment orders |
| `FIBA_ORDER` | Payment orders (when Bank Current Accounts are used) |
| `FIBA_ITEM` | Payment items |
| `FIBA_PECAL` | Account balancing |
| `FIBA_INCAL` | Account balancing details |
| `FIBA_CFBAL` | Balances carried forward |
| `FIBA_TOTAL` | Value date transaction figures |
| `FIBA_BKST` | Bank statements |

Three details from the `IHC_ARC` documentation that belong in a retention design rather than being discovered during an audit: payment orders can only be archived when their final status is **Final, Posted, Deleted or Reversed**; ILM-based archiving requires them to be blocked by program **`IHC_APPL_BLOCK_PN`** with business function **`FIN_IHC_ILM`** active; and the ILM condition fields are the **IHC bank area** and the **IHC payment order status**, with the retention period counted from the last-changed date (or the creation date, if the order was never processed after creation).

## The extension points

Custom requirements in IHC land on a small, documented set of BAdIs. Knowing them turns "can we do X" from a research project into a lookup:

| BAdI | What it overrides |
| --- | --- |
| `IHC_BADI_BCA_ITEMS` | Adds to the posting data when current-account payment items are generated |
| `IHC_BADI_CUSTOMIZING` | Overrides Customizing, including whether dual control is active |
| `IHC_BADI_GUI_CHECKS` | Your own checks, selections and value help for manual payment-order processing |
| `IHC_BADI_IDOC_2_PN` | Transaction type, execution date and value date, on an inbound IDoc |
| `IHC_BADI_PN_2_IDOC` | An outbound IDoc, before it is sent |
| `IHC_BADI_POST_BEHAV` | Posting behaviour for IHC payment orders |
| `IHC_BADI_XBS_TRNS` | Transaction type determination for central incoming payments, per bank statement item |

`IHC_BADI_IDOC_2_PN` and `IHC_BADI_XBS_TRNS` are the two that show up in almost every implementation, because both sit exactly where a real-world file meets an idealised configuration table.

## Where the Transaction Manager plugs in

Treasury deals settle through IHC by a documented route rather than by accident. SAP provides the BAdI **`TPM_EXT_PAYMENT_TRPR`** for connecting payment programs to the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager), and ships an **example implementation named `HC_CFM_ADAPTOR`**, delivered inactive, that realises the connection to In-House Cash. SAP's own recommendation is not to activate the example directly but to create your own implementation that calls its methods — and the method that decides per payment is **`IS_RELEVANT`**: return `X` and the payment goes through In-House Cash, otherwise it is processed as a payment order.

Two things follow. First, treasury payments to IHC run on **payment requests**, not customer-account postings — SAP states that if you want to process a payment using In-House Cash, payment is done using payment requests, which is the same [F111 world](https://gravam.com/blog/sap-treasury-transaction-codes) treasury settlements already live in. Second, the generated payment orders are visible from the treasury side, in the posting journal and in the transaction's cash flow, so the audit trail from deal to internal account is a navigable one.

## Payments on behalf of, and the APM boundary

The modern payments-on-behalf-of flow runs through [Advanced Payment Management](https://gravam.com/blog/sap-advanced-payment-management-apm), and SAP documents the mechanics precisely enough to design against. The subsidiary's payment run posts to an in-house bank clearing account per its payment method setup, and generates at least two IDocs — **`PEXR2003`** and **`PAYEXT`** — which are sent to headquarters' APM. There they become an APM payment order with one originator item and the recipient items; enrichment and validation, then routing and clearing, determine which house bank pays what, and additional outgoing orders are created per bank with the clearing item on that bank's clearing account.

One configuration fact worth knowing before someone promises it in a workshop: **payment on behalf of _inside the same company code_ is deactivated in the standard system** and can be activated only via a BAdI in Routing Control. This is the SAP-side detail behind the [payment factory](https://gravam.com/blog/what-is-a-payment-factory) versus in-house bank distinction, and the external leg still leaves through [Bank Communication Management](https://gravam.com/blog/bank-communication-management-bcm-sap).

> IHC and a [payment factory](https://gravam.com/blog/what-is-a-payment-factory) are often confused, and they're complementary, not competing. In-House Cash is the _internal-banking backbone_ — the internal accounts and intercompany balances. The payment factory is the _centralization of external payment execution_. IHC provides the internal accounts that payments-on-behalf-of relies on; the payment factory centralizes how payments reach the banks.

## The other In-House thing: In-House Banking (IHB)

This is the trap in the topic, and it is worth being pedantic about because the two names differ by one word. **In-House Banking (IHB)** is not a rename of In-House Cash. SAP documents it as "an embedded capability of advanced payment management" for SAP S/4HANA Cloud for advanced payment management, usable only within APM, in which subsidiaries open internal bank accounts that behave, from the subsidiary's side, like house bank accounts.

It is Fiori-first, and unlike classic IHC it has app IDs you can verify:

| App | App ID |
| --- | --- |
| Manage In-House Bank Accounts | F5942 |
| Upload In-House Bank Accounts | F6038 |
| Manage In-House Bank Account Templates | F6039 |
| Manage In-House Bank Limits | F5940 |
| Manage In-House Bank Conditions | F5941 |
| Manage In-House Bank Account Workflows | F6131 |
| Manage In-House Bank Fees | F6335 |
| Manage In-House Bank End of Day | F6338 |
| Manage In-House Bank Payment Items | F6339 |
| Display In-House Bank Account Overdrafts | F6340 |
| Manage In-House Bank Account Balances | F6341 |
| Manage In-House Bank Interest Compensation | F6652 |
| Manage In-House Bank Application Jobs | F6653 |

Its own archiving objects follow the `/PF1/` namespace. `/PF1/ACCT` (accounts) and `/PF1/ACBL` (account balancing data) each have their own SAP Help page, cited below; the siblings listed alongside them in that section of SAP's documentation cover account limits, financial conditions, statements and the destruction of end-of-day logs. Read the section rather than assuming an object name — this namespace is where SAP puts the in-house-banking counterparts of the IHC objects above. Two capability notes from SAP's page that decide designs: conditions resolve in a fixed order — **single, then group, then bank area level** — and the electronic bank statement produced by in-house banking is, in SAP's wording, a "CAM.053 message", with "further formats not yet available". If your subsidiaries need [MT940](https://gravam.com/blog/mt940-format-tags-explained) from the internal bank, that is a gap to plan around, not a setting to find.

## The prize, and the catch

The prize is the [in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) prize, and now you can quantify it from SAP's own framing: fewer external accounts to hold, fewer foreign payments to make, cash concentrated centrally, internal settlement instead of external payments. The catch is the same one that shadows all of this — **intercompany accounting**. Every internal transaction and on-behalf-of payment generates intercompany balances that have to be tracked, reconciled and settled, with interest at proper rates and the [transfer-pricing](https://gravam.com/blog/debt-and-investment-management-in-treasury) and tax implications handled. IHC gives you the internal bank; it also gives you an internal book to run with real rigour.

## In-House Cash design mistakes

- **Underestimating intercompany accounting.** The internal accounts generate intercompany balances that must be tracked, reconciled and settled — and remember FI receives summarised current-account movement, not a document per internal payment. Design this up front, not after go-live.
- **Bank areas designed as an afterthought.** One company code per bank area is a hard constraint, and the bank-area count is your cash-centre count. Getting this wrong is a re-implementation, not a config change.
- **Treating it as pure technology.** IHC is an operating-model and accounting change as much as a system one; configure the module and neglect the process, and adoption and reconciliation suffer.
- **Confusing IHC, the payment factory and In-House Banking.** Three different things, two of which share a name. Scoping one when you needed another is how the centralization ends up half-built.
- **Ignoring the tax/transfer-pricing angle.** Intercompany lending and on-behalf-of activity carry real tax and transfer-pricing implications that treasury can't wave away.

## What I left out, on purpose

- **IHC transaction codes.** This is the deliberate gap, and the honest one. SAP's In-House Cash documentation is written around menu paths and Customizing nodes; I could not verify a set of IHC GUI transaction codes in SAP Help, so none are printed here. The codes circulating on dump sites may well be right — but "may well be" is not this site's standard. Where you do need archiving administration, the objects above are called through `SARA`, and `AOBJ` shows which archiving classes an object triggers; both are documented.
- **The BCA current-account tables.** In-House Cash's payment-order tables are documented (above); the Bank Customer Accounts persistence beneath the current accounts is not, in anything I could verify. The archiving objects are the sanctioned handle on that data instead.
- **In-House Banking Fiori apps without a printed app ID.** The In-House Banking Dashboard is documented as an app but its page carries no app ID, so it appears here without one rather than with a guessed one.
- **Release and edition availability.** Which of classic IHC and In-House Banking you actually get depends on your release and deployment model, and stating a version from memory is how references go stale. Check your release notes.

Use IHC as the internal-banking backbone of a centralized SAP treasury — paired with a [payment factory](https://gravam.com/blog/what-is-a-payment-factory) for external payments — and design the intercompany accounting as carefully as the cash. It's a powerful piece of the centralization story, and, like every part of that story, it's only as clean as the intercompany plumbing beneath it.

***

_See also [what is an in-house bank](https://gravam.com/blog/what-is-an-in-house-bank) and [what is a payment factory](https://gravam.com/blog/what-is-a-payment-factory)._

## Primary sources

Named objects verified against SAP S/4HANA 2025 FPS01 on-premise documentation. IHC's GUI transaction codes are deliberately absent: SAP Help documents this module by menu path and Customizing node rather than by transaction code, and I would not print a code I could not verify. In-House Banking (IHB) is a separate, newer capability of Advanced Payment Management with its own apps — check which of the two your release and edition actually gives you.

- SAP Help — In-House Cash (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/9900c5536a51204be10000000a174cb4.html
- SAP Help — Bank Area (In-House Cash / Bank Customer Accounts) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/a13dc65375b31e4be10000000a174cb4.html
- SAP Help — IHC Payment Order (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/bc01c5536a51204be10000000a174cb4.html
- SAP Help — Archiving In-House Cash Payment Orders with IHC_ARC — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/4c0d1c542b0ef57de10000000a174cb4.html
- SAP Help — Data Management for In-House Cash (IHC) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/430d1c542b0ef57de10000000a174cb4.html
- SAP Help — Business Add-Ins (BAdIs) for SAP In-House Cash — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/4601c5536a51204be10000000a174cb4.html
- SAP Help — Connection of Transaction Manager to In-House Cash — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/2b1cc55368511d4be10000000a174cb4.html
- SAP Help — Payment 'On Behalf Of' (In-House Cash), Advanced Payment Management — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/5ba72d6ef3354e1fa15481d97ba5ea87.html
- SAP Help — Configuring In-House Cash (IHC) for Advanced Payment Management — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/3ab85bf760bf432ea31f579984bdd7ce.html
- SAP Help — In-House Banking (SAP S/4HANA Cloud for Advanced Payment Management) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/3dbe688b4c8840da8567f811be2bc1b4.html
- SAP Help — Manage In-House Bank Accounts (app F5942) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/1b2d43023d2d471cb8e61a57a1d6178c.html
- SAP Help — Archiving In-House Bank Accounts Using /PF1/ACCT — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/d3a3672cad4a4348a6171470c3438139.html

## Questions this article answers

**Q: What is SAP In-House Cash (IHC)?**

SAP In-House Cash (IHC) is the SAP module for running an in-house bank — a central function that maintains internal accounts for the group's subsidiaries and processes payments between them and on their behalf. SAP's own documentation states the purpose plainly: to reduce the number of external bank accounts you hold and the volume of foreign payments you have to make. The main component is the in-house cash centre, described as a virtual internal bank where subsidiaries hold current accounts; it calculates the turnover and balances of those accounts and forwards them in summarised form to Financial Accounting.

**Q: How does SAP In-House Cash work?**

IHC acts as a virtual bank inside SAP. It maintains internal current accounts for participating subsidiaries, and processes four documented transaction categories: internal payments, central payments, local payments and central incoming payments. Subsidiaries' positions are held as internal account balances (intercompany balances), interest can be applied through conditions, and statements are produced for the internal accounts much as an external bank would. Payment orders reach the in-house cash centre automatically from an inbound IDoc sent by a subsidiary's payment run, from an external bank statement, or from Treasury Management.

**Q: What is a bank area in SAP In-House Cash?**

A bank area is the organisational unit that In-House Cash borrows from Bank Customer Accounts, and it is the object that allows independent account management: account numbers must be unique within a bank area. SAP's documentation states that the number of bank areas you define corresponds to the number of in-house cash centres you have. You must assign exactly one company code to a bank area, though one company code can carry several bank areas, and the bank key attached to the bank area is what identifies the internal bank in payment transactions.

**Q: Which tables store SAP In-House Cash payment orders?**

SAP names them in the documentation for archiving object IHC_ARC, which archives payment orders from IHC_DB_PN (source document for incoming payment orders), IHC_DB_PN_BP (address data of the business partners involved), IHC_DB_PN_STATUS (payment order status), IHC_DB_PN_RINFO (reference and note-to-payee information), IHC_DB_PN_CONT (container fields) and IHC_DB_PN_ENQ (the lock table). The current-account side has its own archiving objects instead — FIBA_ORDER, FIBA_ITEM, FIBA_PECAL, FIBA_INCAL, FIBA_CFBAL, FIBA_TOTAL and FIBA_BKST.

**Q: What is the difference between In-House Cash and a payment factory?**

In-House Cash and a payment factory are related and often implemented together. In-House Cash is the internal-bank capability — maintaining internal accounts and processing internal settlement and on-behalf-of transactions. A payment factory is the centralization of external payment execution. IHC provides the internal-banking backbone (the internal accounts and intercompany balances) that payments-on-behalf-of relies on, while the payment factory centralizes how payments actually reach the banks. In an SAP landscape they work together to centralize both the internal banking and the external payments.

---

# Migrating SAP Treasury from ECC to S/4HANA

Source: https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Migrating SAP treasury from ECC to S/4HANA: the simplification items that change (BP, bank accounts, One Exposure, TRM) and what the 2027 deadline means.

**Migrating SAP treasury from ECC to S/4HANA is not an upgrade — it's substantially a re-implementation, because S/4HANA redesigned key treasury areas, most of all Cash Management around [One Exposure from Operations](https://gravam.com/blog/one-exposure-from-operations-fqm-flow).** I've said this in passing across this guide, and it's worth its own article because it's the single most expensive misconception in SAP treasury right now: teams scope the treasury piece of an S/4HANA move as "lift and shift, just newer," and then discover in testing that significant parts had to be _rebuilt_. The concepts a treasurer knows carry over. The plumbing beneath them does not. Plan for the second sentence, not the first.

## Why it's not an upgrade

An upgrade implies the same thing, newer. But S/4HANA didn't just modernize treasury — in places it _redesigned_ it. The clearest example is [Cash Management](https://gravam.com/blog/sap-cash-management-s4hana): classic maintained its own summary records; S/4HANA rebuilds the whole thing on the [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) hub. That's not a reskin — it's a different foundation. When the foundation changes, "upgrade" is the wrong word and the wrong plan. A re-implementation-sized effort is also the moment some treasuries briefly reopen the [SAP TRM vs standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms) question — if you have to rebuild either way, the embedded-vs-best-of-breed call is on the table again.

## What actually changes

> The concepts survive; the plumbing is new. Position, forecast, deals, risk — a treasurer recognizes all of it. But how those concepts are stored, computed and reached has changed underneath, and configuration and data don't migrate themselves across a redesign.

- **Cash Management** — redesigned around [One Exposure / `FQM_FLOW`](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), a new data model, not the classic summary records.
- **Tools** — much moves to **[Fiori apps](https://gravam.com/blog/sap-treasury-fiori-apps)**.
- **Bank accounts** — house bank accounts stop being configuration and become master data in [SAP Bank Account Management](https://gravam.com/blog/sap-bank-account-management-s4hana).
- **Business partner** — every customer and vendor has to be a [business partner](https://gravam.com/blog/business-partner-configuration-sap-treasury) before the conversion runs.
- **TRM** — the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) and [risk components](https://gravam.com/blog/sap-market-risk-analyzer) carry treasury forward, but configuration and postings still need rework and re-testing.

## The simplification items that touch treasury

SAP publishes every functional change in the Simplification List, one "S4TWL" item and SAP Note per change, and SAP Readiness Check reports which of them your system actually triggers. Most of the list is irrelevant to treasury. These are the ones that are not:

| Area | ECC (what you have) | S/4HANA (what replaces it) | What it means for the project |
| --- | --- | --- | --- |
| Business partner | Customers and vendors as separate masters; TRM counterparties already business partners | Business partner as the single entry point for customer and supplier data (S4TWL Business Partner Approach, note 2265093) | Customer/vendor integration (CVI) must synchronise all customers and vendors to BPs in ECC, before conversion. Decide first how records that exist as both customer and vendor, and as TRM counterparty, map to one BP |
| House bank accounts | Maintained with FI12 as transportable configuration in T012K | Bank account master data in Bank Account Management (FCLM_BAM_AMD); house banks via FI12_HBANK or the Manage Banks app, accounts via Manage Bank Accounts; master data, not transported | T012K accounts are migrated to BAM during conversion, by the central data migration activity or manually with FCLM_BAM_MIGRATION. Clean up missing or malformed account data before the migration, not after |
| Cash management foundation | Classic cash management and liquidity forecast built on FDES/FDSB records | S4TWL Cash Management – General (note 2270400): classic cash and liquidity management is not available; flows live in One Exposure (`FQM_FLOW`) | One Exposure is filled from existing documents by the data setup (FQM_INITIALIZE), and memo records need their own migration step: check which one your target release uses. Reconcile the first position against ECC before anyone trusts it |
| Cash position and forecast | FF7A / FF7B reports, Liquidity Planner | FF7AN / FF7BN and the Fiori Cash Position and Liquidity Forecast apps; Liquidity Planner superseded by Fiori liquidity management apps | The report users open every morning changes. Planning levels and groups survive in the back end, but layouts, grouping and authorisations are rebuilt |
| Cash management scope | One module | Basic scope included with S/4HANA; full scope (SAP S/4HANA Finance for cash management) via business function FIN_FSCM_CLM, which cannot be reversed | Decide the licence scope first: liquidity items, cash pooling, bank fee monitoring and BAM workflows need full scope. See [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana) |
| Treasury and Risk Management | Transaction Manager, Exposure Management 1.0, correspondence, position reports | TRM continues, but the list carries TRM items including Exposure Management 1.0, Simulation in Transaction Management, Drawable Bonds, Quantity Ledger Always Active for Money Market Transactions, Correspondence Functionality and Position Reports | Read each triggered note. Exposure Management 2.0 is the S/4HANA exposure component, so 1.0 users plan that move explicitly; correspondence and position reports usually need re-configuration and re-testing |
| Position management and valuation | TRM subledger posting to classic FI (BKPF/BSEG, new-G/L totals) | Valuation areas and posting logic carry forward, with the general-ledger side landing in the Universal Journal (ACDOCA) | Re-run key-date valuation (TPM1) and compare the posting journal (TPM20) against ECC for every [valuation area](https://gravam.com/blog/sap-trm-position-management-and-valuation); the numbers must tie, not just post |
| Pre-TRM treasury data | Enterprise 1.10, CFM 2.0 or 4.6C-era treasury structures | The TRM data model | SAP's migration guide requires converting customizing, master and transaction data with TPM_MIGRATION. Do that as its own project in ECC before the S/4HANA conversion, not inside it |
| Custom reads of classic tables | Interfaces and reports on FDES, T012K, BSEG and the BSIS/BSAS index tables | FQM_FLOW, FCLM_BAM_AMD and ACDOCA; the index and totals tables become compatibility views | A table still existing is not the same as it still being the right source. Inventory every custom read; the [BKPF/BSEG join guide](https://gravam.com/blog/02-bkpf-bseg-join) covers the accounting side |

Two cautions about the table. Item titles and notes change between releases, so confirm the list for your _target_ release rather than the one a colleague used. And the Simplification List tells you what changed, not how your processes should look afterwards; that design work is the re-implementation part.

## The 2027 date, stated accurately

The deadline driving most of these programmes is real but often misquoted. Per SAP's published maintenance timelines, **SAP ERP 6.0 on enhancement packages 6, 7 and 8 leaves mainstream maintenance on 31 December 2027**. After that, SAP offers optional **extended maintenance until 31 December 2030**, under a separate agreement at additional cost. Systems still on enhancement packages 0 to 5 already left mainstream maintenance at the end of 2025 and fell into customer-specific maintenance, which brings no new legal changes.

The **SAP ERP, private edition, transition option**, announced in February 2025, stretches support for ERP 6.0 to the end of 2033 only for customers who move to RISE with SAP and meet its conditions. It is not an extension for on-premise systems. For treasury planning that means a 2027 conversion window with a paid fallback to 2030, and anything later is a contractual decision rather than a technical one.

## Approach it as a transformation

The right frame is the one this whole site argues for: treat it as a [treasury transformation](https://gravam.com/blog/treasury-transformation-guide), not a technical task. That means:

- **Define the outcomes** — what you want the target treasury to do, not just "be on S/4." A re-implementation is also a chance to rescope: the [SAP Treasury Module Selector](https://gravam.com/tools/sap-treasury-module-selector) is a quick way to re-map your actual needs to components before you rebuild what you had by habit.
- **Plan real [data migration](https://gravam.com/blog/tms-data-migration)** — open deals, positions, master data, balances, all migrated and reconciled to the penny (deals and positions are unforgiving of migration errors).
- **Rework and re-test the configuration** — especially the [postings](https://gravam.com/blog/sap-transaction-manager) and the redesigned Cash Management; don't assume classic config carries.
- **Run a real [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems)** — rehearsed, at a clean [period boundary](https://gravam.com/blog/cutover-and-go-live-for-finance-systems), with a fallback.

## Test like it's new — because it is

The trap that catches migrations is _under-testing_ on the assumption that "it worked in ECC." But the [Cash Management redesign](https://gravam.com/blog/sap-cash-management-s4hana) means the position and forecast are computed differently, and reworked config means the postings can behave differently — so [testing](https://gravam.com/blog/testing-strategy-for-finance-systems) has to prove the numbers _reconcile_ in the new world, not trust that they did in the old one. Run real scenarios — a close, a payment run, a valuation — and check the totals. The migration's biggest risk is a number that was right in ECC and is subtly wrong in S/4 because something in the redesign wasn't re-tested.

## Why treasury moves to S/4HANA overrun

- **Treating it as a technical upgrade.** The core mistake — scoping "lift and shift" when the Cash Management redesign means re-implementation.
- **Underestimating the Cash Management change.** Assuming classic Cash Management carries over, when it's rebuilt on One Exposure.
- **Weak data migration.** Migrating open deals, positions and balances carelessly, so the opening picture is wrong.
- **Not re-testing the postings.** Trusting ECC's accounting behaviour instead of proving it in S/4, and finding a wrong number after go-live.

Scope the treasury piece of an S/4HANA move as the re-implementation it substantially is, migrate the deals and positions with care, rework and re-test the configuration — especially the redesigned Cash Management — and run it as a [transformation](https://gravam.com/blog/treasury-transformation-guide) with a real cutover, and it goes from a landmine to a controlled programme. The concepts you know will carry you; the assumption that nothing underneath changed is what sinks you. This is exactly the kind of finance-systems change [delivered without losing control](https://gravam.com/topics/finance-systems-delivery) — SAP treasury edition. The edition you land on shapes the migration path too: see the [deployment & edition comparison](https://gravam.com/blog/sap-treasury-deployment-and-edition-comparison).

***

_See also [SAP Cash Management in S/4HANA](https://gravam.com/blog/sap-cash-management-s4hana) and [treasury transformation: a practical guide](https://gravam.com/blog/treasury-transformation-guide)._

## Primary sources

SAP ERP 6.0 (ECC) EHP 6-8 converting to SAP S/4HANA on-premise or private edition; simplification items named as they appear in the SAP S/4HANA Simplification List (2021-2025 editions) — confirm applicability for your target release with SAP Readiness Check. Cash Management follows the One Exposure model (business function FIN_FSCM_CLM for full scope). Maintenance dates per SAP's published ERP 6.0 timelines. Claims checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- SAP Help — Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/e7d3a052c3ad224fe10000000a445394.html
- SAP — Simplification List for SAP S/4HANA 2025 (S4TWL items for Business Partner, Cash Management and Treasury and Risk Management) — accessed 2026-09-25 — https://help.sap.com/doc/0df2ffddebab40cf9338488b2f18dc41/2025.latest/en-US/SIMPL_OP2025.pdf
- SAP Community (SAP) — Maintenance Timelines for SAP ERP 6.0 ("ECC") — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/maintenance-timelines-for-sap-erp-6-0/ba-p/13524564
- SAP News — New Offering to Help Navigate Complex RISE with SAP Transformations (SAP ERP, private edition, transition option), February 2025 — accessed 2026-09-25 — https://news.sap.com/2025/02/sap-erp-private-edition-transition-option-navigate-complex-rise-with-sap-transformations/
- SAP Community (SAP) — FAQ: CVI – Customer Vendor Integration for system conversion to SAP S/4HANA (note 2265093, S4TWL Business Partner Approach) — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/faq-cvi-customer-vendor-integration-for-system-conversion-to-sap-s-4hana/ba-p/13740757
- SAP Help — Switch Migration Program for House Bank Accounts — accessed 2026-09-25 — https://help.sap.com/doc/474a13c5e9964c849c3a14d6c04339b5/100/en-US/e7cf1319b7b14ddebd3f717725fc2936.html
- SAP Community (SAP) — How to manually migrate House Banks during a system conversion using FCLM_BAM_MIGRATION — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/how-to-manually-migrate-house-banks-during-a-system-conversion-using-fclm/ba-p/13541790
- SAP KBA 2530138 — FAQ: S/4HANA Cash Management and data setup — accessed 2026-09-25 — https://apps.support.sap.com/sap/support/knowledge/preview/en/2530138
- SAP Help — Exposure Management 2.0 (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/4c3af7c7b48f1ca9e10000000a42189e.html
- SAP Help (Support Content) — Treasury migration guide (TPM_MIGRATION for Enterprise 1.10 / CFM 2.0 / 4.6C treasury data) — accessed 2026-09-25 — https://help.sap.com/docs/SUPPORT_CONTENT/fiscm/3643836869.html

## Questions this article answers

**Q: Is migrating SAP treasury to S/4HANA an upgrade or a re-implementation?**

For treasury, it's much closer to a re-implementation than a technical upgrade. S/4HANA redesigned key treasury areas — most significantly Cash Management, which is rebuilt around the One Exposure from Operations hub rather than the classic summary records. So while it's part of a broader S/4HANA move, the treasury piece involves a genuinely new data model, new tools (Fiori apps), and reworked configuration. Teams that scope it as 'just upgrading treasury' consistently under-plan it and get caught out in testing.

**Q: What changes for treasury when moving to S/4HANA?**

The biggest change is Cash Management, which is redesigned around One Exposure from Operations (table FQM_FLOW) instead of maintaining its own separate summary records — a different foundation, not a reskin. Every customer and vendor must be synchronised to a business partner before conversion, house bank accounts become bank account master data in Bank Account Management, and classic cash management reports such as FF7A and FF7B give way to FF7AN, FF7BN and Fiori apps reading One Exposure. Transaction Manager and the risk components carry the treasury concepts forward, but configuration, data and testing all need genuine attention. The concepts a treasurer knows carry over; the plumbing beneath them is new.

**Q: When does SAP ECC mainstream maintenance end?**

For SAP ERP 6.0 on enhancement packages 6, 7 and 8, mainstream maintenance ends on 31 December 2027, with optional extended maintenance available at extra cost until 31 December 2030. Enhancement packages 0 to 5 already left mainstream maintenance at the end of 2025 and moved to customer-specific maintenance. The SAP ERP, private edition, transition option offers support to the end of 2033 only for customers who move to RISE with SAP under its conditions; it is not an extension of on-premise maintenance.

**Q: How should you approach an SAP treasury S/4HANA migration?**

Approach it as a transformation project, not a technical upgrade: define the outcomes, plan real data migration for open deals, positions and master data, rework and re-test the configuration (especially the postings and the redesigned Cash Management), and run a proper cutover. The single most important mindset is refusing to treat it as 'lift and shift' — because the Cash Management redesign in particular means significant parts have to be rebuilt and re-tested, and pretending otherwise is what turns these projects into overruns.

---

# SAP Portfolio Analyzer: Returns and Benchmarks in TRM

Source: https://gravam.com/blog/sap-portfolio-analyzer
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: The SAP TRM Portfolio Analyzer: TWRR, MWRR and Dietz returns, benchmarks, the portfolio hierarchy and results database — and when it's worth implementing.

**The Portfolio Analyzer is the SAP TRM component that measures the returns and performance of the treasury portfolio — how the investments and positions are actually doing, often against benchmarks.** It's the third [Analyzer](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), and I'll be honest in the way this guide tries to be: it's the least central of the three for most corporate treasuries. Where the [Market Risk Analyzer](https://gravam.com/blog/sap-market-risk-analyzer) asks _what are the positions worth and what's the risk?_ and the [Credit Risk Analyzer](https://gravam.com/blog/sap-credit-risk-analyzer) asks _how exposed are we to each counterparty?_, the Portfolio Analyzer asks _how well is the book performing?_ — a question that matters a great deal if you run a real investment portfolio, and rather less if you don't.

## What it is

The Portfolio Analyzer is about **performance** — the achieved returns of the portfolio over time, and how they measure up. It takes the positions and their results and turns them into performance analytics: returns, comparisons to benchmarks, and a breakdown along the portfolio hierarchy of where the returns came from. It's the "how did we do?" lens on the same book the other Analyzers value and risk-assess.

## What it does

- **Returns measurement** — how much the portfolio has returned over a period.
- **Benchmark comparison** — how those returns stack up against a chosen benchmark or expectation.
- **Drill-down** — returns at any level of the portfolio hierarchy, so a result can be traced to where it came from, not just reported.

## How it calculates returns

SAP's documentation is specific about the methods, and they're worth knowing by name because the choice changes the answer:

- **Time-weighted rate of return (TWRR)** — the return of the investments themselves, neutral to when cash was added or withdrawn; the right measure to compare against a market benchmark.
- **Money-weighted rate of return (MWRR)** — the return actually earned on the money invested, so the timing and size of inflows and outflows count.
- **Dietz and modified Dietz** — approximation methods SAP offers alongside the exact TWRR calculation.

Around the methods sit two features that make the numbers defensible. **Benchmarks**: you define benchmark rates of return and compare them with the returns of any part of the portfolio. **Versioning**: the portfolio hierarchy, the return calculations and the benchmark calculations are versioned, so you can see what a past calculation was based on and reproduce it — which is what an auditor or an investment committee will eventually ask for. Evaluations run at any level of the portfolio hierarchy, or for one asset category across several portfolios.

## The objects behind it

The Portfolio Analyzer doesn't have a big transaction footprint; its substance is in a few shared Analyzer objects:

| Object | What it is | Where it lives |
| --- | --- | --- |
| Analysis characteristics | The fields the Analyzers can group and report by | Basic Analyzer Settings — defined, then activated |
| Analysis structure | The structure built from those characteristics, activated in Customizing | Basic Analyzer Settings — shared with Market Risk |
| Portfolio hierarchy | The tree of characteristics returns and benchmarks are calculated along | Built from the characteristics; versioned |
| Financial object (JBDO) | The Analyzer-side representation of each deal or position; its analysis attributes control processing | Automatic financial object integration, or manually |
| Results database | Stored key figures: single-record per transaction, final results aggregated over the hierarchy | Filled by calculation runs, e.g. in end-of-day processing |
| Analyzer Information System | Reporting on the results database, navigating the hierarchy down to single records | Shared with the other Analyzers |

Two things follow from that table. First, the Portfolio Analyzer **shares its foundation with the Market Risk Analyzer**: the Basic Analyzer Settings (characteristics, analysis structure) apply to both, and the SAP Community configuration walkthrough starts Portfolio Analyzer setup there. If you already run the Market Risk Analyzer, a good part of the groundwork exists. Second, the results database separates **calculation from reporting**: key figures are generated once and can then be displayed as often and in as many cuts as you like without recalculating — useful, but it means a report is only as current as the last run.

Transaction codes are deliberately thin here. JBDO (financial objects) is shared across the Analyzers; tcode lists also circulate portfolio-hierarchy codes that I couldn't confirm in SAP's documentation, so they're not on this page — the same rule the [transaction-codes reference](https://gravam.com/blog/sap-treasury-transaction-codes) applies.

## How it connects to the Transaction Manager and market data

The input is the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager): its deals and positions reach the Portfolio Analyzer as financial objects, so an investment without a financial object doesn't exist for performance purposes. Returns are computed on values, and values come from [market data](https://gravam.com/blog/sap-treasury-market-data-management) — security prices, rates and curves — so a missing price is a wrong return, not an error message. And it's an on-premise story: SAP S/4HANA Cloud Public Edition has no Portfolio Analyzer at all.

## Where it sits among the Analyzers

The three Analyzers are complementary lenses on the same portfolio:

| Analyzer | Answers |
| --- | --- |
| **[Market Risk](https://gravam.com/blog/sap-market-risk-analyzer)** | What's it worth, and what could it lose? |
| **[Credit Risk](https://gravam.com/blog/sap-credit-risk-analyzer)** | How exposed are we to each counterparty? |
| **Portfolio** | How well has it performed? |

Value, exposure, performance — together they give the risk and investment functions a full picture of the book.

## When it's worth it

> The honest test for the Portfolio Analyzer: _does the business genuinely need to measure and report investment performance?_ If you run a material, actively-managed investment portfolio, yes — performance analytics are exactly the question you're asking. If your treasury is mostly cash, liquidity, funding and hedging with little discretionary investment, the Portfolio Analyzer may answer a question no one is asking, and the implementation effort is better spent elsewhere.

This is a running theme in how I think about treasury systems: implement the capability where it answers a real question, and skip it where it doesn't. The Portfolio Analyzer is powerful for the treasuries that need it and overhead for the ones that don't — and knowing which you are is the whole decision. It's closely tied to the [surplus-cash and investment](https://gravam.com/blog/managing-surplus-cash) side of treasury: the more of that you do, the more performance measurement earns its keep.

## When Portfolio Analyzer measures nothing useful

- **Implementing it by default.** Building performance analytics no one will use, because it came in the box, when the treasury has little investment to measure.
- **Poor data quality.** Performance numbers built on incomplete or wrong data — missing financial objects, missing prices — like any [analytics](https://gravam.com/blog/sap-market-risk-analyzer), only as good as the inputs.
- **Wrong or missing benchmarks.** Measuring returns against nothing, or against an inappropriate benchmark, so the numbers don't mean much.
- **The wrong return method.** Reporting a money-weighted return where the question was manager performance against a benchmark — or the reverse.
- **Over-engineering a small book.** An elaborate portfolio hierarchy and benchmark set on a portfolio too small to justify it.

Use the Portfolio Analyzer where the business genuinely runs and reports on investment performance — clean data, sensible benchmarks, proportionate to the book — and it completes TRM's analytical picture with the performance lens. Skip it where the treasury isn't really an investor, and spend the effort where the questions actually are. It rounds out the [Analyzers](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), and it's the one whose value depends most on what kind of treasury you actually are.

***

_See also [the SAP Market Risk Analyzer](https://gravam.com/blog/sap-market-risk-analyzer) and [managing surplus cash](https://gravam.com/blog/managing-surplus-cash)._

## Primary sources

SAP S/4HANA on-premise/private edition (some SAP Help pages cited come from the SAP ERP documentation set). SAP S/4HANA Cloud Public Edition has no Portfolio Analyzer. Verify against your release. The 2026-09-25 fact-check used cross-checked excerpts of SAP Help and SAP Community pages returned by search, because SAP Help could not be opened directly from the verification environment; claims that could not be confirmed in at least one SAP-published source were left out.

- SAP Help — Portfolio Analyzer (Treasury and Risk Management, SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/48055e53ae50e047e10000000a441470.html
- SAP Help — Evaluations Using the Results Database (SAP ERP) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_ERP/4d6b9b32599844ee81b23a443efedb7f/5ffa4b530f57ff4fe10000000a44176d.html
- SAP Help — Analyzer Information System — accessed 2026-09-25 — https://help.sap.com/doc/d213da531198434de10000000a174cb4/3.6/en-US/7799d65378024308e10000000a174cb4.html
- SAP Community — Portfolio Analyzer Configuration 101 — accessed 2026-09-25 — https://community.sap.com/t5/financial-management-blog-posts-by-members/portfolio-analyzer-configuration-101/ba-p/13385714

## Questions this article answers

**Q: What is the SAP Portfolio Analyzer?**

The Portfolio Analyzer is the component of SAP Treasury and Risk Management that measures the returns and performance of a company's financial portfolio — how its investments and positions are actually doing over time, often compared against benchmarks. Where the Market Risk Analyzer answers 'what are the positions worth and what's the risk?' and the Credit Risk Analyzer answers 'how exposed are we to each counterparty?', the Portfolio Analyzer answers 'how well is the portfolio performing?' It's most relevant to treasuries that run a material investment portfolio.

**Q: How is the Portfolio Analyzer different from the Market Risk Analyzer?**

The Market Risk Analyzer values positions and measures market risk — what things are worth now and how much market moves could cost. The Portfolio Analyzer measures performance — the returns the portfolio has generated over time and how they compare to expectations or benchmarks. One is about current value and potential loss; the other is about achieved return and how well the book has done. They're complementary, and they share the same Analyzer foundation: financial objects, analysis characteristics and the portfolio hierarchy.

**Q: Does every SAP treasury need the Portfolio Analyzer?**

No. The Portfolio Analyzer earns its place where a company runs a material investment portfolio whose performance genuinely needs measuring and reporting. For a treasury focused mainly on cash, liquidity, funding and hedging — with little discretionary investment — return and performance analytics may add little, and the effort is better spent elsewhere. It is also not part of SAP S/4HANA Cloud Public Edition, so on that edition the question doesn't arise.

**Q: Which return methods does the SAP Portfolio Analyzer support?**

SAP documents exact methods for the time-weighted rate of return (TWRR) and the money-weighted rate of return (MWRR), plus the Dietz and modified Dietz approximation methods for the time-weighted return. Returns can be calculated for any level of the portfolio hierarchy or for an asset category across portfolios, and compared against benchmark rates of return you define. The portfolio hierarchy and the return and benchmark calculations are versioned, so past results can be reproduced.

---

# SAP Market Risk Analyzer: NPV, Sensitivities and VaR

Source: https://gravam.com/blog/sap-market-risk-analyzer
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: The SAP TRM Market Risk Analyzer: evaluation types, yield curve types, NPV and key figure analysis (JBRX, AISS, AISGENKF), and VaR — all driven by market data.

**The Market Risk Analyzer is the SAP TRM component that values financial positions and measures market risk — net present value, sensitivities, scenarios and value-at-risk.** It's the engine behind two questions every treasury has to answer: _what are our positions worth right now?_ and _how much could market moves cost us?_ It's one of the three [Analyzers](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) in TRM, and the one the risk team lives in. The critical thing to hold onto: everything it produces is computed from [market data](https://gravam.com/blog/market-data-in-treasury-systems) — so its output is only ever as good as the rates and curves you feed it. [Get the market data wrong](https://gravam.com/blog/sap-treasury-market-data-management) and the Analyzer will confidently produce precise, wrong numbers.

## What it does

The Market Risk Analyzer takes the [positions](https://gravam.com/blog/sap-transaction-manager) TRM holds and does two kinds of work on them:

- **Valuation** — what each instrument and position is _worth_ now: present value / mark-to-market.
- **Risk measurement** — how that value could _change_: sensitivities, scenarios, and value-at-risk.

Together, that's the "value and risk" half of TRM — the counterpart to the Transaction Manager's "deals and positions" half, while the achieved _performance_ of that same book is the [Portfolio Analyzer](https://gravam.com/blog/sap-portfolio-analyzer)'s job.

## Valuation

The core is **valuation** — computing the present value of the deals and positions in the book. This is what turns a portfolio of contracts into a number you can report, mark to market, and feed into [hedge accounting](https://gravam.com/blog/hedge-accounting-explained). It's driven by discounting future cash flows on the relevant curves, which is exactly why the [market data](https://gravam.com/blog/market-data-in-treasury-systems) — the curves, the rates, the prices — is the beating heart of the whole thing.

## The objects behind the numbers

Every Market Risk Analyzer number is the product of a handful of configuration objects, and knowing them is what lets you answer "where did that NPV come from?":

- **Evaluation type** — the central one. It controls which market data a calculation uses: on its Market Data Categories tab you assign yield curve types, exchange rate types, FX volatility types and basis spread curve types. SAP states that the evaluation type's settings are required to calculate the NPV of financial transactions and treasury positions, and the Analyze NPV, Calculate Net Present Values, Calculate Market Risk Key Figures and sensitivity apps all let you choose one.
- **Valuation rules** — how particular products are valued, assigned to the evaluation type.
- **Yield curve types** — defined in Customizing under General Settings (Define Yield Curve Types) from reference interest rates in ascending order of term; those rates are the curve's grid points. The risk-based NPV is calculated on these curves and can include credit spreads.
- **Financial objects** — the Analyzers don't read deals directly; each deal is represented by a financial object, created automatically when financial object integration is active (or manually in JBDO).
- **Analysis structure** — in the Customizing activity Select Analysis Structure Category you choose the generated analysis structure, the static one, or both. With the static structure, market risk key figures are calculated from **market risk key figure sets** (Manage Market Risk Key Figure Sets) in two steps: a run stores the basic values — NPVs, profits and losses, delta positions per financial object — and CDS queries do the final calculation.

| Code / app | SAP's name | What you use it for |
| --- | --- | --- |
| JBRX | Analyze NPV (single value analysis: NPV) | NPV of individual deals and positions for an evaluation type and horizon |
| AISS | Sensitivity Key Figures - Single Analysis | How values move when rates and prices move |
| AISGENKF | Key Figure Analysis | Formula-based key figures, built on the JBRX and AISS infrastructure |
| TPM60 / TPM60CVA | Calculate Net Present Values | Calculate and save NPVs that valuation and reporting read; TPM60CVA adds CVA and DVA |
| RAEP1_KFSET | Calculate Market Risk Key Figures | Step one of the static analysis structure: basic values per object |
| AFWO1_KFSET | Monitor MR Key Figure Calculations | Check those runs |
| C_TrsyMktRskKeyFigValueQry / C_TrsyValueAtRiskQuery | CDS queries | Step two: the final key figures and value-at-risk, at a confidence level |

JBRX and TPM60 match the [transaction-codes reference](https://gravam.com/blog/sap-treasury-transaction-codes). Keep AISGENKF and the batch run apart: AISGENKF sits in the menu under Market Risk Analyzer > Information System > Key Figure Analysis, while the batch calculation for key figure sets is RAEP1_KFSET under Tools.

## The risk measures

Beyond "what's it worth," the Analyzer measures "what could happen":

- **Sensitivities** — how much a position's value moves when a rate or price moves (the [FX](https://gravam.com/blog/fx-risk-transaction-translation-economic-exposure) and [interest-rate](https://gravam.com/blog/interest-rate-risk-in-corporate-treasury) exposures, quantified). SAP delivers key figures such as basis point value, modified duration, convexity, yield to maturity and the option sensitivities delta, gamma, theta and vega.
- **Scenarios / simulation** — what the book would be worth under defined market conditions.
- **Value-at-risk** — a statistical estimate of potential loss over a horizon at a chosen confidence level, via historical simulation, the variance/covariance approach or Monte Carlo simulation.

Results are read in the Analyzer Information System, which lets you navigate a portfolio or risk hierarchy from the total down to single records. These are the numbers that inform risk decisions and feed the limits and reporting the risk function runs on.

## How it connects to the Transaction Manager and market data

Upstream sits the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager): its deals, via their financial objects, are the population every analysis runs over. The same pricing also serves accounting — NPVs saved with TPM60 feed [key-date valuation](https://gravam.com/blog/sap-trm-position-management-and-valuation), which is why the risk view and the accounting view have to reconcile. And every calculation reads the rates loaded through the [market data interfaces](https://gravam.com/blog/sap-treasury-market-data-management) (TBDM, TBD4, TBEXN) or maintained by hand, as exchange rates are in OB08, selected by rate type and assembled by the evaluation type. A wrong rate type in an evaluation type is a configuration error that produces a plausible number.

## Market data is everything

> The Market Risk Analyzer is a calculation engine, and a calculation engine is only as good as its inputs. Every valuation and risk number it produces is built from [market data](https://gravam.com/blog/market-data-in-treasury-systems) — FX rates, interest curves, prices, volatilities. Wrong or stale data doesn't produce an error; it produces a _wrong number that looks right_. So the discipline around sourcing, validating and controlling market data matters as much as the Analyzer's own config. This is where I'd look first when a valuation is questioned — starting with which evaluation type the run used.

## Why it matters

The Market Risk Analyzer produces the numbers that _drive decisions and reporting_ — the valuations in the accounts, the exposures the risk team manages, the measures behind hedging and limits. When those numbers are trusted, the risk function works on facts; when they're suspect, every downstream decision inherits the doubt. Its job is to make the value and risk of the book _knowable_ — accurately, which means with clean data behind it.

## Why Market Risk Analyzer numbers mislead

- **Bad or stale market data.** The number-one cause of wrong output — garbage rates in, garbage risk numbers out, silently.
- **Inconsistent data sources.** Different rate types or evaluation types feeding different calculations, so numbers don't reconcile.
- **Misreading the measures.** Treating a statistical measure like value-at-risk as a certainty rather than what it is.
- **Config without understanding.** Setting up evaluation types, valuation rules and yield curve types without understanding the financial maths they implement, so errors go uncaught.

Feed the Market Risk Analyzer clean, controlled, consistent [market data](https://gravam.com/blog/market-data-in-treasury-systems), understand the measures it produces, and it becomes the reliable value-and-risk engine of TRM — the place the whole risk function's numbers come from. Neglect the data, and it becomes a very sophisticated way to be precisely wrong. In a calculation engine, the inputs are the product.

***

_See also [market data in treasury systems](https://gravam.com/blog/market-data-in-treasury-systems) and [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management)._

## Primary sources

SAP S/4HANA on-premise/private edition (the evaluation-type page cited is from the SAP S/4HANA Cloud documentation, where the same object is configured). Classic transactions named here are GUI transactions; verify availability against your release and edition. The 2026-09-25 fact-check used cross-checked excerpts of SAP Help, SAP Community and SAPinsider pages returned by search, because SAP Help could not be opened directly from the verification environment; claims that could not be confirmed in at least one SAP-published source were left out.

- SAP Help — Market Risk Analyzer (Treasury and Risk Management, SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/8505c753b1081d4be10000000a174cb4.html
- SAP Help — Overview: Calculating NPVs in TRM (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/7bef515413e5843ae10000000a44538d.html
- SAP Help — Define and Set Up Evaluation Types (Treasury and Risk Management, SAP S/4HANA Cloud) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/e5ec5859d8e54df98492d80564a734c0/4149eeb39c10469698b19355e41dab60.html
- SAP Help — Calculate Market Risk Key Figures (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/c4b94dd03c1f4f2c949992c36141f342.html
- SAP Help — Static Analysis Structure (Market Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/474a13c5e9964c849c3a14d6c04339b5/100/en-US/0d5428dfa40e4d78b8f869eba4b45a79.html
- SAP Help — Analyzer Information System — accessed 2026-09-25 — https://help.sap.com/doc/d213da531198434de10000000a174cb4/3.6/en-US/7799d65378024308e10000000a174cb4.html
- SAPinsider — Gauge a Company's Risk Exposure Using Market Risk Analyzer — accessed 2026-09-25 — https://sapinsider.org/articles/gauge-a-companys-risk-exposure-using-market-risk-analyzer/

## Questions this article answers

**Q: What is the SAP Market Risk Analyzer?**

The Market Risk Analyzer is the component of SAP Treasury and Risk Management that values financial positions and measures market risk. It calculates the value of deals and positions (such as net present value), runs sensitivity and scenario analyses, and produces market-risk measures like value-at-risk. In short, it answers two questions: what are our financial positions worth right now, and how much could movements in market rates and prices cost us? It's driven by market data, so its output is only as good as the rates and curves feeding it.

**Q: What does the Market Risk Analyzer calculate?**

The Market Risk Analyzer calculates valuations — the net present value or mark-to-market of financial instruments and positions — and market-risk key figures such as basis point value, modified duration, convexity, yield to maturity and the option sensitivities delta, gamma, theta and vega. On top of those come scenario results and value-at-risk, which SAP supports through historical simulation, the variance/covariance approach and Monte Carlo simulation. These feed both risk management, where they inform decisions and limits, and accounting, where valuations support mark-to-market and hedge accounting.

**Q: Why does market data matter so much for the Market Risk Analyzer?**

Because every valuation and risk measure it produces is computed from market data — FX rates, interest rate curves, security prices and volatilities. The evaluation type decides which of those are used: it assigns the yield curve types, exchange rate types and volatility types a calculation reads. If that data is wrong, stale, or inconsistent, every number the Analyzer produces inherits the error, silently, because a wrong valuation still looks like a valuation. So sourcing, validating and controlling the market data feeding the Analyzer is as important as the Analyzer's own configuration.

**Q: Which transaction codes does the SAP Market Risk Analyzer use?**

The everyday ones are JBRX (Analyze NPV) for single-value NPV analysis, AISS (Sensitivity Key Figures - Single Analysis) for sensitivities, and AISGENKF for key figure analysis with formula-based key figures. TPM60 calculates and saves NPVs, with TPM60CVA as the variant including CVA and DVA. With the static analysis structure, RAEP1_KFSET (Calculate Market Risk Key Figures) computes the basic values per financial object and AFWO1_KFSET monitors those runs; the final key figures and value-at-risk are then read through CDS queries.

---

# SAP Credit Risk Analyzer: Counterparty Limits in TRM

Source: https://gravam.com/blog/sap-credit-risk-analyzer
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: The SAP TRM Credit Risk Analyzer: limit types and characteristics, attributable amounts, the limit check at deal entry, and TBL1, TBLB and KLNACHT.

**The Credit Risk Analyzer is the SAP TRM component that measures counterparty/credit risk and manages limits — quantifying exposure to each counterparty as an _attributable amount_, checking deals against limits, and flagging breaches.** It's how SAP turns the [counterparty-limit discipline](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) from a policy document into an enforced system control. Treasury policy decides _how much_ exposure to any one bank or partner is acceptable; the Credit Risk Analyzer is what makes the dealing actually _stay_ within it — measuring exposure, holding the limits, and checking every deal against them. It's one of the three [Analyzers](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), and the one that keeps a good policy from being just a good intention.

## What it is

Every treasury runs on [counterparty limits](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) — caps on how much it will be exposed to any single institution, so no one failure is catastrophic. The Credit Risk Analyzer is where those limits live and bite in SAP: it knows the current exposure to [each counterparty](https://gravam.com/blog/business-partner-configuration-sap-treasury), holds the limit for each, and enforces the relationship between them. SAP frames it as measuring, analyzing and controlling _default risk_: the loss if a business partner doesn't meet its obligations.

## What it does

Three connected jobs: **measure exposure** to each counterparty across its deals and positions, **maintain the limits** policy has set (per counterparty, often by other dimensions too), and **check transactions** against them as they're entered, so a deal that would breach is caught.

## The objects you actually configure

This is the part generic descriptions skip. Five objects carry most of the weight:

- **Limit characteristics** — the dimensions a limit can be defined on. SAP delivers seven direct characteristics for the default risk limit: company code, business partner, limit product group, portfolio, trader, currency and monitoring unit.
- **Limit types** — a combination of limit characteristics, such as business partner plus limit product group. The limit type decides which transactions a limit collects; a limit type filter can narrow it further with ranges.
- **Limit product groups** — your grouping of products for limit purposes; walkthroughs typically split investments, derivatives and cash balances.
- **Determination procedure and default risk rule** — the default risk rule is derived per transaction, and each combination of the two specifies the formula for the attributable amount.
- **Netting groups and collateral agreements** — a netting group defines which business partner's transactions are balanced and carries its own default risk rule; [collateral agreements](https://gravam.com/blog/isda-csa-and-collateral-management) assigned to it reduce attributable amounts, and with them limit utilization.

| Code | SAP's name | What you use it for |
| --- | --- | --- |
| TBL1 | Manage Limits | Create and maintain limits (Credit Risk Analyzer > Master Data) |
| TBLB | Review Limit Utilizations | The limit utilization overview — what is using each limit right now |
| KLNACHT | End-of-Day Processing | Recalculate attributable amounts and update every utilization |
| KLNACHT2 | Execute Postprocessing | The error messages of the end-of-day run |

The check at deal entry has no transaction of its own: it's switched on in Customizing (Credit Risk Analyzer > Basic Settings > Activate Integrated Default Risk Limit Check) and runs inside the Transaction Manager.

TBL1, TBLB and KLNACHT match the [transaction-codes reference](https://gravam.com/blog/sap-treasury-transaction-codes). Tables such as KLNT01 and KLMAXLIMIT are named in SAP's data-protection documentation but not described — the [tables reference](https://gravam.com/blog/sap-treasury-tables) explains why they get no rows.

## What it actually calculates: the attributable amount

Every limit is compared against the **attributable amount** — SAP's measure of the default risk that arises when a transaction is concluded, meant to reflect expected and unexpected loss. It's a formula: a base key figure with parameters such as add-on factors and default probabilities. For counterparty and issuer risk the base is typically the net present value or the nominal amount; for settlement risk it's usually the repayment amount. A limit's **utilization** is then simply the sum of the attributable amounts of all transactions assigned to that limit through their characteristic values.

Which risk category a product draws on is configuration: an SAP-authored walkthrough on SAP Community sets FX spots to settlement risk only and FX forwards to credit risk — a decision that determines which limit a spot-heavy day consumes.

## Limit checking is the point

> A counterparty limit you only check _after_ the deal is done isn't a control — it's a report of the breach you already have. The Credit Risk Analyzer's value is checking _before_, at the point of dealing, so the limit actually stops something.

The heart of it is **checking at the point of dealing**. With the integrated check active, each transaction is checked when it is created in the Transaction Manager: the system determines attributable amounts for every risk category released for the single transaction check, then checks the maximum risk commitment period, internal and external limits, and the critical limit utilization — the percentage above which an early warning fires. The result comes back as a traffic light. The same check can also test a deal that isn't in the system yet, before it is struck.

Be precise about what a breach does. In SAP standard, a limit excess raises a **warning**, and a "workflow is active" setting can route a message to a responsible person; the deal can still be saved. A hard stop is a deliberate extra configuration decision, not a default — which is why the reaction has to be designed with the [risk policy](https://gravam.com/blog/treasury-risk-management-policy), not in a separate room.

## End of day: KLNACHT

The check at deal entry keeps utilizations current during the day; **end-of-day processing (KLNACHT)** is the final update. It revalues all transactions and positions, including external transactions entered for deals outside the Transaction Manager — so an NPV-based attributable amount moves with the market even if nobody touched the deal. It usually runs as a scheduled job; KLNACHT2 shows what failed, TBLB shows the result.

## How it connects to the Transaction Manager and market data

The Credit Risk Analyzer holds no deals of its own. It reads the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager): when a deal is created, its limit characteristics and attributable-amount parameters are derived onto the financial object the Analyzer evaluates. Two upstream things are therefore decisive. The [Business Partner](https://gravam.com/blog/business-partner-configuration-sap-treasury) is the counterparty the limit sits on, so a duplicated partner splits exposure across two records. And where the attributable amount is NPV-based, it's only as right as the [market data](https://gravam.com/blog/sap-treasury-market-data-management) behind the valuation.

## Why it matters

The Analyzer is where the [counterparty discipline](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) — set limits, diversify, monitor, act early — stops depending on someone remembering to look at a spreadsheet. Counterparty risk [feels like nothing until it's everything](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury); when policy says "no more than X to any one counterparty," this is what holds the line, deal by deal. It's the difference between having a counterparty limit and _enforcing_ one.

## Why counterparty limits become theatre

- **Limits not maintained.** Limits set at go-live and never updated in TBL1 as counterparties and appetite change.
- **Warnings nobody owns.** SAP's standard reaction to an excess is a warning; without the workflow switched on and someone accountable for the result, it gets clicked through and the control is theatre.
- **Exposure measured wrongly.** A determination procedure or default risk rule that doesn't capture true exposure — or a product mapped to the wrong risk category — so limits are checked against the wrong number.
- **End-of-day run nobody watches.** KLNACHT fails, KLNACHT2 isn't checked, and TBLB shows stale utilizations.
- **Policy and config designed apart.** Limits in the system that don't match the actual risk policy, so neither is trustworthy.

Maintain the limits, measure exposure correctly, check at the point of dealing with a deliberate warn/stop decision, and keep the configuration aligned to policy — and the Credit Risk Analyzer becomes the enforcement layer that makes counterparty limits real. Policy sets the appetite; this is what holds the dealing to it, automatically, at the one moment a limit can actually prevent something.

***

_See also [counterparty and credit risk in treasury](https://gravam.com/blog/counterparty-and-credit-risk-in-treasury) and [the treasury risk management policy](https://gravam.com/blog/treasury-risk-management-policy)._

## Primary sources

SAP S/4HANA on-premise/private edition (the classic transactions named here are GUI transactions; several SAP Help pages cited come from the SAP ERP and SAP Simple Finance documentation sets). Verify against your release. The 2026-09-25 fact-check used cross-checked excerpts of SAP Help, SAP Community and SAPinsider pages returned by search, because SAP Help could not be opened directly from the verification environment; claims that could not be confirmed in at least one SAP-published source were left out.

- SAP Help — Credit Risk Analyzer (Treasury and Risk Management, SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/bc08da531198434de10000000a174cb4.html
- SAP Help — Default Risk and Limit System (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/af02c753b1081d4be10000000a174cb4.html
- SAP Help — Limit Types (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/c009da531198434de10000000a174cb4.html
- SAP Help — Attributable Amount Determination (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/f909da531198434de10000000a174cb4.html
- SAP Help — Single Transaction Check (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/bb09da531198434de10000000a174cb4.html
- SAP Help — Checking New Transactions (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/c508da531198434de10000000a174cb4.html
- SAP Help — Updating Limit Utilizations (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/7a0ada531198434de10000000a174cb4/700_SFIN20%20006/en-US/f508da531198434de10000000a174cb4.html
- SAP Help — End-of-Day Processing (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/7a0ada531198434de10000000a174cb4/700_SFIN20%20006/en-US/0dbd9753858ced23e10000000a174cb4.html
- SAP Help — Netting (Credit Risk Analyzer) — accessed 2026-09-25 — https://help.sap.com/doc/ac03c55368511d4be10000000a174cb4/700_SFIN3E%20006/en-US/1a0ada531198434de10000000a174cb4.html
- SAP Community — Credit Risk Analyzer: Limits Management, Money Market (Fixed Deposits) and Forex (Spots) — accessed 2026-09-25 — https://community.sap.com/t5/financial-management-blog-posts-by-sap/credit-risk-analyzer-limits-management-money-market-fixed-deposits-and/ba-p/14277230
- SAPinsider — A Guide to SAP's Credit Risk Analyzer — accessed 2026-09-25 — https://sapinsider.org/a-guide-to-saps-credit-risk-analyzer/

## Questions this article answers

**Q: What is the SAP Credit Risk Analyzer?**

The Credit Risk Analyzer is the component of SAP Treasury and Risk Management that measures counterparty and credit risk and manages limits. It quantifies how much exposure the company has to each counterparty (banks and trading partners) as attributable amounts, maintains the limits set for them, and checks transactions against those limits, flagging deals that would breach them. In effect, it's how SAP enforces the counterparty-limit discipline that treasury policy defines, turning limits from a document into a system control.

**Q: How does the Credit Risk Analyzer manage limits?**

Limits are defined on limit types, which combine limit characteristics such as company code, business partner, limit product group, portfolio, trader, currency and monitoring unit. Each transaction produces an attributable amount, and a limit's utilization is the sum of the attributable amounts of the transactions assigned to it. With the integrated single transaction check active, a new deal in the Transaction Manager is checked against its limits as it is entered; end-of-day processing (KLNACHT) then recalculates every utilization. In SAP standard, an excess raises a warning and can trigger a workflow; a hard stop is a separate, deliberate configuration decision.

**Q: How does the Credit Risk Analyzer relate to counterparty risk management?**

The Credit Risk Analyzer is the SAP implementation of counterparty risk control. Counterparty risk management as a discipline means setting limits on how much exposure you'll carry to any single bank or partner, diversifying, and monitoring — and the Credit Risk Analyzer is where those limits become enforceable in the system: exposure is measured, limits are held, and deals are checked against them automatically. The policy decides how much risk is acceptable; the Credit Risk Analyzer makes sure the dealing actually stays within it.

**Q: Which transaction codes does the SAP Credit Risk Analyzer use?**

The working set is small. TBL1 (Manage Limits) creates and maintains limits, TBLB (Review Limit Utilizations) shows what is using them, KLNACHT (End-of-Day Processing) recalculates attributable amounts and utilizations, and KLNACHT2 (Execute Postprocessing) shows the error messages of that run. The limit check at deal entry has no transaction of its own: it runs inside the Transaction Manager when the integrated default risk limit check is activated in Customizing.

---

# SAP Transaction Manager: Deals and Instruments

Source: https://gravam.com/blog/sap-transaction-manager
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-08-01
Reviewed: 2026-08-19
Summary: The Transaction Manager is the core of SAP TRM, where financial deals live — money market, FX, securities and derivatives, from capture to accounting.

**The Transaction Manager is the core of SAP TRM — the component where financial deals live and move through their lifecycle: money market, FX, securities and derivatives, captured and processed front-to-back office into position, valuation and accounting.** If TRM has a home you'll spend most of your time in, this is it. And here's the truth from implementation after implementation: the deal _capture_ is the easy, visible part; the [accounting behind it](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) is where the project's effort and its arguments actually concentrate. When a TRM timeline slips, it's rarely because someone couldn't enter an FX forward — it's because the team is three weeks deep in _how that forward should post_.

## What it is

The Transaction Manager manages financial transactions through their whole life — from the moment a dealer strikes a deal [against a counterparty](https://gravam.com/blog/business-partner-configuration-sap-treasury) to the moment its results land in the [general ledger](https://gravam.com/blog/what-is-sap-treasury-and-risk-management). It's the SAP equivalent of the deal-and-position engine any treasury system has, but native to SAP and wired straight into FI.

## The product areas

It's organized around the main categories of treasury instrument, each with its own instrument types and handling — the [product and transaction type classification](https://gravam.com/blog/sap-trm-product-types-and-transaction-types) behind this has a deep dive of its own:

- **Money market** — deposits, loans, commercial paper and similar short-term instruments.
- **Foreign exchange** — spot and forward FX and related instruments.
- **Securities** — bonds, shares and other tradable instruments.
- **Derivatives** — interest-rate and FX derivatives, typically used for [hedging](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps).

Different products, one common lifecycle underneath — which is the elegant part of the design once you see it.

## The deal lifecycle

Every deal moves through stages that deliberately mirror a treasury's own front/middle/back-office split:

1. **Capture** — the deal is entered (front office), in practice through [the FTR_CREATE family of transaction codes](https://gravam.com/blog/sap-treasury-transaction-codes).
2. **Processing / settlement / confirmation** — checked, confirmed and settled (back office).
3. **[Position management](https://gravam.com/blog/sap-trm-position-management-and-valuation)** — it feeds positions and exposures.
4. **Valuation and risk** — priced and risk-measured (via the [Analyzers](https://gravam.com/blog/what-is-sap-treasury-and-risk-management)).
5. **Accounting** — the results post to FI as [accounting documents](https://gravam.com/blog/02-bkpf-bseg-join).

> That staging isn't bureaucracy — it's [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) built into the process. The dealer who captures a deal must not be the one who settles it. If your design collapses these stages "to save clicks," you've quietly removed a control, and audit will find it before you do. Respect the front/back-office separation; it's there on purpose.

The lifecycle above says what _happens_; this deal-to-accounting flow adds the part that decides where a number lands — what _governs_ each stage. When a posting is wrong, it names the stage to check:

| Stage | What happens | What governs the accounting |
| --- | --- | --- |
| Capture | Deal entered (front office) | Product & transaction type |
| Settlement | Checked, confirmed, settled | Processing category (set on the product/transaction type) |
| Position | Feeds positions & exposures | Position management procedure; account assignment reference |
| Valuation | Priced & risk-measured | Valuation area (one per accounting principle) |
| Accounting | Results post to FI | Update type → posting spec → account symbol; G/L looked up per symbol, valuation area and assignment reference |

Read the last row carefully, because the obvious shorthand for it is wrong. The account assignment reference is not a step the account symbol resolves _into_ — it's a property of the position that, together with the valuation area and currency, decides which G/L account a given symbol points at. The chain runs from the update type to a posting specification to a debit/credit pair of symbols; the reference qualifies the lookup rather than sitting in the middle of it.

The pattern worth keeping: **the account assignment reference is derived when the treasury position is created, and from then on it drives G/L determination for that position's postings** — you can only change it before the first posting, or via a transfer afterwards. Valuation posts separately per valuation area, one per accounting principle. So a wrong posting is usually a determination or valuation-area question, not a capture one. One caveat the table can't hold: "position creation" isn't the same moment for every product — an OTC position appears when the contract is saved, a securities position when the paper is bought into the account, a loan position at disbursement. Behaviour and configuration differ by release and edition (on-premise derives the reference in the IMG, Cloud Public Edition through substitution rules); verify against SAP's documentation for your system.

## Where the effort actually goes

Let me be specific about where TRM projects spend themselves, because no one warns you up front: **the postings.** How each product type and each event in a deal's life should post to the general ledger — that's the design work, the testing work, and the source of most cross-functional debate between treasury and accounting. Deal capture demos beautifully in week two; the posting design is still being argued in [UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems). Budget for it accordingly, and get treasury and accounting in the same room early.

## Master data and correspondence

Two supporting things quietly matter: the **master data** (business partners/counterparties, instruments, conditions) that deals reference — wrong here and every deal inherits the error — and **correspondence/confirmations**, the matching of your deal record against the counterparty's, which is a real control against booking errors and fraud. Neither is glamorous; both bite when neglected.

## Where Transaction Manager projects slip

- **Underestimating the postings.** Treating accounting as an afterthought when it's the bulk of the real work and the main source of delay.
- **Collapsing the deal stages.** Removing the front/back-office separation for convenience, and losing the control with it.
- **Weak master data.** Wrong counterparty or instrument setup, so errors propagate through every deal.
- **Neglecting confirmations.** Skipping the deal-matching control that catches booking errors and fraud.

Understand the Transaction Manager as one lifecycle over four product areas, respect the front/back-office staging as the control it is — it is also the separation that decides whether [an AI agent may release what it created](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment) —, and — above all — plan for the [accounting and posting architecture](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) to be the real work rather than the deal entry, and TRM's core stops surprising you. It's a powerful engine; it just asks that you take its postings as seriously as it does.

***

_See also [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) and [hedge management in SAP](https://gravam.com/blog/hedge-management-in-sap)._

## Primary sources

SAP S/4HANA — verify against your release and edition; behaviour and available apps/tools differ across releases and between on-premise and Cloud.

- SAP Help — Treasury and Risk Management / Transaction Manager (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/3b3e7e53c4d1cc26e10000000a4450e5.html
- SAP Help — Account Assignment References (Treasury and Risk Management) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/fc0ada531198434de10000000a174cb4.html
- SAP Help — Terms in Position Management and Treasury Accounting — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/0c0dda531198434de10000000a174cb4.html
- SAP Help — Parallel Accounting in Treasury and Risk Management — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/651d8af3ea974ad1a4d74449122c620e/dd50d7531a4d424de10000000a174cb4.html

## Questions this article answers

**Q: What is the SAP Transaction Manager?**

The Transaction Manager is the core component of SAP Treasury and Risk Management (TRM) where a company's financial transactions are captured and managed through their lifecycle. It covers the main product areas — money market, foreign exchange, securities and derivatives — and takes each deal from capture through processing, settlement and confirmation, into position management, valuation and accounting. It's where most of the day-to-day treasury dealing activity in SAP happens, and where much of a TRM implementation's effort is concentrated.

**Q: What product types does the SAP Transaction Manager handle?**

The SAP Transaction Manager handles the main categories of treasury financial instruments: money market (deposits, loans, commercial paper and similar), foreign exchange (spot and forward FX, and related), securities (bonds, shares and other tradable instruments), and derivatives (such as interest rate and FX derivatives used for hedging). Each product area has its own instrument types and processing, but all flow through the same lifecycle of capture, processing, position, valuation and accounting.

**Q: How does a deal flow through the Transaction Manager?**

A deal moves through stages that mirror a treasury's front/middle/back-office separation: it's captured (front office), then checked, confirmed and settled (back office), then it contributes to positions and exposures, is valued and risk-measured, and finally posts to financial accounting. This staging enforces segregation of duties — the person who strikes a deal is not the one who settles it — and it's also where much of the configuration and testing effort goes, especially around how each deal type should post to the general ledger.

---

# Hedge Management in SAP: The Cockpit and Hedging Areas

Source: https://gravam.com/blog/hedge-management-in-sap
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Hedge Management in SAP is the risk half of SAP's Hedge Management and Accounting area — Hedge Accounting, switched on separately, designates and posts.

**Hedge Management in SAP is the risk half of an area SAP calls _Hedge Management and Accounting_ — hedging areas, the Hedge Management Cockpit, net open exposure, hedge requests. The other half, Hedge Accounting, is what designates the hedging relationship, holds the documentation, tests effectiveness and generates the postings that keep a sound hedge from creating P&L noise.** Most of the trouble I see starts with treating those as one thing. It's the SAP implementation of a discipline I've written about in general terms already: [hedge accounting](https://gravam.com/blog/hedge-accounting-explained). If you haven't read that piece, read it first — because the single most important thing about SAP Hedge Management is that _the system faithfully reflects how strict the accounting is_, and if you don't understand the accounting, no amount of config knowledge will save you.

## The problem it addresses

Recall the core issue from [hedge accounting](https://gravam.com/blog/hedge-accounting-explained): a derivative hedge is marked to market through profit every period, while the item it hedges often isn't recognized yet — so an _economically sound_ hedge makes reported profit _more_ volatile, not less. Hedge accounting fixes that timing mismatch, and SAP's Hedge Management and Accounting area is where that happens: between them, the two halves turn "we're economically hedged" into "and the accounts show it correctly."

## What it does

The area covers the whole job, but the two halves own different parts of it, and SAP documents them apart.

**Hedge Management** is the risk side:

- **Hedging areas** — the master data setting the granularity at which you monitor FX risk.
- **The Hedge Management Cockpit** — exposures, hedging instruments and existing hedging relationships in one view, with the key figures (net open exposure, overhedge) you act on.
- **Hedge requests** — asking a trader to hedge a currency amount for a date: the execution end of a [layered hedging strategy](https://gravam.com/blog/fx-hedging-strategy), where each layer becomes a request.

**Hedge Accounting** is the accounting side, and it owns everything the standard demands:

- **Designation** — formally connecting the **hedging instrument** (typically a [derivative](https://gravam.com/blog/fx-hedging-instruments-forwards-options-swaps) deal in the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager)) to the **hedged item**.
- **Documentation** — capturing the formal hedge documentation at inception, which the standards demand.
- **Effectiveness** — the assessment evidencing that the hedge offsets the hedged risk: forward-looking only under IFRS 9, with a retrospective assessment still required under IAS 39 and US GAAP (see [hedge effectiveness testing](https://gravam.com/blog/hedge-effectiveness-testing)).
- **Accounting** — generating the entries that align the timing, for the different [hedge types](https://gravam.com/blog/hedge-accounting-explained) (cash flow, fair value, net investment).

The part worth internalising: hedge accounting is _switched on_, not inherited. SAP ships a hedge-management process with no hedge accounting at all — the balance-sheet FX risk flavour — and on the net-open-exposure side nothing designates until the hedging area version is marked relevant for hedge accounting and the hedging classification's hedge accounting indicator is active. So designation isn't the step that goes on to produce the accounting; it's what hedge accounting being active produces in the first place. Scope the two separately, or you will budget for the cockpit and inherit the standard. Why the balance-sheet process can do without hedge accounting at all is the subject of [balance sheet FX hedging vs cash flow hedging](https://gravam.com/blog/balance-sheet-fx-hedging).

## Why it's genuinely hard

> SAP's hedge accounting is unforgiving in exactly the way the accounting standard is unforgiving — because it's implementing that standard. A sound economic hedge still fails hedge accounting if the documentation or effectiveness isn't right, and the system won't pretend otherwise.

This is the area where I've seen the most projects underestimate the work — not because SAP is obscure here, but because **hedge accounting is genuinely strict, and the system holds you to it.** Formal designation and documentation at inception, ongoing effectiveness evidence, correct treatment per hedge type — miss any of it and the relationship doesn't qualify, no matter how good the underlying hedge. The config is deep; the accounting is deeper. Success here needs someone who understands the _standard_, not just the transaction.

## Where it fits

Hedge Management sits on top of the [Transaction Manager](https://gravam.com/blog/sap-transaction-manager) (the hedging instruments are deals there) and reads the exposures being hedged from Exposure Management, FX Management and [Cash Management](https://gravam.com/blog/sap-cash-management-s4hana). The area as a whole is the point where TRM's dealing side and the accounting side meet — and it's why a TRM implementation needs treasury _and_ accounting engaged together, because a hedge relationship is a financial construct and an accounting one at the same time.

## Why hedge relationships fail to qualify in SAP

- **Expecting qualification to follow from economics.** However sound the hedge, it fails without the formal designation, documentation and effectiveness — the system enforces this because the standard does.
- **Documentation gaps.** Missing or late inception documentation disqualifies the relationship.
- **Underestimating the accounting expertise needed.** Staffing it as a pure config task when it demands real hedge-accounting knowledge.
- **Treating it as separate from the deals.** Forgetting that Hedge Management and the Transaction Manager are two ends of one thing.

Approach the hedge accounting half as the system _enforcing_ the [hedge accounting standard](https://gravam.com/blog/hedge-accounting-explained) — designate properly, document at inception, evidence effectiveness, handle each hedge type correctly — and it does exactly what it should: makes the accounts tell the truth about a hedge that already works economically. Approach it as config to be figured out on the fly, and it will teach you, expensively, that the accounting was the hard part all along.

***

_See also [hedge accounting explained](https://gravam.com/blog/hedge-accounting-explained) and [SAP Transaction Manager](https://gravam.com/blog/sap-transaction-manager)._

## Primary sources

SAP S/4HANA — verify against your release and edition; behaviour and available apps/tools differ across releases and between on-premise and Cloud.

- SAP Help — Hedge Management and Accounting of Net Open Exposures (FX Risk), SAP S/4HANA — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/104b7358ff3ca107e10000000a441470.html
- SAP Help — Hedge Accounting (SAP S/4HANA Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/ef50e11850884b5a83ef25b0ee992e83.html
- SAP Help — Hedge Accounting for Exposure Items — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/bca73558e4912260e10000000a44147b.html
- SAP Help — Automated Designation Process — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/38417f58655b9244e10000000a4450e5.html
- SAP Help — Hedge Management Cockpit — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/d69ba95626c76b15e10000000a441470.html
- SAP Help — Display Effectiveness Test Results (Hedge Accounting for Positions) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/79ebf2c79e514699adb326f83199397b.html
- SAP Help — Comparison of Hedge Management and Accounting of Net Open Exposures (FX Risk) and Hedge Management of Balance Sheet FX Risk — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/605b6caef795445986c9aeeb2ce929a9.html
- SAP Help — NIH: Cross-Currency Interest Rate Swap Used as a Hedging Transaction — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/ca0bda531198434de10000000a174cb4.html

## Questions this article answers

**Q: What is Hedge Management in SAP?**

Hedge Management in SAP is the risk-side half of Treasury and Risk Management's Hedge Management and Accounting area: hedging areas that set the granularity at which you monitor FX risk, the Hedge Management Cockpit that shows exposures against hedging instruments and existing hedging relationships, and the hedge requests you raise from it. Its sibling, Hedge Accounting, is the half that formally designates hedging relationships, holds the inception documentation, runs the effectiveness tests and generates the postings. The two are documented separately and hedge accounting is activated deliberately — SAP ships a hedge-management process that has no hedge accounting at all.

**Q: How does SAP support hedge accounting?**

SAP supports hedge accounting by letting you formally designate the hedge relationship (which instrument hedges which item), capture the required documentation at inception, support effectiveness assessment, and then generate the accounting that matches the timing of the hedge and the hedged item — for cash flow, fair value or net investment hedges. The aim is the same as hedge accounting anywhere: to make the reported profit reflect the economic reality that the hedge and the hedged item offset, rather than swinging because a derivative is marked to market while the hedged item isn't yet recognized.

**Q: Why is hedge management hard to implement in SAP?**

Because hedge accounting is strict and detailed everywhere, and SAP faithfully reflects that: it requires formal designation and documentation at inception, ongoing effectiveness evidence, and correct handling of the different hedge types — and if those requirements aren't met, the relationship doesn't qualify. The configuration is deep, the accounting is unforgiving, and a sound economic hedge still fails if the documentation and effectiveness aren't right. It's one of the areas where understanding the accounting standard matters as much as knowing the system.

---

# Planning Levels and Groups in SAP Cash Management

Source: https://gravam.com/blog/planning-levels-and-groups-in-sap
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-03
Reviewed: 2026-09-03
Summary: Planning levels ride on G/L accounts, groups on business partners — and both land in BSEG. The IMG nodes, the rebuild activity and the flow types beside them.

**Planning levels and planning groups are how SAP classifies items for cash management — signalling whether a flow is cash-relevant and where it belongs, by its certainty and proximity to cash.** The enduring idea is simple and worth holding onto regardless of release: not every flow is equal in the cash view. Money sitting in a bank account is _certain_ and belongs to the [cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position); an invoice a customer _might_ pay next month is _expected_ and belongs to the [forecast](https://gravam.com/blog/13-week-cash-flow-forecast). Levels and groups route each flow to the right one — levels through the accounts, groups through the business partners.

This page names the objects: what SAP's own definitions say, which IMG activity configures what, where the values land in the database, and what to run when you change an assignment after go-live.

## SAP's own definitions, which are better than the folklore

Worth quoting, because both sentences carry design information the usual summaries drop:

- **Planning level** — "reflects typical financial transactions, for example, posting to a bank account, posting to a clearing account, confirmed or unconfirmed payment notes, and so on. **It explains the origin of the data and thus enables you to better estimate its reliability.**"
- **Planning group** — "represents a group of customers or vendors with particular characteristics, behaviors or risks. With this attribute, you can break down incoming and outgoing payments **according to the amount, the probability of the cash inflow or outflow, and the type of business relationship**."

Read those two together and the design brief writes itself. A planning level answers _where did this number come from and how much do I trust it_. A planning group answers _who is on the other side, and how do they behave_. Everything else in this article is the plumbing for those two questions.

## The configuration

| Setting | Where |
| --- | --- |
| Planning levels & planning groups | IMG → Financial Supply Chain Management → Cash and Liquidity Management → Cash Management → **Planning Levels and Planning Groups** |
| Planning level assignment | On the relevant **G/L accounts** — SAP names bank accounts, bank clearing accounts and payment request accounts |
| Planning group assignment | In the **customer and vendor master records** |
| Rebuild after a change | IMG → … → Cash Management → **Data Setup** → **Rebuild Planning Levels, Groups, Dates in Accounting Documents** |
| House bank / account field status | Financial Accounting → AR/AP → Business Transactions → Incoming Payments → Incoming Payments Global Settings → Make and Check Document Settings → **Define Field Status Variants** |

SAP's sequencing instruction is explicit and often ignored: configure planning levels and planning groups **before** you use SAP S/4HANA Finance for cash management. Doing it afterwards is possible — that's what the rebuild activity is for — but it is a data-repair exercise rather than a setup step.

## Planning levels

**Planning levels** are assigned to **G/L accounts** — particularly bank accounts, bank clearing accounts, and payment request accounts. The level on the account determines how items posting there appear in the cash view: a bank account carries a level meaning "this is actual cash," while a bank-clearing account (payments in transit) carries one meaning "on its way." As money moves through the chain of accounts — clearing to settled — the planning levels are what express its changing certainty in the position.

The payment-request account is the row people forget, and it's the one that matters to a treasury team: [treasury settlements run as payment requests](https://gravam.com/blog/sap-treasury-transaction-codes), so if the payment request accounts carry no planning level, treasury's own outflows are the ones missing from the position.

## Planning groups

**Planning groups** work the other side — assigned to **customer and vendor master records**, classifying the _expected_ flows from those business partners. SAP's definition gives you the three dimensions to group by: amount, probability of the flow, and the type of business relationship. That's a more useful design prompt than "group by significance", because it says out loud that a planning group is partly a **probability** statement, which is exactly what a [direct forecast](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) needs from its inputs.

> The clean way to remember it: **levels ride on accounts, groups ride on business partners.** Levels classify the money you can see (actuals, by account); groups classify the money you expect (from customers and vendors). Between them, every flow — certain or expected — gets placed.

## Where the values actually land: BSEG

Here is the part that turns this from a concept into something you can debug, and it is the answer to "does any of this still work the same way in S/4HANA": **planning level and planning group are fields on the accounting document segment, database table `BSEG`.** SAP says so in the documentation of the Data Setup activity that repairs them:

> With the Data Setup function, you can rebuild the **Planning Level** and **Planning Group** fields in database table `BSEG`. When you change the assignment of planning levels to G/L accounts, or the assignment of planning groups to customers or vendors, you can execute the Data Setup function to fill in the updated planning level and planning group information into the existing BSEG records.

Three consequences worth carrying into a project plan:

1. **The values are stamped at posting time.** Change the assignment on an account or a business partner and every document already posted keeps the old value until you rebuild.
2. **The rebuild is a named, supported activity**, not a note-based repair — _Rebuild Planning Levels, Groups, Dates in Accounting Documents_ under Cash Management → Data Setup. It sits beside its siblings _Rebuild Flow Types in Accounting Documents_ and _Rebuild Liquidity Items in Accounting Documents_, which do the same job for the other two classifiers.
3. **`BSEG` is where you look when the position is wrong**, and it's the same table the [BKPF/BSEG join article](https://gravam.com/blog/02-bkpf-bseg-join) covers. Two neighbouring fields belong in the same query: `HBKID` (house bank) and `HKTID` (house bank account), which SAP documents inserting into `BSEG` through _Insert House Bank and House Bank Account Data to Accounting Documents_. And because both are optional fields in payments and bank statements by default, SAP suggests making them mandatory for bank and bank-clearing G/L accounts via **Define Field Status Variants** — one of the cheapest data-quality wins in the whole module.

## The classifier that joined them: flow types

The honest S/4HANA answer isn't "planning levels might have changed"; it's that they were **joined** by a second classifier. S/4HANA Cash Management is built on [One Exposure from Operations](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), and One Exposure classifies by **flow type**: "flow types classify the lifecycle of cash flows, for example, it distinguishes forecasted cash flows from confirmed cash flows. Only transaction data that is assigned with flow type information can be consumed and used in Cash Management applications."

SAP predefines the set, and publishes both the numbers and the derivation:

| Category | Flow types |
| --- | --- |
| Receivable/payable | 600000, 600001 (regular increase); 600200, 600201 (unallocated increase) |
| Revenue/expense | 600500, 600501 (increase); 600510, 600511 (decrease) |
| Tax | 300000, 300001 (increase); 300010, 300011 (decrease) |
| Cash in transit | 800006 (incoming), 800008 (outgoing) |
| Cash | 900006 (incoming bank confirmed), 900008 (outgoing bank confirmed) |
| Payment request | 700000 (incoming), 700001 (outgoing) |

And the categories are determined from account configuration, not from judgement — which is why two systems with the same chart of accounts can behave differently:

- **Receivable or payable** — items from invoices with account type `K` (vendor) or `D` (customer).
- **Cash in transit** — G/L accounts maintained in payment-program account determination (`T042I`) or bank-to-bank transfer determination (`T042Y`), that are balance sheet accounts (`SKA1-XBILK`) and not reconciliation accounts (`SKB1-MITKZ`); or accounts flagged cash-relevant (`SKB1-XGKON`) **with** open item management (`SKB1-XOPVW`).
- **Cash** — G/L accounts maintained in house bank accounts (`T012K`), or flagged cash-relevant **without** open item management.

Accounting documents containing items other than these are not handled by the Financial Operations integration into One Exposure at all. If you need an exception in, the activity is **Assign Flow Types to G/L Accounts** under Cash Management → Flow Types — with SAP's own caution attached: do not assign flow types to a G/L account characterised as a reconciliation account.

So the mental model for a modern build: **planning level and group say how reliable a flow is and who it is with; flow type says what stage of its life it is in.** Both are stamped on the document, both have a rebuild activity, and both are prerequisites for the [S/4HANA cash position and forecast](https://gravam.com/blog/sap-cash-management-s4hana) to be right.

## Planning level errors that skew the position

- **Wrong levels on accounts.** Bank and clearing accounts carrying levels that misplace their items, so the position or forecast is subtly wrong — and nobody notices until a treasurer questions a number they already knew.
- **No planning level on payment request accounts.** Treasury's own settlements go missing from the position, which is a memorable way to lose credibility with the people who asked for the system.
- **Assignments changed without a rebuild.** New configuration, old documents, and a position that is right going forward and wrong looking back.
- **Neglected planning groups.** Business partners left in a default group, so the forecast can't distinguish expected flows by probability or relationship — the exact breakdown SAP designed the field for.
- **House bank fields left optional.** `HBKID`/`HKTID` empty on the postings that needed them, and a bank-level view of the position that doesn't reconcile.

## What I left out, on purpose

- **Specific planning level codes and their meanings.** These are customer configuration, not SAP-delivered constants; any list of "the standard levels" is somebody's project, not a standard.
- **The Cloud Public Edition configuration path.** The same settings exist there, reached through configuration apps rather than SPRO; naming a specific app from memory is how references go stale.
- **How planning levels interact with each source application in One Exposure.** SAP documents the accounting-document path in detail (above) and treats the others separately; I've kept to what's documented rather than generalising a rule across source applications.

Understand levels and groups as the _certainty and counterparty classifier_ — levels on accounts, groups on partners, both stamped into `BSEG` — and flow types as the _lifecycle classifier_ that One Exposure needs, and the cash position and [S/4HANA cash forecast](https://gravam.com/blog/sap-s4hana-cash-forecasting) populate correctly. When they don't, the rebuild activities under Cash Management → Data Setup are the first place to go, not the last. The [ECC-to-S/4HANA article](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana) covers what else changes underneath a migration.

***

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

Named objects verified against SAP S/4HANA 2025 FPS01 on-premise documentation. IMG paths and BSEG field names are on-premise/private-edition concerns; in SAP S/4HANA Cloud Public Edition the same settings are reached through configuration apps, not SPRO. Flow type numbers are SAP's predefined set — confirm against your own system before designing on them.

- SAP Help — Planning Levels and Planning Groups (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/12106156c4b61e58e10000000a4450e5.html
- SAP Help — Build Key Information in Accounting Documents (Cash Management Data Setup) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/91779647befa432ba9c1d4c67e6e83e0.html
- SAP Help — Flow Types (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/a00d6156c4b61e58e10000000a4450e5.html
- SAP Help — Field Status (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/ff106156c4b61e58e10000000a4450e5.html
- SAP Help — Set Up Cash Management Data (SAP S/4HANA, One Exposure) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/1ab55956b967c841e10000000a44147b.html
- SAP Help — Business Function: Cash and Liquidity Management (FIN_FSCM_CLM) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c7999f525c5b224fe10000000a445394.html

## Questions this article answers

**Q: What are planning levels in SAP cash management?**

A planning level reflects a typical financial transaction — posting to a bank account, posting to a clearing account, a confirmed or unconfirmed payment note — and SAP's documentation says its purpose is to explain the origin of the data so you can better estimate its reliability. Planning levels are assigned to relevant G/L accounts, in particular bank accounts, bank clearing accounts and payment request accounts, so that items posting to those accounts are routed to the right place in the cash position or liquidity forecast. They classify by certainty and proximity to cash.

**Q: What is the difference between a planning level and a planning group?**

A planning level is assigned to G/L accounts and controls how items on those accounts appear in the cash position and liquidity forecast. A planning group is assigned to customer and vendor master records and classifies expected flows from those business partners; SAP defines it as a group of customers or vendors with particular characteristics, behaviours or risks, letting you break down incoming and outgoing payments by amount, by the probability of the inflow or outflow, and by the type of business relationship. Levels work through the accounts; groups work through the business partners.

**Q: Where are planning levels and planning groups configured in S/4HANA?**

Under Financial Supply Chain Management, Cash and Liquidity Management, Cash Management, Planning Levels and Planning Groups in the implementation guide. SAP's instruction is to configure them before you use SAP S/4HANA Finance for cash management. You then assign planning levels to the relevant G/L accounts and specify the planning group in the customer and vendor master records. A separate Data Setup activity, Rebuild Planning Levels, Groups, Dates in Accounting Documents, refills those fields on documents that were already posted.

**Q: Do planning levels still apply in S/4HANA cash management?**

Yes, and the mechanism is documented rather than assumed. Planning level and planning group are fields on the accounting document segment, database table BSEG, populated from the G/L account and the business partner master when the document posts. SAP ships a Data Setup activity called Rebuild Planning Levels, Groups, Dates in Accounting Documents that refills those BSEG fields when you change the assignments. Alongside them S/4HANA adds flow types, which classify the lifecycle of a cash flow for One Exposure from Operations, so the two classifications coexist rather than replace one another.

---

# Liquidity Items in SAP Cash Management

Source: https://gravam.com/blog/liquidity-items-in-sap-cash-management
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-03
Reviewed: 2026-09-03
Summary: Liquidity items classify cash flows by purpose. The IMG nodes, the derivation queries, the Origin codes D/C/X and the apps — verified against SAP Help.

**Liquidity items classify cash-relevant flows by their _purpose_ — customer receipts, supplier payments, payroll, tax, financing — so the liquidity forecast can be read by category, not just as a wall of amounts.** SAP's own definition is drier and worth having in your design document: liquidity items "represent the source and use of cash flows in your company" and "serve as an import dimension for financial planning and reporting". Here's why they matter more than they sound: a forecast that says "€40m out next month" is nearly useless; a forecast that says "€18m payroll, €12m suppliers, €6m tax, €4m financing" is something you can _act on_.

Liquidity items are attached to flows through **derivation**, and derivation is where projects win or lose this. This page names the objects — the Customizing activities, the query mechanism, the Origin codes and the apps — because "configure the derivation properly" is advice, and a list of the activities you configure it in is a reference.

## Before anything else: the scope gate

Liquidity items are not available in every S/4HANA cash management installation. SAP's business function documentation says it flatly for the basic capability: **"liquidity item is not supported in the basic cash management capability."** They belong to the full scope — SAP S/4HANA Finance for cash management, business function `FIN_FSCM_CLM`, with Full Scope selected in the Customizing activity **Define Basic Settings**. The [S/4HANA Cash Management overview](https://gravam.com/blog/sap-cash-management-s4hana) covers that fork in detail.

I lead with it because it is the cheapest possible discovery and the most expensive possible surprise. A forecast design built on liquidity items, presented to a steering committee, in a system licensed for basic scope, is a bad afternoon.

## Where they are configured

Everything below hangs off one branch: **Financial Supply Chain Management → Cash and Liquidity Management → Cash Management → Liquidity Items**.

| Customizing activity | What it does |
| --- | --- |
| **Edit Liquidity Items** | Defines the liquidity items themselves |
| **Define Default Liquidity Items for G/L Accounts** | The simple case — the item is determined by the G/L account |
| **Define Queries for Liquidity Item Derivation** | The complex case — read fields of the document to decide |
| **Define Query Sequences** | Orders queries into a sequence |
| **Assign Queries to Query Sequences** | Binds the two together |
| **Import and Export Liquidity Items** (under … → Cash Management → **Tools**) | Creates liquidity items en masse across systems |

Two more activities sit outside that branch and are easy to miss: **Define Default Liquidity Items for Liquidity Analysis**, under Cash Management → Data Setup, is the generic setting for the Flow Builder Plus program, and the Flow Builder side of the [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) pipeline is where the flows you are labelling come from in the first place.

## Derivation: the part that is actually a mechanism

The concept is simple; the derivation is the work. SAP splits it into two layers, and the split is the thing to understand:

- **If the liquidity item can be determined by the G/L account**, use _Define Default Liquidity Items for G/L Accounts_. That is a lookup table and it covers a surprising amount of a real chart of accounts.
- **If you need more complex logic** — reading various fields of the accounting document rather than just the account — you define **queries** and **query sequences**.

For accounting documents, derivation runs against database table `BSEG` — the accounting document segment whose [join with BKPF](https://gravam.com/blog/02-bkpf-bseg-join) has its own article here. And the resolution order is documented, which means you can reason about a wrong result instead of guessing at it:

> The system first tries to apply the assigned query sequences; if not successful, then it turns to the default liquidity items defined for G/L accounts.

Query sequences win. The default per G/L account is the fallback, not the baseline. Every "but the account is mapped correctly" support ticket I've seen in this area resolves to a query sequence quietly overriding the account default.

### The Origin codes

`Origin` is the field that tells a query which structure it runs against, and it is the single most-misconfigured setting in the topic:

| Origin | Runs against | Use it for |
| --- | --- | --- |
| `C` | Accounting document line items | Line items with account type **D** (customer) or **K** (supplier) |
| `D` | Accounting document line items | Line items with account types **other than** D or K |
| `X` | The One Exposure from Operations structure | Source-application data (TRM, CML, FI-CA) and classic Cash Management from remote systems |

The mnemonic that keeps it straight: `C` and `D` are the two halves of an accounting document — the customer/supplier half and everything else — while `X` means "I am no longer looking at an FI document at all, I am looking at the hub". SAP states there are **no default derivation rules** for data integrated into One Exposure from source applications in the central system: for TRM, CML or FI-CA flows you must define queries and query sequences with Origin `X`, or those flows arrive with no liquidity item at all. That is the usual reason a forecast is well categorised for receivables and payables and blank for [treasury deals](https://gravam.com/blog/sap-transaction-manager).

### The remote-system special case

Data arriving from remote systems splits again. Classic Cash Management data from remote systems is derived with Origin `X` like any other hub data. **SAP Liquidity Planner actuals are different**: their original liquidity item values are transferred into the One Exposure hub as they are — so the item must exist in _both_ the remote and the central system, or the value arrives pointing at nothing. That is exactly what the **Import and Export Liquidity Items** activity under Cash Management → Tools exists for, and it is the reason that activity is not the administrative footnote it looks like.

## Hierarchies: the reporting shape

Individual items are the label; the **hierarchy** is what makes a forecast readable. Hierarchies are maintained in the **Manage Liquidity Item Hierarchies** app, and SAP documents the mechanics that matter operationally:

- A hierarchy has an **ID, a description and a validity period**, and you can add new timeframes under an existing hierarchy ID to stage a planned reorganisation before it takes effect.
- Nodes are either a **subnode** (a liquidity item that can be a parent) or a **liquidity item** (a leaf, which cannot take children).
- Hierarchies can be saved in **draft** and must be **activated**: "Only activated liquidity item hierarchies can appear in related apps and be used in business."

The draft-and-activate pair is the feature to use rather than route around. It means the honest answer to "can we restructure the forecast categories without breaking this month's reporting" is yes — build the new hierarchy as a new timeframe, activate it when the period turns.

## The apps that make it inspectable

| App | App ID | What it gives you |
| --- | --- | --- |
| Cash Flow Analyzer | F2332 | The forecast itself, sliced by liquidity item |
| Check Cash Flow Items | F0735 | The audit of individual flows behind the numbers |
| Check Liquidity Item on G/L Account | F6459 | Displays the default liquidity items set per G/L account, with the account's cash-relevant fields |
| Manage Liquidity Item Transfer | F6385 | Reclassifies flows between liquidity items, documenting the shift |
| Manage Liquidity Item Hierarchies | — | Hierarchies, timeframes, draft and activate |

`F6459` is the one I'd put in front of a team on day one of a derivation clean-up: it lists the G/L accounts with their default liquidity items alongside the account group, the balance-sheet indicator and the open-item-management flag, which is exactly the evidence you need to see why an account behaves the way it does.

`F6385` deserves a caution to go with it. A liquidity item transfer generates **actual One Exposure flows** — the original items are not necessarily changed, the shift is documented as its own movement, and the transfer's line items must net to zero. It is a correcting entry, not an edit. And if the underlying flows are later deleted or aggregated, the transfer's status goes to **Invalidated** and it can no longer be updated.

For reporting outside the apps, the released CDS views are `I_LiquidityItem` and `I_LiquidityItemText` for the master data, with the cash position and liquidity forecast cube `I_LiquidityPositionCube` and its query `C_LiquidityPositionQuery` above them.

> The health check for liquidity items: look at how much of the forecast lands in the catch-all / unassigned category. A little is normal. A lot means the derivation rules aren't keeping up with the business — and every flow in "other" is a flow the forecast can't explain. `Check Cash Flow Items (F0735)` is where you count it.

## Why it makes or breaks the forecast

This is the part that surprises people: the liquidity forecast's value doesn't come from the amounts — [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow) has those. It comes from the _categorization_. Without good liquidity items, you have a forecast that can total but can't explain; with them, you have one that shows the drivers, supports analysis, and earns trust. It's the SAP expression of a truth from the [forecasting](https://gravam.com/blog/direct-vs-indirect-cash-flow-forecasting) side of treasury: a cash forecast is only useful when you can see _what_ the cash is, not just how much. The same item structure is what joins the apps, the SAP Analytics Cloud plan and an accuracy measure, which [SAP S/4HANA cash forecasting, end to end](https://gravam.com/blog/sap-s4hana-cash-forecasting) follows step by step.

Businesses change, too. Derivation rules that were complete at go-live drift as new flow types appear, and the "other" bucket quietly grows. Treating derivation as a _maintained_ thing rather than a one-time setup is what keeps the [13-week forecast](https://gravam.com/blog/13-week-cash-flow-forecast) meaningful over years.

## Liquidity item setups that misclassify flows

- **Incomplete Origin X coverage.** FI flows are categorised, TRM/CML/FI-CA flows are not, because nobody defined the Origin `X` queries SAP says have no defaults.
- **Query sequences fighting account defaults.** The account mapping looks right and the result is wrong, because a sequence matched first.
- **Liquidity Planner items existing in only one system.** Actuals arrive with items the central system has never heard of.
- **Hierarchies edited in place.** Restructuring an active hierarchy instead of adding a timeframe, and breaking the current period's reporting to prepare for the next one.
- **Everything in "other."** A catch-all that swallows so much the categorization is meaningless — and no scheduled review to notice.

## What I left out, on purpose

- **The persistence behind liquidity items.** SAP documents the released CDS views (`I_LiquidityItem`, `I_LiquidityItemText`); the physical tables of the derivation configuration are not documented anywhere I could verify, so no table names are printed here.
- **Field-level query definitions.** Which document fields are available to a derivation query varies by release and by the structures active in your system; a field list copied from one release is a liability in another.
- **The Manage Liquidity Item Hierarchies app ID.** SAP's page for it documents the app without printing an app ID, so it appears above without one rather than with a guess.

Design the liquidity item structure to match how the business actually thinks about its cash, get the Origin coverage complete across both FI documents and hub data, and maintain the rules as the business changes — and the forecast becomes the structured, trustworthy, _explainable_ view it's meant to be. Liquidity items are small config with outsized consequence: they're the meaning layer over the amounts.

***

_See also [One Exposure from Operations & FQM_FLOW](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), [the SAP Treasury Fiori apps reference](https://gravam.com/blog/sap-treasury-fiori-apps) and [the 13-week cash flow forecast](https://gravam.com/blog/13-week-cash-flow-forecast)._

## Primary sources

Named objects verified against SAP S/4HANA 2025 FPS01 on-premise documentation. Liquidity items require the full scope of Cash and Liquidity Management (business function FIN_FSCM_CLM); SAP states they are not supported in the basic cash management capability. IMG paths are an on-premise/private-edition concern.

- SAP Help — Liquidity Items and Liquidity Item Hierarchies (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/dd0e6156c4b61e58e10000000a4450e5.html
- SAP Help — Business Function: Cash and Liquidity Management (FIN_FSCM_CLM) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c7999f525c5b224fe10000000a445394.html
- SAP Help — Managing Liquidity Item Hierarchies (Cash Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/fbb589ce1f3d40e4913aa45c2aa931e1.html
- SAP Help — Manage Liquidity Item Hierarchies (app) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/e8153e9f3c044856a1f990a550afa050.html
- SAP Help — Check Liquidity Item on G/L Account (app F6459) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/05c6682668aa464c966cd0941c365d88.html
- SAP Help — Manage Liquidity Item Transfer (app F6385) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/4c62e3d1af0348ce8af229bfd4f6e279.html
- SAP Help — CDS Views for Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/be968afbde79451abb255fe123b3a17b.html

## Questions this article answers

**Q: What are liquidity items in SAP?**

Liquidity items are a classification of cash-relevant flows by their purpose or nature — for example customer receipts, supplier payments, payroll, tax, or financing. SAP's own definition is that they represent the source and use of cash flows in your company and serve as an import dimension for financial planning and reporting. In SAP Cash Management they let the liquidity forecast be viewed and analyzed by category rather than as undifferentiated amounts. Each flow is assigned a liquidity item through derivation rules, and they roll up into hierarchies for reporting.

**Q: What is liquidity item derivation?**

Liquidity item derivation is the process by which SAP assigns a liquidity item to each cash-relevant flow, based on the attributes of the underlying document or transaction. SAP configures it in two layers: a simple default per G/L account, and — when the logic needs more than the account number — queries and query sequences that read fields of the accounting document. The system tries the assigned query sequences first and falls back to the default liquidity items defined for G/L accounts. Getting derivation right is critical: if the rules are incomplete, flows land unassigned and the forecast loses its analytical value.

**Q: What do the Origin values D, C and X mean in liquidity item derivation?**

Origin is the field that tells a derivation query which structure it runs against. SAP documents three values for it. Origin C applies to accounting-document line items with account type D (customer) or K (supplier). Origin D applies to accounting-document line items with account types other than D or K. Origin X means the derivation logic is executed against the structure of the One Exposure from Operations hub — which is what you use for data integrated from source applications such as Treasury and Risk Management, Consumer and Mortgage Loans or FI-CA, and for classic Cash Management data integrated from remote systems.

**Q: Why do liquidity items matter for the cash forecast?**

Because a forecast of undifferentiated amounts is nearly useless for decisions — treasury needs to know what the cash is: which inflows are customer collections versus financing, which outflows are payroll versus supplier payments versus tax. Liquidity items provide that categorization, so the forecast can be analyzed, trusted and acted on. They turn the liquidity forecast from a single number into a structured view of the drivers behind it, which is where its real value lives.

---

# Bank Communication Management (BCM) in SAP

Source: https://gravam.com/blog/bank-communication-management-bcm-sap
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-08-02
Reviewed: 2026-09-26
Summary: SAP Bank Communication Management (BCM) is the controlled gateway between SAP and the banks for payments — batching, approval workflow, signatures, monitoring.

**SAP Bank Communication Management (BCM) is the controlled gateway between SAP and the banks for payments — batching them, routing them through approval workflows, applying digital signatures, releasing them to the connectivity channel that carries them to the bank, and monitoring their status.** The framing that matters: BCM is a _control_ as much as a technical bridge, and the transmission itself belongs to the [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), not to BCM. Payments are money leaving the company, and BCM is where the discipline on that lives — who approves, at what level, with what authorization, tracked through to settlement. Teams that treat it as "the thing that sends the file to the bank" under-build the part that actually matters. The connectivity is the easy half; the control is the point.

## What it is

Payments originate in SAP — from [payment runs](https://gravam.com/blog/what-is-a-payment-factory), treasury settlements, and elsewhere — but they shouldn't flow straight to the bank unchecked. BCM sits in between: it takes those payments and manages them through a controlled release before they leave — and in a centralised landscape, an orchestration hub like [Advanced Payment Management](https://gravam.com/blog/sap-advanced-payment-management-apm) sits upstream, deciding what flows into that gate. It's the gate between "SAP created a payment" and "the bank received it," and everything that gate should do — batch, approve, authorize, release, track — is BCM's job.

## What it does

- **Batching** — groups payments together for controlled, efficient processing rather than a scatter of individual releases.
- **Approval workflow** — routes payment batches for approval, typically multi-level and often driven by amount, so larger payments need higher or additional sign-off.
- **Digital signatures** — secure authorization of the release.
- **Release to the bank** — hands the approved batch to the [connectivity channel](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics), which is what actually transmits it. The file it releases was shaped upstream by the payment medium — a [DMEE format tree](https://gravam.com/blog/sap-dmee-payment-file-format-tree) in most landscapes.
- **Status monitoring** — tracks payments via the acknowledgements and status messages coming back, so you know what actually happened.

> **Figure — SAP Bank Communication Management as the gate between SAP and the bank**
>
> Payments from SAP enter BCM, drawn as a gate with four steps — batch, approve, sign and release. An arrow labelled channel carries the released batch to the bank, and an arrow labelled status comes back from the bank to BCM.
>
> BCM is the gate, not the wire — it batches, approves, signs and releases; the connectivity channel transmits; the bank's status comes back to be watched.

## The approval workflow is the heart of it

BCM's approval workflow is [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) applied to payments: the person who creates a payment must not be the one who approves and releases it, and larger amounts warrant more scrutiny. It is the control standing between the company and an unauthorized or erroneous payment going out, and it has its own guide — [the SAP payment approval workflow](https://gravam.com/blog/sap-payment-approval-workflow) covers dual control on bank data, the F110 proposal-versus-run separation, the batch grouping rules, the BNK_INI and BNK_COM release steps, signatures, the rules exempted from approval and the Fiori apps. This page stays with BCM as the product: what it does, the monitoring that closes the loop, and where it sits in the landscape.

## Status monitoring closes the loop

Sending a payment isn't the end — you need to know it _arrived and settled_. BCM's status monitoring tracks payments through the acknowledgements and status responses from the bank (the [ISO 20022 status side](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), pain.002 and friends), so a rejected or stuck payment is _seen_ rather than assumed successful. Without it, a payment that failed at the bank looks identical to one that worked — until someone chases the missing money. It's the same [monitor-don't-assume](https://gravam.com/blog/interface-monitoring-and-reconciliation) discipline every treasury interface needs.

## Where it fits

BCM is the payments-out gateway in the SAP treasury landscape — downstream of where payments are generated, including [In-House Cash](https://gravam.com/blog/sap-in-house-cash-ihc) payments made on behalf of subsidiaries, and upstream of the banks. It works alongside the [connectivity](https://gravam.com/blog/treasury-bank-connectivity-swift-host-to-host-api-ebics) channels — in many SAP landscapes [SAP Multi-Bank Connectivity](https://gravam.com/blog/sap-multi-bank-connectivity), which carries the released file to the bank without changing it — and the [payment formats](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and it's what turns a centralized [payment factory](https://gravam.com/blog/what-is-a-payment-factory) ambition into a controlled reality inside SAP. It's also a natural [straight-through-processing](https://gravam.com/blog/straight-through-processing-in-treasury) point — the controls live _in the workflow_, so they don't have to become manual breaks.

The approval workflow is also the answer to a newer question. When the payment request comes from an AI step rather than a person, [can an AI agent approve its own payment?](https://gravam.com/blog/can-an-ai-agent-approve-its-own-payment) is settled here, in the release strategy — and [four-eyes and segregation of duties for AI agents](https://gravam.com/blog/four-eyes-and-segregation-of-duties-for-ai-agents) is the same control reasoned forward onto a caller that never goes home.

## Where BCM payment controls fall short

- **Under-designed approval.** Weak or single-level approval with no amount tiers, so the central payment control is thin.
- **No status monitoring.** Payments sent and assumed settled, so failures surface late as missing money.
- **Bypasses "for urgent payments."** An escape hatch around the workflow that quietly becomes the fraud path.
- **Treating it as pure connectivity.** Building the bank bridge and neglecting the approval and control side — its actual purpose.

Design BCM around the _control_ — a real multi-level approval workflow matching your payment policy, secure authorization, and status monitoring that closes the loop — and it becomes the trustworthy gateway for every payment leaving the company. Get the connectivity working and neglect the controls, and you've built a very efficient way to send the wrong payment. In BCM, the workflow _is_ the product. For where BCM sits relative to output management and a central hub, see the [BCM, APM and output-management boundaries](https://gravam.com/blog/sap-bcm-apm-output-management-architecture).

***

_See also [segregation of duties in treasury systems](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) and [ISO 20022 payments](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002)._

## Primary sources

SAP S/4HANA — verify against your release and edition; behaviour and available apps/tools differ across releases and between on-premise and Cloud.

- SAP Help — Bank Communication Management (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/95a8510ebc24461f87c65d2eb3c62288.html
- SAP Help — Bank Communication Management: Purpose and Features (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/3f7ad0531d8b4208e10000000a174cb4.html
- SAP Help — Approve Payments (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/517ad0531d8b4208e10000000a174cb4.html
- SAP Help — Batch and Payment Monitor (SAP S/4HANA) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/457ad0531d8b4208e10000000a174cb4.html
- SAP Help — Outbound Message Processing (Connector for SAP Multi-Bank Connectivity) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/c4dee5cb8c574aadbbfe66dd1c073d56.html

## Questions this article answers

**Q: What is SAP Bank Communication Management (BCM)?**

SAP Bank Communication Management (BCM) is the component that controls and centralizes a company's outgoing payments and bank communication within SAP. It groups payments into batches, routes them through approval workflows, applies digital signatures, releases the approved batch to the connectivity channel, and monitors its status through to the bank. Transmitting the file itself is the connectivity channel's job, not BCM's. In effect BCM is the controlled gateway between SAP and the banking system for payments — as much a control mechanism as a technical bridge.

**Q: What does BCM do in the payment process?**

BCM takes payments generated in SAP and manages them through a controlled release process before they reach the bank: it batches payments together, applies approval workflows (often multi-level, based on amount or other criteria), applies digital signatures for authorization, releases the approved batch to the connectivity channel that transmits it to the bank, and then monitors its status via the acknowledgements and status messages that come back. It provides the visibility and control between 'payment created' and 'payment settled at the bank.'

**Q: Why is BCM a control and not just connectivity?**

Because payments are money leaving the company, and BCM is where the controls on that live — approval workflows enforce that the right people authorize payments, often at multiple levels by amount, and digital signatures provide secure authorization. This is segregation of duties applied to payments: the person who creates a payment isn't the one who approves and releases it. Treating BCM purely as a technical bridge to the bank, and under-designing the approval and control side, misses its most important job.

---

# SAP Cash Management in S/4HANA

Source: https://gravam.com/blog/sap-cash-management-s4hana
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-03
Reviewed: 2026-09-26
Summary: SAP Cash Management in S/4HANA — business function FIN_FSCM_CLM, the three areas, the Fiori apps, the IMG spine and the One Exposure data layer, verified.

**SAP Cash Management in S/4HANA is the redesigned solution for cash and liquidity — three areas: Bank Relationship Management (the part most of us still call Bank Account Management), Cash Operations (the daily position), and Liquidity Management (the forecast) — built on One Exposure from Operations, database table `FQM_FLOW`, as its single source of cash-relevant data.** The word that matters is _redesigned_. If you're coming from classic Cash Management in ECC, do not assume your muscle memory transfers: the concepts survive, but the data model, the tools and most of the configuration are new. I've watched more than one project treat the S/4HANA move as a technical upgrade and then discover, in testing, that it's a re-implementation wearing an upgrade's clothes.

This page is the map. Like the [treasury tables](https://gravam.com/blog/sap-treasury-tables) and [transaction codes](https://gravam.com/blog/sap-treasury-transaction-codes) references it sits beside, every object named below — business function, app ID, IMG node, flow type, table, workflow task — is checked against SAP's own documentation, and anything I couldn't verify there is named in the exclusions at the end rather than quietly included.

## First question: which scope are you licensed for?

Before the three areas, the fork that decides half the design. SAP ships cash management in **two scopes**, and they are not a marketing distinction — they are a Customizing setting plus a business function.

| Object | Value |
| --- | --- |
| Business function | `FIN_FSCM_CLM` — "Cash and Liquidity Management" |
| Type | Enterprise Business Function |
| Application component | FIN-FSCM-CLM |
| Available from | SAP S/4HANA, on-premise edition 1511 |
| Customizing activity | **Define Basic Settings** → Cash Management Scope = _Basic_ or _Full Scope_ |
| Related component for banking | FIN-FSCM-BNK ([Bank Communication Management](https://gravam.com/blog/bank-communication-management-bcm-sap)) |

**Basic cash management** ships with S/4HANA. It gives you banks and house banks (a subset of fields), bank accounts and house bank accounts (common attributes only), a list view of accounts, import/export, IDoc replication, cash position and liquidity forecast monitoring, and memo records through the app or transactions FF63/FF65. SAP names the supported apps explicitly, and adds one sentence that has cost projects real money when it was discovered late: **"liquidity item is not supported in the basic cash management capability."** If your forecast design depends on [liquidity items](https://gravam.com/blog/liquidity-items-in-sap-cash-management), you are not in basic scope, whatever the budget says.

**Full scope** — SAP S/4HANA Finance for cash management — needs `FIN_FSCM_CLM` switched on _and_ Full Scope selected in Define Basic Settings. It adds bank account workflow, dual control and two-person verification, payment approvers and overdraft limits, bank fee import and monitoring, bank account review, cash pools and cash concentration, liquidity item derivation, liquidity planning, and powers of attorney for banking transactions. SAP's own caution deserves repeating verbatim in your design document: activating a business function **cannot be reversed in a live system**.

## The three areas

| SAP's area | The question it answers | Where it lives here |
| --- | --- | --- |
| **Bank Relationship Management** | _Which accounts do we have, and who can act on them?_ | [Bank Account Management](https://gravam.com/blog/sap-bank-account-management-s4hana), [rationalization](https://gravam.com/blog/bank-account-rationalization), [eBAM](https://gravam.com/blog/electronic-bank-account-management-ebam) |
| **Cash Operations** | _How much cash do we have today?_ | [The daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position), [bank statements](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) |
| **Liquidity Management** | _How much will we have, and when?_ | [The liquidity forecast](https://gravam.com/blog/13-week-cash-flow-forecast), [planning levels](https://gravam.com/blog/planning-levels-and-groups-in-sap) |

Three questions, three parts. Keep them straight and the module stops feeling like a maze. One naming note worth absorbing: SAP's current documentation calls the master-data area **Bank Relationship Management**, with Bank Account Management as the process inside it. Consultants (me included) still say BAM. Both are right; only one of them is what you type into the help portal's search box.

## The working apps

The Fiori app IDs below come from the [Fiori apps reference](https://gravam.com/blog/sap-treasury-fiori-apps), where each one was verified against SAP's app library, and the classic codes from the [transaction codes reference](https://gravam.com/blog/sap-treasury-transaction-codes). This is the day-one launchpad for a cash team:

| Area | Fiori app (ID) | Classic counterpart |
| --- | --- | --- |
| Cash Operations | Cash Flow Analyzer (F2332) | FF7AN / FF7BN territory |
| Cash Operations | Cash Position (F1737) | FF7A → FF7AN |
| Liquidity Management | Liquidity Forecast (F0512A) | FF7B → FF7BN |
| Cash Operations | Short-Term Cash Positioning (F5380) | — (no classic equivalent) |
| Cash Operations | Check Cash Flow Items (F0735) | — (the data audit behind the position) |
| Cash Operations | Manage Memo Records (F2986 / F2986A) | FF63 / FF65 |
| Cash Operations | Make Bank Transfers (F0691) | — |
| Cash Operations | Manage Cash Concentration (F3265) | FF73 |
| Bank Relationship Mgt | Manage Bank Accounts (F1366A) | — (this is where the process lives) |
| Bank Relationship Mgt | Manage Bank Accounts – Hierarchy (F1366) | — |
| Bank Relationship Mgt | Manage Banks – Cash Management (F1574A) | successor to F1574 (deprecated) |
| Bank Relationship Mgt | Manage Banks – Master Data (F6437) | — |
| Bank statements | Manage Bank Statements (F1564) | FF67 |
| Bank statements | Manage Incoming Payment Files (F1680) | FF.5 |
| Bank statements | Reprocess Bank Statement Items (F1520) | FEBA_BANK_STATEMENT |
| Bank statements | Bank Statement Monitor (F6388) | — (no classic equivalent) |
| Payments | Approve Bank Payments (F0673A) | BNK_APP |

If you build one launchpad tile group and no more, build the Cash Flow Analyzer one: SAP keeps extending F2332 as the integration point for the newer cash functions, and it carries cash position, liquidity forecast and actual cash flows in a single app.

## The configuration spine

This is the part the overview articles skip, and the part a consultant actually needs. Almost all of it hangs off one IMG branch — **Financial Supply Chain Management → Cash and Liquidity Management → Cash Management** — and it is worth memorising as a spine rather than as a list:

| IMG node (under Cash Management) | What you configure there |
| --- | --- |
| Planning Levels and Planning Groups | The certainty classifier — [levels on G/L accounts, groups on partners](https://gravam.com/blog/planning-levels-and-groups-in-sap) |
| Liquidity Items | Edit Liquidity Items, default items per G/L account, and the [derivation queries](https://gravam.com/blog/liquidity-items-in-sap-cash-management) |
| Flow Types | Assign Flow Types to G/L Accounts — the exception path into One Exposure |
| Data Setup | Source application activation, Define Runtime Parameters for Flow Builder, Define Source Application Accounting |
| Tools | Import and Export Liquidity Items (for keeping remote and central systems in step) |

Two named activities inside Data Setup earn their own line, because they are the ones people search for by symptom rather than by name: **Activate Individual Source Applications** and **Activate Multiple Source Applications**. Until a company code's source applications are activated, that company code's flows are simply not in cash management — and the symptom is a forecast that is right for eight company codes and empty for the ninth.

## The data layer: One Exposure, Flow Builder, FQM_FLOW

The foundation under all three areas is the **One Exposure from Operations** hub — the single store of cash-relevant flows in table `FQM_FLOW` that S/4HANA Cash Management reads from. This guide only places the named objects around it. The walkthrough — what feeds the store, how flow types and certainty levels separate forecast from actual, what liquidity items do and which apps read the result — is [cash forecasting in S/4HANA end to end](https://gravam.com/blog/sap-s4hana-cash-forecasting); the store itself has [its own article](https://gravam.com/blog/one-exposure-from-operations-fqm-flow); and when the numbers do not tie, [the reconciliation walk](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting) is the method.

| Object | What it is |
| --- | --- |
| `FQM_FLOW` | One Exposure from Operations — the flow store cash management consumes |
| `FDES` | The classic memo record table, documented as no longer holding memo records |
| `FCLM_MIGR_FDES2FQM` | SAP's migration report moving existing memo records from FDES into FQM_FLOW |
| `FDSB` | Classic Cash Management's summary balance table, still reconcilable against FQM_FLOW |
| **Flow Builder** / **Flow Builder Plus** | The programs that derive cash-relevant flows from FI and MM into One Exposure |
| `FCLM_FLOWBUILDER_JOB` | The background job definition that lets the Flow Builder run automatically |

The Flow Builder distinction is the one to get right early, because SAP states it as a one-way door: Flow Builder Plus is enabled by activating **"Optimized data model and algorithm"** in Define Basic Settings, and once activated, _it is not possible to switch back to Flow Builder_. That belongs in the same paragraph of your design document as the business function warning, for the same reason.

Flow types are how One Exposure knows what a flow _is_. SAP predefines them and publishes the derivation for accounting-document items down to the G/L account fields that decide "cash" from "cash in transit"; the documented list and the field-level classification behind it are in the [planning levels and groups](https://gravam.com/blog/planning-levels-and-groups-in-sap) reference, so they are not repeated here. When a flow does not appear in the position and the reconciliation walk runs dry, that field list is the next place to look.

## Bank Account Management, and the governance objects under it

**BAM** manages bank accounts as master data — every account, its attributes, its signatories — with review and, in full scope, workflow-driven opening, closing and change processes. It's the SAP home for the [account-inventory and governance](https://gravam.com/blog/bank-account-rationalization) discipline every treasury needs: one controlled record of every account and who can act on it — the more so when [In-House Cash](https://gravam.com/blog/sap-in-house-cash-ihc) replaces external accounts with internal ones, leaving fewer to govern in the first place.

Two attributes are mandatory on every bank account, and confusing them is a standing design error: the **account type** says what business operation the account is for and you define it yourself; the **contract type** says what the contractual relationship with the provider is, is predefined by SAP, and forms part of the logical key that uniquely identifies a bank account. Each account type is assigned to one contract type; a contract type can carry many account types.

The workflow objects, for when someone asks "who approves what, and where is that configured":

| Object | Name / meaning |
| --- | --- |
| BOR object `FCLM_CR` | Bank account change request, with events CREATED and PROCESSED |
| Workflow scenario 78500050 | The default bank account management workflow |
| Standard task 78500044 | `FCLM_APPR` — the approval step in scenario 78500050 |
| Workflow template 74300043 | The older predefined template |
| Standard task 74300047 | its decision step |
| Rule 74300006 | `FCLM_CASHMGR` — assigns a cash manager as agent |
| Rule 74300007 | `FCLM_CASHOPER` — assigns a cash specialist as agent |
| Rule 74300008 | `FCLM_CASHSYSCOLL` — assigns a key user as agent |
| Rule 74300013 | `FCLM_REVWOR` — fixed rule; pulls the internal contact persons from the account master |

Account lifecycle status codes are equally concrete — Inactive (01), Withdrawn (99), Application Approved (22), Pre-Opening Preparation (24) among them — and they matter because "inactive bank accounts cannot be used in business operations" is the answer to a support ticket you will otherwise spend an afternoon on.

## The cloud read path: released CDS views

Table access is an on-premise and private-edition concern. In S/4HANA Cloud you get released **CDS views** instead, and SAP publishes the list — which makes it the sanctioned read path for reporting and for SAP Analytics Cloud, exactly as `FTI_TR_*` is on the [treasury side](https://gravam.com/blog/sap-treasury-tables):

| CDS view | What it exposes | DataSource |
| --- | --- | --- |
| `I_LiquidityItem` / `I_LiquidityItemText` | Liquidity item master and its texts | — |
| `I_LiquidityPositionCube` | Cash position and liquidity forecast cube | ILPCUBE |
| `C_LiquidityPositionQuery` | The query on top of that cube | CLPOSQ |
| `I_BankAccountAnalysisCube` / `C_BankAcctAnalysisQuery` | Bank account analysis | 2CCBKACCTANLYSQ |
| `I_PaymentByBankCube` / `C_PaymentByBankQuery` | Bank payments | 2CCPAYBYBANKQRY |
| `I_BankGroupLiquidityStatusCube` / `C_BankGroupLiquidityQuery` | Financial status by bank group | 2CCBANKGROUPLSQ |
| `I_BankGroupBankFeeCube` / `C_BankGroupBankFeeQuery` | Bank fees by bank group | 2CCBANKGROUPBFQ |

One precision on that last column, because SAP prints two of them and they are not interchangeable: `ILPCUBE` and `CLPOSQ` are extractor DataSources, while the `2C*` names are the DataSources for use in SAP Analytics Cloud and other analytical clients. The pattern otherwise holds throughout: an `I_*` cube or dimension view, a `C_*` query view on top of it. If you're being asked to "just read the table" in a cloud system, this table is the polite answer.

## What changed from classic

For those of us who cut our teeth on classic Cash Management, the honest map of what's different:

- **The data model.** Classic maintained its own summary records, updated as documents posted. S/4HANA reads from One Exposure instead — a genuinely different foundation, not a reskin.
- **The tools.** Much of the classic transaction-driven work moves to Fiori apps; the table above maps which app replaces which transaction.
- **The organization.** Reorganized into the three areas above, with the master-data half renamed Bank Relationship Management.
- **The scope decision.** Classic had no equivalent of the basic/full split, and the split is now a licence conversation with an irreversible switch in it.

The concepts a treasurer cares about — position, forecast, account control — all carry over. What changes is everything underneath, which is exactly why "we're just upgrading Cash Management" is the sentence that sinks the plan. The [ECC-to-S/4HANA article](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana) covers which of your existing reads survive.

## What I left out, on purpose

- **The physical tables behind the apps, beyond the ones SAP names.** `FQM_FLOW`, `FDES`, `FDSB`, `FCLM_BAM_AMD` and the `FEB*` bank-statement ring are documented and are in the [tables reference](https://gravam.com/blog/sap-treasury-tables). The rest of the cash-management persistence layer is not documented anywhere I could verify, so it isn't here.
- **Fiori app IDs I couldn't pin.** Several apps in this area (Manage Cash Pools, Monitor Bank Account Balances, Manage Liquidity Item Hierarchies among them) have SAP Help pages that document the app without printing an app ID. They're real and they're named above where relevant, but no ID is inferred for them.
- **Cloud Public Edition scope items and release dates.** Availability differs by edition and release, and a scope-item number stated from memory is exactly the kind of detail that ages badly. Check your own release notes.
- **Liquidity planning with SAP Analytics Cloud.** A different product boundary, so it has its own article: [SAP S/4HANA cash forecasting, end to end](https://gravam.com/blog/sap-s4hana-cash-forecasting) covers where SAC takes over from the apps and how to measure the result.

## Where this guide goes next

This is the map; the next articles walk the territory — starting with [One Exposure from Operations and `FQM_FLOW`](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), because until that clicks, everything else in S/4HANA Cash Management feels arbitrary. Then Flow Builder, [liquidity items and derivation](https://gravam.com/blog/liquidity-items-in-sap-cash-management), [planning levels](https://gravam.com/blog/planning-levels-and-groups-in-sap), and the bank-statement and BCM side. When a number won't tie, the [FQM_FLOW reconciliation & troubleshooting guide](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting) is the method; and for scoping a whole implementation, the [module-selection roadmap](https://gravam.com/blog/sap-treasury-implementation-roadmap-and-module-selection) sequences it.

***

_See also [what is SAP Treasury and Risk Management](https://gravam.com/blog/what-is-sap-treasury-and-risk-management) and [building a daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position)._

## Primary sources

Named objects verified against SAP S/4HANA 2025 FPS01 on-premise documentation. Transaction codes and IMG paths are on-premise/private-edition concerns; SAP S/4HANA Cloud Public Edition gives you the apps and the released CDS views, not the GUI transactions or the SPRO tree. Basic scope and full scope differ — check which one you are licensed for before designing.

- SAP Help — Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/e7d3a052c3ad224fe10000000a445394.html
- SAP Help — Business Function: Cash and Liquidity Management (FIN_FSCM_CLM) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c7999f525c5b224fe10000000a445394.html
- SAP Help — Planning Levels and Planning Groups (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/12106156c4b61e58e10000000a4450e5.html
- SAP Help — Liquidity Items and Liquidity Item Hierarchies (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/dd0e6156c4b61e58e10000000a4450e5.html
- SAP Help — Flow Types (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/a00d6156c4b61e58e10000000a4450e5.html
- SAP Help — Customize the Flow Builder (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/08fc676e23aa4a7ab038c2e435209506.html
- SAP Help — Source Applications (Configuration for One Exposure from Operations) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/810c6156c4b61e58e10000000a4450e5.html
- SAP Help — Predefined Workflows (Approval Processes for Bank Account Management) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/33b96156bcb6d354e10000000a441470.html
- SAP Help — Bank Account Statuses (Bank Relationship Management) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/c0a95feb9940461a8c2d67f0cb18141d.html
- SAP Help — Bank Account Types and Contract Types (Bank Relationship Management) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/43c3d462dbfe4df99d54058c47f31515.html
- SAP Help — CDS Views for Cash and Liquidity Management (SAP S/4HANA) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/be968afbde79451abb255fe123b3a17b.html
- SAP Help — Set Up Cash Management Data (SAP S/4HANA, One Exposure) — accessed 2026-09-03 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/1ab55956b967c841e10000000a44147b.html

## Questions this article answers

**Q: What is SAP Cash Management in S/4HANA?**

SAP Cash Management in S/4HANA is the redesigned solution for managing a company's cash and liquidity within SAP. It has three main areas: Bank Relationship Management (bank accounts and signatories as governed master data, the part most people still call Bank Account Management), Cash Operations (the daily cash position and short-term cash management), and Liquidity Management (the liquidity forecast over the medium and longer term). It's a ground-up redesign of the classic Cash Management that ran in SAP ERP/ECC, and it's built on the One Exposure from Operations hub — database table FQM_FLOW — as its single source of cash-relevant data.

**Q: How is S/4HANA Cash Management different from classic Cash Management?**

S/4HANA Cash Management is a redesign rather than an upgrade. The classic solution in SAP ERP/ECC maintained its own summary records that were updated as documents posted, and was driven largely through classic transactions. S/4HANA rebuilds this around the One Exposure from Operations hub as a single source of cash-relevant flows, delivers the functionality largely through Fiori apps, and reorganizes it into Bank Relationship Management, Cash Operations and Liquidity Management. The concepts carry over, but the data model, the tools and much of the configuration are new.

**Q: What is the difference between basic and full scope in SAP S/4HANA cash management?**

SAP ships two licensed scopes. Basic cash management comes with SAP S/4HANA and is selected as Basic Scope in the Customizing activity Define Basic Settings; it covers banks, house banks, bank accounts, memo records, cash position and liquidity forecast monitoring, and SAP states explicitly that liquidity item is not supported in it. Full scope is SAP S/4HANA Finance for cash management, switched on with business function FIN_FSCM_CLM and Full Scope in the same Customizing activity; it adds bank account workflow, dual control and two-person verification, bank fee monitoring, cash pools and cash concentration, liquidity item derivation, liquidity planning and powers of attorney. SAP warns that a business function activation cannot be reversed in a live system.

**Q: How does Bank Account Management fit into S/4HANA Cash Management?**

Bank Account Management (BAM) is the part of S/4HANA Cash Management that manages a company's bank accounts as master data — the accounts, their attributes, and signatories — with, in the full scope, account reviews and workflow-based opening, closing and change processes. SAP's current documentation files it under Bank Relationship Management. It gives treasury a single governed record of every bank account, which is the SAP counterpart to the account-inventory and governance discipline any treasury needs regardless of system.

---

# One Exposure from Operations & FQM_FLOW Explained

Source: https://gravam.com/blog/one-exposure-from-operations-fqm-flow
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-08-02
Reviewed: 2026-08-19
Summary: One Exposure from Operations is the hub at the centre of S/4HANA Cash Management — a single store (FQM_FLOW) every cash-relevant flow feeds. Why it exists.

**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](https://gravam.com/blog/sap-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](https://gravam.com/blog/treasury-system-of-record) 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 [the S/4HANA cash forecast](https://gravam.com/blog/sap-s4hana-cash-forecasting) read directly. It's the [system-of-record discipline](https://gravam.com/blog/treasury-system-of-record) 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."

> The mental shift from classic: stop thinking "cash management has its _own_ numbers that I reconcile to the documents." Start thinking "there is _one_ store of flows, and the position and forecast are just _views_ of it." Once you hold that model, most One Exposure questions answer themselves — including _where_ to look when a flow is missing or wrong.

## 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](https://gravam.com/blog/what-is-sap-treasury-and-risk-management), loans, manual/memo records, and [bank statement items](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms), 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:

| Source | Reaches `FQM_FLOW` via | Check first when a flow is missing/wrong |
| --- | --- | --- |
| **FI documents** | Flow Builder | Flow Builder; document cash relevance |
| **MM (purchasing) documents** | Flow Builder | Flow Builder; document cash relevance |
| **SD (sales) activity** | Its own source application | The SD → cash integration |
| **Treasury deals (TRM)** | TRM's own integration (forecast) | The TRM → One Exposure integration |
| **Loans** | Loans' own integration (forecast) | The loans integration |
| **Bank statement items** | End-of-day statements: own source app | Statement processing / posting |
| **Manual / memo records** | Memo-record entry | The memo record itself |

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](https://gravam.com/blog/interface-monitoring-and-reconciliation) 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](https://gravam.com/blog/fqm-flow-reconciliation-and-troubleshooting).

## 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](https://gravam.com/blog/how-to-build-a-daily-cash-position) and the forward-looking [liquidity forecast](https://gravam.com/blog/13-week-cash-flow-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.

> **Figure — How sources reach One Exposure from Operations**
>
> Seven sources feed the FQM_FLOW store. Flow Builder carries FI and MM documents; SD, TRM, loans, bank statements and memo records each reach the store through their own integration. Those routes carry each application's own flows — forecast for TRM, loans and SD, actuals for end-of-day statements — and once a deal or statement posts, the resulting FI document is Flow Builder's. The cash position, liquidity forecast and reporting are views of that one store.
>
> Flow Builder owns the FI/MM route; the other applications bring their own. Verify the exact routes for your release against SAP's documentation, since integration details differ by release and edition.

Everything else — [liquidity items](https://gravam.com/blog/liquidity-items-in-sap-cash-management), [planning levels](https://gravam.com/blog/planning-levels-and-groups-in-sap), 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](https://gravam.com/blog/sap-cash-management-s4hana) and [the treasury system of record](https://gravam.com/blog/treasury-system-of-record)._

## Primary sources

SAP S/4HANA — verify against your release/edition; One Exposure behaviour and the initialization/rebuild tools differ across releases and between on-premise and Cloud.

- SAP Help — One Exposure from Operations (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/abd32554225fea6fe10000000a423f68.html
- SAP Help — Flow Builder (Cash and Liquidity Management) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/ee9ee0ca4c3942068ea584d2f929b5b1/835cc0f9ff554154bf06245b70c4c79b.html
- SAP Help — Integration with Source Applications in the Central System — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/83996156f5b61d58e10000000a4450e5.html
- SAP Help — Build Cash Flows from Operations — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/3848ad639f0c4fcaae89467ed9443fb8.html
- SAP Help — Treasury and Risk Management in One Exposure from Operations — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/eb383c57e236d820e10000000a44147b.html
- SAP Help — Cash Flows from End-of-Day Bank Statements — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/0d4605c7e1c644f4b3a4dce4f4571d0f.html
- SAP Help — Flow Builder Plus — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/269afd61815d455a911ff2d58f222e31.html
- SAP Help — End-of-Day Bank Statements in One Exposure from Operations — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/0bddfa562f4fff7de10000000a441470.html
- SAP Help — Intraday Memo Records (Cash and Liquidity Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/06f8351bfac0478d95d94440060c2f45.html

## Questions this article answers

**Q: What is One Exposure from Operations in SAP?**

One Exposure from Operations is the central hub in S/4HANA Cash Management that consolidates all cash-relevant flows into a single store — the table FQM_FLOW. Instead of cash management maintaining its own separate summary records, every cash-relevant flow from across the system lands in this one place, and the cash position, liquidity forecast and reporting all read from it. It's SAP's implementation of a single source of truth for cash: one hub, many sources, one place everything downstream trusts.

**Q: What is FQM_FLOW?**

FQM_FLOW is the database table at the heart of One Exposure from Operations in S/4HANA — it holds the cash-relevant flows that feed cash management. Relevant flows from across the system (financial documents, purchasing, sales, treasury deals, loans, memo records, bank statement items and more) are collected into it, so that the cash position and liquidity forecast are built from one consolidated store rather than from many separate summary records as in classic Cash Management. It is still derived operational data: SAP provides initialization, deletion and rebuild tools precisely because these flows can need regenerating or reconciling when source configuration or postings change.

**Q: What is Flow Builder in SAP Cash Management?**

Flow Builder (and Flow Builder Plus) is the mechanism that generates cash-relevant flows from FI and MM documents and writes them into One Exposure (FQM_FLOW). It is not the single pipe for everything: applications such as Treasury and Risk Management, loans and sales activate as their own source applications and feed their expected flows in directly, and memo records are entered by hand. The distinction that matters is forecast versus posted — those integrations carry the expected flow, but once the underlying deal or statement posts, the resulting FI document is Flow Builder's territory, and SAP's FI flow builder traces the document chain back to the originating source. Knowing which source a flow comes from, and whether you are looking at the expected or the posted version, is what lets you explain or fix a number that looks wrong.

---

# What Is SAP Treasury and Risk Management (TRM)?

Source: https://gravam.com/blog/what-is-sap-treasury-and-risk-management
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-08-02
Reviewed: 2026-09-02
Summary: SAP Treasury and Risk Management (TRM) manages financial transactions and risk: capturing deals, valuing them, measuring risk, and posting to accounting.

**SAP Treasury and Risk Management (TRM) is SAP's module for running a company's financial transactions and the risk that comes with them — capturing and processing deals, valuing them, measuring market and credit risk, and posting it all to accounting.** That's the textbook answer. Here's the one I've earned building and fixing it: TRM is powerful, deeply integrated, and completely unforgiving of anyone who treats it like a third-party TMS you can bolt on and configure later. Its two pillars are the **Transaction Manager**, where the deals live, and the **Analyzers**, where the risk gets measured. Almost everything else in this guide is the stuff the SAP help states in one confident sentence — and a real project then spends three weeks discovering what that sentence actually meant.

## What TRM actually is

Every [treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system) does broadly the same jobs: deals, valuation, risk, accounting. What makes TRM different isn't the _what_, it's the _where_: it lives natively inside SAP, wired straight into FI and the rest of the finance landscape. That's its whole appeal and its whole difficulty in one sentence.

I've seen it done both ways; [SAP TRM vs a standalone TMS](https://gravam.com/blog/sap-trm-vs-standalone-tms) is the decision in full. Bolt a best-of-breed TMS onto SAP and you get a clean tool with an integration seam to maintain forever. Run TRM native and you get no seam — but you inherit SAP's depth, its configuration surface, and its habit of doing exactly what you _configured_, not what you _meant_. What never works is running TRM as if it were that third-party tool: its value is the integration, and so is its cost. Go in expecting a treasury product and you'll be surprised; go in expecting a treasury _module of SAP_ and you'll be right.

## Where it sits

TRM runs inside **SAP S/4HANA** (and, in the landscapes many of us are still [migrating off](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana), SAP ERP/ECC). It doesn't stand alone; it's stitched into:

- **Financial Accounting (FI):** deals and valuations post to the general ledger as [accounting documents split across BKPF and BSEG](https://gravam.com/blog/02-bkpf-bseg-join). This integration is a feature and, at go-live, usually your biggest source of "why did it post _that_?"
- **[Cash Management](https://gravam.com/blog/sap-cash-management-s4hana):** TRM's cash flows feed cash and liquidity (the subject of the next few articles here).
- **[Bank Communication Management (BCM)](https://gravam.com/blog/bank-communication-management-bcm-sap):** payments out and bank connectivity.

## The components, and where the effort actually goes

TRM is a handful of components, but they don't demand equal attention, and no one tells you that up front:

- **[Transaction Manager](https://gravam.com/blog/sap-transaction-manager):** the heart of it. Money market, FX, derivatives, securities, captured and pushed through their whole lifecycle to accounting. You'll spend most of the project here, and most of the _arguments_ here too, usually about how a deal should post.
- **[Market Risk Analyzer](https://gravam.com/blog/sap-market-risk-analyzer):** valuation (NPV and friends) and market-risk measures.
- **[Credit Risk Analyzer](https://gravam.com/blog/sap-credit-risk-analyzer):** counterparty and credit risk, with limit management.
- **[Portfolio Analyzer](https://gravam.com/blog/sap-portfolio-analyzer):** returns and performance.
- **[Hedge Management](https://gravam.com/blog/hedge-management-in-sap):** designating and monitoring hedges. [Hedge accounting](https://gravam.com/blog/hedge-accounting-explained) is a separate, separately documented step — and, if you've read the hedge-accounting piece, the place the real pain hides.

Reference, when you need the object names rather than the story: the [TRM tables](https://gravam.com/blog/sap-treasury-tables), the [transaction codes](https://gravam.com/blog/sap-treasury-transaction-codes), the [Fiori apps](https://gravam.com/blog/sap-treasury-fiori-apps) and the [product and transaction types](https://gravam.com/blog/sap-trm-product-types-and-transaction-types). Around TRM sit [One Exposure](https://gravam.com/blog/one-exposure-from-operations-fqm-flow), [In-House Cash](https://gravam.com/blog/sap-in-house-cash-ihc) and [Advanced Payment Management](https://gravam.com/blog/sap-advanced-payment-management-apm).

The honest split: most implementations live and die in the Transaction Manager and the [accounting and posting architecture](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) behind it. The Analyzers are the risk team's home, and they're powerful, but they're rarely what blows the timeline. When a TRM project is late, look at the postings first.

### SAP Treasury capability map

TRM doesn't stand alone; it sits inside a wider SAP Treasury landscape. This map is the one-screen picture of which component answers which need, the starting point for the [implementation roadmap and module selection](https://gravam.com/blog/sap-treasury-implementation-roadmap-and-module-selection). (If you'd rather work it interactively, the [SAP Treasury Module Selector](https://gravam.com/tools/sap-treasury-module-selector) lets you tick your needs and see which components address them.)

| Capability | Component | Answers the need to… |
| --- | --- | --- |
| **Instruments & accounting** | Transaction Manager (TRM) | Manage and post FX, MM, securities, derivatives |
| **Valuation & market risk** | Market Risk Analyzer | Value positions and measure market risk |
| **Counterparty & credit risk** | Credit Risk Analyzer | Measure and limit counterparty exposure |
| **Return & performance** | Portfolio Analyzer | Analyse returns and performance |
| **Hedging** | Hedge Management | Designate and monitor hedges (hedge accounting is a separate, separately documented step) |
| **Cash visibility & position** | Cash and Liquidity Management (fed by One Exposure) | See the cash position and liquidity forecast |
| **Bank accounts** | Bank Account Management | Manage accounts, payment approvers and powers of attorney centrally |
| **Payment approval & monitoring** | Bank Communication Management | Approve and track outgoing payment batches |
| **Central payment hub** | Advanced Payment Management | Centralise group payments, including payments on behalf of (POBO) |
| **Internal bank** | In-House Cash | Run an internal bank with intercompany current accounts |

The map is functional, not a licence or availability statement: **which components exist, and how they're activated, differs by release and edition**; verify against SAP's documentation for your target system. It describes the on-premise/private-cloud shape, and the gap is wider than a footnote — SAP S/4HANA Cloud Public Edition has no Portfolio Analyzer and no In-House Cash component at all (in-house banking is an embedded capability of Advanced Payment Management there), and it organises what on-premise calls Transaction Manager as Financial Transaction Management plus Treasury Accounting. If your target is public cloud, check the component list before you plan around this map.

## How a deal flows

TRM mirrors the front/middle/back-office separation a real treasury already runs on, which is the point, not an accident:

1. **Capture:** the deal is entered (front office).
2. **Processing / settlement:** checked, confirmed, settled (back office).
3. **Position management:** it feeds positions and exposures.
4. **Valuation and risk:** the Analyzers price it and measure the risk.
5. **Accounting:** the results post to FI.

The concrete day-to-day surface of all this is a set of transaction codes — [the verified reference](https://gravam.com/blog/sap-treasury-transaction-codes) lists what a consultant actually opens, grouped the same way.

That staging is also where [segregation of duties](https://gravam.com/blog/segregation-of-duties-in-treasury-systems) is enforced: the person who strikes the deal is not the person who settles it. Collapse those steps "to save clicks" and a control silently disappears — the kind of gap that surfaces in the first audit, not in testing.

## TRM vs Cash Management: don't conflate them

This trips people up constantly, so let me be blunt: **TRM is transactions and risk; Cash Management is cash and liquidity.** Different modules, different data, different owners. TRM runs the deals; Cash Management runs the [position](https://gravam.com/blog/how-to-build-a-daily-cash-position), the [forecast](https://gravam.com/blog/13-week-cash-flow-forecast) and [bank account management](https://gravam.com/blog/sap-bank-account-management-s4hana), classifying every flow through [liquidity items](https://gravam.com/blog/liquidity-items-in-sap-cash-management) and [planning levels](https://gravam.com/blog/planning-levels-and-groups-in-sap). They integrate tightly (TRM deals throw off the cash flows Cash Management sees) and a full SAP treasury build uses both. But scope them as one thing and you'll under-plan both. The next articles in this guide take the Cash Management side apart, starting with One Exposure from Operations.

## Why I'm writing this guide

TRM rewards people who understand _why_ it behaves the way it does and punishes people who only know _which button_. That is doubly true of anything acting on the system automatically: what an [AI agent leaves on the document](https://gravam.com/blog/ai-agents-in-sap-what-actually-posts) is decided by the posting architecture, not by the assistant. The standard documentation is thorough on the what and nearly silent on the why — so this guide pairs the official behaviour with what actually happens when you switch it on in a live company running a real close. That's the part you can't fake, and it's the part I've spent a career learning the expensive way.

***

_See also [what is a treasury management system](https://gravam.com/blog/what-is-a-treasury-management-system) and [hedge accounting explained](https://gravam.com/blog/hedge-accounting-explained)._

## Primary sources

SAP S/4HANA (documented for on-premise; also available in SAP S/4HANA Cloud with scope differences). Component availability and the TRM/Cash Management split vary by release and edition.

- SAP Help — Treasury and Risk Management (SAP S/4HANA) — accessed 2026-07-26 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/3b3e7e53c4d1cc26e10000000a4450e5.html
- SAP Help — Transaction Manager (SAP S/4HANA) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/f827c753b1081d4be10000000a174cb4.html
- SAP Help — Market Risk Analyzer (SAP S/4HANA) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/8505c753b1081d4be10000000a174cb4.html
- SAP Help — Credit Risk Analyzer (SAP S/4HANA) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/bc08da531198434de10000000a174cb4.html
- SAP Help — Portfolio Analyzer (SAP S/4HANA) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/48055e53ae50e047e10000000a441470.html
- SAP Help — Bank Relationship Management (SAP S/4HANA) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ac319d8fa4ea4624b40a58d23e3c4627/59d5a052c3ad224fe10000000a445394.html
- SAP Help — Advanced Payment Management (SAP S/4HANA) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/e200555127f24878bed8d1481c9d5a0b/2945c7d799ac46f0bdb0267f9fd7a289.html
- SAP Help — In-House Banking (SAP S/4HANA Cloud Public Edition) — accessed 2026-08-01 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/b8e68a90bfff4ff0906d5db5342bdece/3dbe688b4c8840da8567f811be2bc1b4.html
- SAP Help — Hedge Accounting (SAP S/4HANA Treasury and Risk Management) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/ef50e11850884b5a83ef25b0ee992e83.html
- SAP Help — Hedge Management and Accounting of Net Open Exposures (FX Risk) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/104b7358ff3ca107e10000000a441470.html
- SAP Help — Comparison of Hedge Management and Accounting of Net Open Exposures (FX Risk) and Hedge Management of Balance Sheet FX Risk — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/848f8ce21bcd4f67bce77494799e2257/605b6caef795445986c9aeeb2ce929a9.html

## Questions this article answers

**Q: What is SAP Treasury and Risk Management (TRM)?**

SAP Treasury and Risk Management (TRM) is SAP's module for managing a company's financial transactions and the risks attached to them. It captures and processes financial deals (money market, foreign exchange, derivatives and securities), values them, measures market and credit risk, and posts the results to financial accounting. Its main building blocks are the Transaction Manager, which handles the deals through their lifecycle, and a set of Analyzers (Market Risk, Credit Risk and Portfolio) that measure risk and performance.

**Q: What are the main components of SAP TRM?**

The core components are the Transaction Manager (managing financial transactions such as money market, FX, derivatives and securities through capture, processing, position management and accounting) and the Analyzers: the Market Risk Analyzer (valuation and market risk measures), the Credit Risk Analyzer (counterparty and credit risk with limit management), and the Portfolio Analyzer (portfolio returns and performance). Hedge Management supports designating and monitoring hedges; hedge accounting is a separate, separately documented step.

**Q: What is the difference between SAP TRM and SAP Cash Management?**

SAP TRM focuses on financial transactions and risk: the deals a treasury enters into and the market and credit risk they carry. SAP Cash Management focuses on cash and liquidity: bank balances, the cash position, liquidity forecasting and bank account management. They are distinct but closely integrated: TRM deals generate cash flows that feed cash and liquidity, and both sit within the broader SAP treasury and finance landscape. A full SAP treasury implementation typically uses both together.

---

# BKPF BSEG Join: Keys, S/4HANA Changes and ACDOCA

Source: https://gravam.com/blog/02-bkpf-bseg-join
Topic: SAP Treasury & Cash Management — https://gravam.com/topics/sap-treasury
Author: Tan Gravam
Published: 2026-05-13
Updated: 2026-09-25
Reviewed: 2026-09-25
Summary: Join SAP BKPF to BSEG on MANDT, BUKRS, BELNR and GJAHR, sign amounts with SHKZG, why BSEG was a cluster table, and when to read ACDOCA in S/4HANA instead.

**To join BKPF to BSEG, match all four header keys, MANDT, BUKRS, BELNR and GJAHR; BSEG adds BUZEI as the line number, so one header fans out to its line items and nothing else.** `BKPF` is the accounting document header, `BSEG` the accounting document segment (the lines), and that shape is the same in SAP ECC and S/4HANA. What changed is everything around it: in ECC, BSEG was a cluster table that ABAP could not join or aggregate, and in S/4HANA the reporting job moved to `ACDOCA`, the universal journal, while BSEG stayed on as the entry view. This page is the reference for all three: the join, why it used to be awkward, and when to stop using it.

## The tables and their keys

| Table | What it holds | Key | One row per |
| --- | --- | --- | --- |
| `BKPF` | Accounting document header | `MANDT`, `BUKRS`, `BELNR`, `GJAHR` | Document |
| `BSEG` | Accounting document segment: the entry-view line items | `MANDT`, `BUKRS`, `BELNR`, `GJAHR`, `BUZEI` | Document line |
| `ACDOCA` | Universal journal (S/4HANA): the ledger-view line items | `RCLNT`, `RLDNR`, `RBUKRS`, `GJAHR`, `BELNR`, `DOCLN` | Document line **per ledger** |

A document is unique only across all four header fields. Leaving out `BUKRS` or `GJAHR` is the classic mistake: `BELNR` repeats across company codes and fiscal years, so a two-field join silently multiplies rows.

The fields you reach for most:

| Table | Field | Meaning |
| --- | --- | --- |
| BKPF | `BLART` | Document type |
| BKPF | `BUDAT`, `BLDAT` | Posting date, document date |
| BKPF | `XBLNR` | Reference (often the external document number) |
| BKPF | `USNAM` | User who entered the document |
| BSEG | `BUZEI` | Line item number, three digits, so at most 999 lines per document |
| BSEG | `KOART` | Account type: `S` G/L, `D` customer, `K` vendor, `A` asset, `M` material |
| BSEG | `HKONT` | G/L account |
| BSEG | `SHKZG` | Debit/credit indicator: `S` debit, `H` credit |
| BSEG | `DMBTR`, `WRBTR` | Amount in local currency, amount in document currency, both unsigned |
| BSEG | `AUGBL`, `AUGDT` | Clearing document and clearing date |

## The join

Header joined to line items on the full key — illustrative

```sql
SELECT
  h.bukrs,
  h.belnr,
  h.gjahr,
  h.blart,   -- document type
  h.budat,   -- posting date
  l.buzei,   -- line item number
  l.koart,   -- account type
  l.hkont,   -- G/L account
  l.shkzg,   -- debit/credit indicator (S/H)
  l.dmbtr    -- amount in local currency, unsigned
FROM bkpf AS h
JOIN bseg AS l
  ON  l.mandt = h.mandt
  AND l.bukrs = h.bukrs
  AND l.belnr = h.belnr
  AND l.gjahr = h.gjahr
WHERE h.mandt = '100'
  AND h.bukrs = '1000'
  AND h.gjahr = '2026'
ORDER BY h.belnr, l.buzei;
```

This is plain SQL of the kind you would run against a replicated copy or an S/4HANA system. Treat client, company code and year as placeholders.

## Amounts are unsigned: read SHKZG

`DMBTR` and `WRBTR` are always positive. The direction lives in `SHKZG` (`S` = debit, `H` = credit), so summing `DMBTR` directly gives gross turnover, not a net balance.

Signed balance per G/L account — illustrative

```sql
SELECT
  l.hkont,
  SUM(CASE WHEN l.shkzg = 'H' THEN -l.dmbtr ELSE l.dmbtr END) AS net_local
FROM bkpf AS h
JOIN bseg AS l
  ON  l.mandt = h.mandt
  AND l.bukrs = h.bukrs
  AND l.belnr = h.belnr
  AND l.gjahr = h.gjahr
WHERE h.mandt = '100'
  AND h.bukrs = '1000'
  AND h.gjahr = '2026'
GROUP BY l.hkont;
```

## Why BSEG was awkward in ECC: a cluster table

In classic SAP ERP, BSEG is not an ordinary database table. It is a **cluster table**, physically stored inside the table cluster `RFBLG`, which is keyed on the document header fields. The ABAP Keyword Documentation lists what that costs in Open SQL: **no joins** with pooled or cluster tables, **no `GROUP BY` or `HAVING`**, and no column comparisons on the right side of a `WHERE` condition. Both SQL blocks above are therefore impossible as Open SQL on a classic ECC database.

SAP's answer was redundancy. The **secondary index tables** duplicate a subset of BSEG in transparent tables you can join and index: `BSIS`/`BSAS` for G/L items, `BSID`/`BSAD` for customers, `BSIK`/`BSAK` for vendors, with `I` for open and `A` for cleared items. Line-item reports such as FBL3N, FBL5N and FBL1N read those, not BSEG.

The idiomatic ECC pattern in ABAP is header first, lines second, with the full key:

Header first, then lines by full key — illustrative ECC ABAP

```abap
SELECT bukrs, belnr, gjahr, blart, budat
  FROM bkpf
  WHERE bukrs = @lv_bukrs
    AND gjahr = @lv_gjahr
    AND blart = 'SA'
  INTO TABLE @DATA(lt_head).

IF lt_head IS NOT INITIAL.
  SELECT bukrs, belnr, gjahr, buzei, hkont, shkzg, dmbtr
    FROM bseg
    FOR ALL ENTRIES IN @lt_head
    WHERE bukrs = @lt_head-bukrs
      AND belnr = @lt_head-belnr
      AND gjahr = @lt_head-gjahr
    INTO TABLE @DATA(lt_items).
ENDIF.
```

(The inline-declaration syntax needs a recent ABAP release; on an older ECC the same logic uses classic `SELECT ... INTO TABLE` with declared internal tables.)

**ECC on SAP HANA** is the halfway house. Migrating an ERP system to the HANA database declusters its cluster tables into transparent ones as standard, which is why SAP has a knowledge-base article for the cases where some weren't, and a FAQ specifically on converting cluster tables such as BSEG. One practical trap follows: a cluster table returned rows in key order as a side effect, and a declustered one does not. Code that relied on that order needs an explicit `ORDER BY` or a `SORT`.

## What changed in S/4HANA

Two things happened at once. BSEG became a normal transparent table, and ACDOCA took over the ledger.

| Question | ECC | S/4HANA |
| --- | --- | --- |
| Is BSEG a cluster table? | Yes, in RFBLG (unless the database is HANA) | No, a transparent table |
| What does BSEG hold? | All FI line items | The entry view: one row per document line, not per ledger, plus open-item details such as payment terms |
| Where do balances come from? | Totals tables (`GLT0`, `FAGLFLEXT`) and index tables | `ACDOCA`; the old totals and index tables are compatibility views that read it |
| Are amounts signed? | No, use `SHKZG` | In BSEG, still no; in ACDOCA, yes (`HSL` in company code currency, `KSL` in group currency, and further currency fields), with `DRCRK` as the indicator |
| Line limit per document | 999 (`BUZEI`) | 999 in BSEG still; `ACDOCA-DOCLN` has six digits, and BSEG lines can be summarized |
| Multiple ledgers | Separate new-G/L tables | One ACDOCA row per line per ledger, distinguished by `RLDNR` |

SAP's own documentation calls ACDOCA the single source of truth for accounting, and the compatibility views exist so that old code selecting from `BSIS` or `FAGLFLEXT` keeps running. Running is not the same as being the right source: a compatibility view is ACDOCA wearing an old name.

Three consequences matter for anyone reconciling the two. **Line numbers don't map one-to-one**: `DOCLN` is not `BUZEI`, ACDOCA can carry lines that BSEG summarized away, and every extra ledger adds rows. **Some things never reach ACDOCA**: SAP's knowledge base notes that noted items such as down-payment requests live in BSEG only. And **on S/4HANA Cloud public edition you don't read tables at all**: the released CDS views are the interface, with `I_JournalEntry` for the header, `I_JournalEntryItem` for universal-journal items and `I_OperationalAcctgDocItem` for the entry-view items that correspond to BSEG.

> BSEG didn't disappear in S/4HANA; it stopped being the answer to "what's the balance?". Ask ACDOCA that question, and keep BSEG for "what exactly was posted on this document?"

## When to read ACDOCA instead

Use **ACDOCA** (or `I_JournalEntryItem`) for balances, trial balances, P&L and balance-sheet slices, anything by profit centre, segment or cost object, and any question that is really "per ledger". Always restrict the ledger: without `RLDNR`, a company with a leading and a local ledger double-counts.

Signed balance per account from the universal journal — illustrative S/4HANA

```sql
SELECT
  racct,                 -- G/L account
  SUM(hsl) AS net_local  -- already signed, company code currency
FROM acdoca
WHERE rclnt  = '100'
  AND rldnr  = '0L'      -- the ledger you report on
  AND rbukrs = '1000'
  AND gjahr  = '2026'
GROUP BY racct;
```

Keep the **BKPF/BSEG join** for document-level work: an audit trail or a drill-down from a document number, open-item and payment-term detail, clearing analysis, noted items, and tracing what a specific process posted. Tracing what an [electronic bank statement run](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) or a treasury [TBB1 flow posting](https://gravam.com/blog/sap-transaction-manager) actually created is the everyday example.

## Performance guidance

- **Always restrict company code and fiscal year**, and the client if you are outside ABAP. On ACDOCA add the ledger. Most runaway queries on either table are missing one of these.
- **Select the columns you need.** BSEG and ACDOCA are wide; `SELECT *` on ACDOCA pulls hundreds of columns from a column store.
- **ECC on a classic database: never search BSEG by a non-key field.** Go through the index tables or through BKPF, then read BSEG by full key.
- **S/4HANA: aggregate in the database.** A `GROUP BY` on ACDOCA is what the column store is built for; pulling line items into ABAP to sum them is the ECC habit to drop.
- **Don't join `ACDOCA-DOCLN` to `BSEG-BUZEI`** and expect a one-to-one result. Reconcile at document level (company code, document number, year), then compare totals.
- **Sort explicitly.** No former cluster table guarantees order any more.

## Traps worth checking in any report

- A join on `BELNR` alone, or on `BELNR` and `BUKRS` without `GJAHR`: correct in testing, wrong in the first year-end.
- Summing unsigned `DMBTR`: a balance that is really turnover.
- Summing ACDOCA without a ledger filter: every value doubled for each parallel ledger.
- Reconciling ACDOCA line counts to BSEG line counts: summarization and ledgers make them differ by design.

For the treasury view of these tables, where TBB1 postings and the Treasury subledger meet the general ledger, see the [SAP treasury tables reference](https://gravam.com/blog/sap-treasury-tables); for what changes in a conversion, see [migrating SAP treasury from ECC to S/4HANA](https://gravam.com/blog/migrating-sap-treasury-ecc-to-s4hana).

***

_See also [SAP treasury tables](https://gravam.com/blog/sap-treasury-tables), [SAP TRM accounting and posting architecture](https://gravam.com/blog/sap-trm-accounting-and-posting-architecture) and the [SAP Treasury hub](https://gravam.com/topics/sap-treasury)._

## Primary sources

SAP ERP 6.0 (ECC) on any database, including ECC on SAP HANA, and SAP S/4HANA on-premise and private edition. Table and field names are SAP data-dictionary names; the SQL and ABAP blocks are illustrative sketches for reading a replica or an S/4HANA system, not production code, and S/4HANA Cloud public edition exposes the released CDS views rather than the tables. Claims checked on 2026-09-25 through cross-checked excerpts of the listed sources.

- SAP Help — Detection Method: OTA Uses Bank Account of Regular Vendor (BKPF as accounting document header, BSEG as accounting document segment at database level) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/9b03947b033f4432ba0261c94b73ea45/d8a956539a2f4e3fe10000000a441470.html
- SAP Help — JVA on ACDOCA (the universal journal as the single source of truth for accounting) — accessed 2026-08-02 — https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/f049a59301a94f1c9bb60ca8394db217/06421bf5a2ad4af28c8d1f6904a214ec.html
- ABAP Keyword Documentation (7.51) — Restrictions in Pooled Tables and Cluster Tables (no joins, no GROUP BY/HAVING) — accessed 2026-09-25 — https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-us/abenddic_database_tables_poclure.htm
- SAP KBA 1960840 — Not all tables have been declustered/depooled on migration to SoH — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/1960840
- SAP KBA 2769310 — Frequently-asked questions about table conversion on cluster tables such as BSEG — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/2769310
- SAP Community (SAP) — 999: The Number of the BSEG (BUZEI limit, BSEG summarization in S/4HANA) — accessed 2026-09-25 — https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/999-the-number-of-the-bseg/ba-p/13692857
- SAP KBA 3128916 — FI document has 999 limit of line item in S/4HANA? — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3128916
- SAP KBA 3523400 — Overview of the compatibility view topic in the context of SAP HANA (SAP S/4HANA) — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3523400
- SAP KBA 3513673 — CDS view for noted items related to down payment request (noted items in BSEG, not ACDOCA) — accessed 2026-09-25 — https://userapps.support.sap.com/sap/support/knowledge/en/3513673
- SAP Help — CDS Views for General Ledger Accounting (SAP S/4HANA) — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/0fa84c9d9c634132b7c4abb9ffdd8f06/ca03bbfc892d4474be69934d6f5c783d.html
- SAP Help — Accounting Document Item: Operational View — accessed 2026-09-25 — https://help.sap.com/docs/SAP_S4HANA_CLOUD/c0c54048d35849128be8e872df5bea6d/f585d657f8a28a3de10000000a441470.html

## Questions this article answers

**Q: Which fields join BKPF to BSEG in SAP FI?**

All four together: MANDT (client), BUKRS (company code), BELNR (document number) and GJAHR (fiscal year). BELNR is only unique within a company code and fiscal year, so a join on document number alone fans out across every company code and year that reuses it. BSEG's own key adds BUZEI, the line item number, which is why one BKPF row joins to many BSEG rows.

**Q: Why can't I just sum DMBTR to get an account balance?**

DMBTR is stored as a positive number; the debit or credit direction is in SHKZG, where S is debit and H is credit. Summing DMBTR gives gross turnover, not a balance. Flip the sign for H rows, for example SUM(CASE WHEN shkzg = 'H' THEN -dmbtr ELSE dmbtr END). ACDOCA avoids the problem because its amount fields such as HSL are already signed.

**Q: Is BSEG still used in S/4HANA?**

Yes. BSEG still exists in S/4HANA as a transparent table rather than a cluster table, and it still holds the entry view of each accounting document, one row per document line, along with open-item details such as payment terms. The ledger view lives in ACDOCA, the universal journal, which holds one row per line per ledger and is the source for balances and reporting. The old index and totals tables such as BSIS and FAGLFLEXT survive only as compatibility views.

**Q: Should I join BKPF and BSEG or read ACDOCA on S/4HANA?**

Read ACDOCA, or its released CDS views, for balances, ledger-specific values and anything that needs controlling or profitability fields, filtering on the ledger. Keep the BKPF/BSEG join for document-level work: audit trails, drill-downs from a document number, open-item and payment-term detail, and noted items such as down-payment requests, which sit in BSEG but not in ACDOCA.

---

# Operational Readiness & Acceptance for Finance Systems

Source: https://gravam.com/blog/operational-readiness-and-acceptance
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Passing go-live isn't being ready to run. How to prove operational readiness — support, monitoring, runbooks, ownership — and get acceptance before handover.

**A system can pass go-live and still not be ready to run — because "does it work?" and "can we operate it?" are different questions with different owners.** Projects pour effort into building and cutting over, then treat the moment of go-live as the finish line. It isn't. The finish line is when the run organisation can support the thing day after day — fix what breaks, monitor what matters, own each interface, close each period — without the project team in the room. Operational readiness is whether that's true; operational acceptance is the run team formally agreeing it is. Skip these and you get the classic post-go-live disaster: a "successful" launch, followed by an operations team discovering on day two that they own a system nobody prepared them to run.

## Go-live readiness and operational readiness are not the same gate

This is the distinction that gets collapsed, and the collapse is expensive. [Cutover go/no-go](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) asks: **is it safe to switch on?** (there is a [go/no-go checklist](https://gravam.com/tools/cutover-go-live-checklist) for that gate) — data migrated, critical processes tested, a fallback ready. Operational readiness asks a different question: **can we live with this, day after day?** — is there a support model, are there runbooks, is it monitored, does someone own each interface?

A project can pass the first gate and fail the second completely. The system is live, the data's clean, the payment run works — and there's no defined support path, no monitoring, no named owner for the bank interface that'll fail at the first month-end. Go-live succeeded; the operation is a disaster waiting for day two. **Two questions, two gates, two owners** — and operational acceptance belongs to the people who'll run it, not the project that built it.

## The operational readiness checklist

Readiness is provable, not assumable. Each item is evidenced — "we have monitoring" means alerts exist and someone receives them, not that monitoring is theoretically possible.

- [ ] **Support model defined** — levels, priorities, and who owns what (including the interfaces, not just the app).
- [ ] **Runbooks written** — routine operations _and_ the exception procedures (a failed interface, a stuck payment, a period that won't close).
- [ ] **Monitoring & alerting live** — on the system and every integration, with a named recipient for each alert.
- [ ] **Owners named** — for the system and each interface; "the team owns it" means no one does.
- [ ] **Knowledge transfer complete** — the run team has been walked through it and can operate it, evidenced by them doing it, not attending a session.
- [ ] **Operational access & roles provisioned** — the run team can actually do their job on day one.
- [ ] **Hypercare plan agreed** — who's on standby, for how long, and how issues escalate during [stabilisation](https://gravam.com/blog/hypercare-and-post-go-live-stabilization).
- [ ] **Acceptance criteria agreed** — what "operationally accepted" means, defined _before_ the run team is asked to sign.

> "We have monitoring" is a claim; an alert firing to a named person who knows what to do is readiness. Evidence every item, because the ones taken on trust are exactly the ones that aren't real.

## Operational acceptance: the run team signs, not the project

The gate has to be owned by the people who inherit the system. Operational acceptance is the **run organisation** formally agreeing it can support and operate what's being handed over — against the criteria agreed up front. This matters because the incentives diverge at go-live: the project wants to declare success and roll off; operations wants to not be handed a liability. A real acceptance gate protects operations from inheriting a system it can't run, and protects the project from the accusation that it walked away — because the handover is a signed, criteria-based agreement, not an assumption.

The failure mode when this gate is missing: the project declares victory at go-live, the team disperses, and operations discovers the gaps alone, in production, with no one left who knows the design. Operational acceptance is the forcing function that makes the project close the gaps _before_ it leaves.

## Where this sits relative to hypercare

Operational readiness is what you prove _before_ go-live; [hypercare](https://gravam.com/blog/hypercare-and-post-go-live-stabilization) is the staffed stabilisation period _after_ it. They're complementary, not alternatives: readiness ensures the run team _can_ operate the system; hypercare is the safety net while they get fluent and the last defects surface. A common mistake is using hypercare to _substitute_ for readiness — "we'll figure out support during hypercare" — which just means the stabilisation period is spent building the operational basics that should have existed at go-live, while real incidents pile up unaddressed.

## How operations inherit an unready system

- **Go-live treated as the finish.** The project declares success at switch-on and disperses, leaving operations to discover the gaps.
- **No support model.** Nobody's defined who fixes what, so the first incident becomes a scramble to find an owner.
- **Interfaces unowned and unmonitored.** The app is watched; the integrations that actually break aren't.
- **Knowledge transfer as a slide deck.** A session held, not competence built — so the run team "accepted" a system they can't actually operate.
- **Acceptance criteria invented at handover.** No agreed definition of ready, so acceptance is a rushed signature under go-live pressure, not a real gate.

## Separating go-live from operational acceptance

Separate the two gates explicitly and give operational acceptance to the run team, with criteria agreed at the _start_ of the project, not the end. Evidence every readiness item — an alert that fires, a runbook that's been followed, a run-team member who's done the task — because the items taken on trust are the ones that fail on day two. And never let hypercare become a substitute for readiness: hypercare is the net for the last defects and the learning curve, not the time to build the support model you skipped. Going live is switching the system on; being ready is being able to run it after everyone who built it has gone home. Readiness means something additional when part of the system is a model — the data an answer depends on has to be reachable and current, not merely clean — which is one of [the three steps that change when you sequence an AI programme](https://gravam.com/blog/where-to-start-with-enterprise-ai).

***

_See also [cutover & go-live for finance systems](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) and [hypercare and post-go-live stabilization](https://gravam.com/blog/hypercare-and-post-go-live-stabilization)._

## Questions this article answers

**Q: What is operational readiness?**

Operational readiness is whether the organisation can actually run and support a system once it's live — as distinct from whether the system passed its build and cutover. It covers the support model (who fixes what, at what priority), runbooks and operational procedures, monitoring and alerting, named owners for the system and its interfaces, knowledge transfer from the project to the run team, and access and roles for day-to-day operation. A system can pass every test and go live cleanly and still not be operationally ready — because nobody's defined who supports it, how it's monitored, or what to do when an interface fails at month-end.

**Q: What is the difference between go-live and operational acceptance?**

Go-live is the moment the system starts being used in production; operational acceptance is the run organisation formally agreeing it can support and operate it. They're different gates with different owners: go/no-go asks 'is it safe to switch on?'; operational acceptance asks 'can we live with this day after day?' A project can be desperate to go live and the operations team entirely unready to run it — no support model, no runbooks, no monitoring. Separating the two gates stops a project declaring victory at go-live and walking away, leaving operations to discover on day two that they own something they were never prepared for.

**Q: What should an operational readiness checklist include?**

The essentials: a defined support model (levels, priorities, who owns what), runbooks for routine and exception operations, monitoring and alerting on the system and its interfaces, named owners for the system and each integration, completed knowledge transfer from the project team to the run team, operational access and roles provisioned, and a hypercare plan for the stabilisation period after go-live. Each item should be evidenced, not assumed — 'we have monitoring' means the alerts exist and someone receives them, not that monitoring is theoretically possible. The checklist gates operational acceptance: unmet items are either fixed or explicitly accepted as risks before the run team signs.

---

# Decision Log & Change Control for Finance Systems

Source: https://gravam.com/blog/decision-log-and-change-control
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Finance-system projects fail on forgotten decisions and uncontrolled change. Running a decision log and change control: choices traceable, changes deliberate.

**Two things quietly sink finance-system projects: decisions nobody recorded, and changes nobody controlled.** Not dramatic failures — slow ones. A posting design agreed in week six, questioned in week twenty by someone who wasn't there, relitigated for a day because no one can say why it was chosen. A "small" scope tweak slipped in during UAT that unravels three earlier decisions nobody re-checked. Individually trivial; collectively, they're how a project drifts from what was agreed into something no one quite decided. A decision log and change control are the unglamorous disciplines that prevent both — and they're the first things dropped when a project gets busy, which is exactly when they matter most.

## Decisions are the project's real output

A finance-system project produces a working system, but along the way it produces something just as valuable and far more perishable: **decisions**. How each deal type posts. Which system owns which data. What's in scope and what's explicitly out. Every one is a choice with a reason, and the reason is the part that evaporates.

The failure is predictable: three months on, someone asks "why does it work this way?" — and the answer lives only in the memory of whoever's since rolled off the project. So the decision gets relitigated (expensive) or quietly reversed by someone who didn't know it was deliberate (dangerous). A [decision log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) fixes this by making the reason a record, not a memory.

## The decision log: what each entry needs

A decision log is only useful if each entry captures enough to answer "why" without the person who decided it. The fields that earn their place:

| Field | Why it matters |
| --- | --- |
| **Decision** | What was actually decided, in one clear sentence |
| **Date** | When — so you can tie it to the state of the project then |
| **Owner / decider** | Who made it — accountability, and who to ask |
| **Context / why** | The reason and the constraints at the time |
| **Alternatives rejected** | What was considered and _not_ chosen, and why |
| **Impact / affects** | What else depends on this decision |

The field everyone skips is **alternatives rejected** — and it's the one that stops relitigation. "We chose A" invites "but what about B?"; "We chose A over B because B couldn't handle multi-currency" ends the conversation. Recording the rejected option records the _thinking_, which is the whole point.

> The decision log's job is to make "why does it work this way?" a lookup instead of an argument. A project that can't answer that question is one bad week from reversing a decision it made for good reasons it forgot.

## Change control: make change deliberate, not accidental

Change control is the twin discipline. Once something is **baselined** — scope, a design decision, a requirement — changing it should be a conscious, owned act, not a quiet tweak. The path is simple and non-negotiable:

1. **Raise.** The proposed change is written down — what and why.
2. **Assess impact.** Cost, time, risk, and _which other decisions it touches_ — the step that catches the "small change" that isn't.
3. **Decide.** Someone with authority approves or rejects it, deliberately.
4. **Record.** The outcome becomes a decision-log entry, so the change is now part of the traceable history.

The purpose isn't to _resist_ change — finance-system projects must change as they learn. It's to make sure no change is silent. The most damaging changes aren't the big ones everyone debates; they're the "obvious" small ones slipped in without impact assessment, each unravelling something nobody re-checked.

## The two connect: a change becomes a decision

Decision log and change control aren't separate systems — they're one traceable history with a gate. Everyday design decisions go straight into the log. Changes to _already-baselined_ items go through change control first, and then the outcome lands in the log. Together they answer the two questions that stall projects and audits:

- **"Why is it like this?"** → the decision log.
- **"Who approved changing it, and did they understand the impact?"** → change control.

This is the delivery-side twin of [environment config promotion](https://gravam.com/blog/finance-systems-environment-strategy): there, you control how _config_ moves; here, you control how _decisions and scope_ move. Same principle — deliberate change over convenient change — applied to the choices instead of the system.

## How decision logs and change control decay

- **Decisions in chat.** The real decision log is a scattered trail of messages and meeting notes nobody can search, so "why" is unanswerable.
- **No rejected-alternatives.** Only the chosen option recorded, so every past decision is re-openable by anyone who wasn't there.
- **Silent scope creep.** "Small" changes made directly, without impact assessment, until the system no longer matches what was signed off.
- **Change control as bureaucracy.** A heavy process nobody uses, so change routes around it entirely — worse than no process, because it's ignored _and_ resented.
- **Dropped when busy.** Both disciplines abandoned exactly when the project is moving fast and making the most decisions — the worst possible time to stop recording them.

## Keeping the log and the change gate light

Keep both lightweight enough to actually use. A decision log is a single searchable table with the fields above — not a document management system; the moment it's heavier than the decisions it records, it stops being used. Change control is one gate — raise, assess impact, decide, record — applied only to _baselined_ items, so it governs the changes that matter without slowing the everyday ones. And treat "alternatives rejected" and "impact assessed" as the two non-negotiable fields, because they're what turn a log from a list into a defence and a change from a tweak into a decision. Projects don't fail because they made bad decisions; they fail because they forgot the good ones and changed them by accident.

***

_See also [the RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) (and the [RAID log template](https://gravam.com/tools/raid-log-template) if you need one now) and [governance and steering for finance programmes](https://gravam.com/blog/governance-and-steering-for-finance-programmes)._

## Questions this article answers

**Q: What is a decision log in a project?**

A decision log is the running record of the significant choices a project makes — what was decided, when, by whom, why, and what alternatives were rejected. It exists because finance-system projects make hundreds of consequential decisions (a posting design, a scope call, a data rule) and, without a record, the reasons evaporate. Three months later someone asks 'why does it work this way?' and nobody remembers — so the decision gets relitigated, or worse, quietly reversed by someone who didn't know it was deliberate. The log turns decisions from tribal memory into traceable record: the answer to 'why' is a lookup, not an argument.

**Q: What is change control on a project?**

Change control is the discipline of making changes to agreed scope, design or plan deliberate rather than accidental. Once something is baselined — scope, a design decision, a requirement — a change to it goes through a defined path: raised, assessed for impact (cost, time, risk, other decisions), decided by someone with authority, and recorded. The point isn't to prevent change; projects must change. The point is that every change is a conscious, owned decision with its impact understood — not a quiet tweak that unravels three other things nobody re-checked. Change control is what stops 'small' changes accumulating into a project that no longer matches what was agreed.

**Q: What is the difference between a decision log and a change request?**

A decision log records decisions as they're made throughout the project; a change request is the mechanism for altering something already agreed. They're linked: a change request, once decided, becomes an entry in the decision log. Think of the decision log as the full history of what was chosen and why, and change control as the gate that governs changes to previously-agreed items. A project needs both — the log so choices are traceable, and change control so changes to baselined work are deliberate and impact-assessed rather than silent.

---

# Test Data Management for Finance-System Projects

Source: https://gravam.com/blog/test-data-management
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: Tests are only as good as their data. How to build test data for a finance-system rollout — representative volume, edge cases, anonymization, golden datasets.

**A finance system can pass every test and still fail in production — because the tests ran on data that never challenged them.** Test data is the most under-designed part of most testing efforts. Teams write careful test cases, then run them against whatever data was convenient: a thin synthetic set that never hits an edge, or a raw production copy nobody understands well enough to know what "correct" looks like. Either way, the tests prove less than they appear to. Good [UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) and a defensible [go/no-go](https://gravam.com/blog/defect-triage-and-exit-criteria) both rest on the same foundation: data that actually exercises the system. This is how to build it.

## The two failures of bad test data

Almost every test-data problem is one of these:

- **Too clean.** Synthetic data that's tidy, small and happy-path. The system passes because nothing in the data was hard — no odd counterparty name, no payment volume that breaks a batch window, no opening balance that doesn't tie. Then production supplies all of that on day one.
- **Too raw.** A full production copy dropped into a test environment: realistic, yes, but nobody knows what the _right_ answer is for any given record, so a test can only confirm "it ran," not "it ran correctly." And it's usually sensitive data sitting where it shouldn't.

The target is the middle: **realistic enough to be hard, known enough to be checkable, safe enough to exist in a lower environment.**

## What good test data actually contains

Design the data as deliberately as the test cases. A working finance-system test dataset spans several types, each earning its place:

| Data type | Purpose |
| --- | --- |
| **Representative volume** | Find performance and batch-window problems real scale causes |
| **Master data** | Realistic accounts, counterparties, banks, mappings |
| **Opening balances** | So positions and reconciliations have a true starting point |
| **Normal transactions** | The happy path — the bulk of processing |
| **Edge cases** | Boundary values, unusual-but-valid records |
| **Negative scenarios** | Deliberately broken input, to prove the system rejects it |
| **Time-spanning data** | Period boundaries, value-date effects, cut-offs |

The two rows people skip are the two that catch the most: **edge cases** and **negative scenarios**. Random data almost never contains them, and they're precisely where finance systems break — the payment that's a cent over a limit, the statement item in a currency you don't handle, the date that lands on the wrong side of a period close.

> Representative _volume_ finds the problems scale causes. Curated _scenarios_ find the problems logic causes. A dataset with one and not the other tests half the system and hides the other half.

## The golden dataset: known data, known answers

The single highest-leverage test-data practice is a **golden dataset**: a curated, version-controlled baseline whose _expected results are also known_. Run a test against it and you don't just see an output — you see it against a defined "correct."

What a golden dataset buys you:

- **Repeatability.** Reset to the golden baseline, re-run, get the same result. A test you can't repeat is an anecdote, not evidence.
- **Regression safety.** A change that alters a golden result is caught the moment it happens — the foundation of trusting that a fix didn't break something else.
- **Checkability.** Every result has a known-correct to compare against, so "it ran" becomes "it ran correctly."

Build it once, curate it deliberately (normal + edge + negative + real opening balances), version it alongside the code and config, and it becomes the backbone every test run stands on.

## Anonymization: realistic without the risk

Production-derived data is the fastest route to realism and the fastest route to a data-protection incident. The rule is simple: **any production data used for testing is masked or anonymized before it leaves production.** Keep the structure, volume and messiness; remove the real bank details, counterparties and amounts.

This is the data-side of the broader [environment strategy](https://gravam.com/blog/finance-systems-environment-strategy) — who may copy production data, how it's masked, and where it may land is an owned decision, not an ad-hoc extract. Two workable models:

- **Masked production extract** — real structure and volume, sensitive values replaced. Best for finding real-world mess.
- **Synthetic golden data** — fully invented, no exposure, but you must deliberately build in the edge cases production would have supplied.

Most teams use both: masked bulk for volume and realism, a synthetic golden set for the scenarios they specifically want to prove.

## Repeatability: the property everything depends on

A test is only evidence if you can run it again and trust the result. That requires test data you can **reset to a known state** — otherwise each run starts from wherever the last one left it, results drift, and "the test passed" stops meaning anything. Build the reset in from the start: a defined baseline, a way to restore it, and the discipline that tests run from it rather than from accumulated residue. Repeatability is what turns a pile of test runs into a body of evidence you can put in front of a go-live decision.

## What good looks like

- **Data is designed, not scavenged** — chosen to be hard, checkable and safe.
- **Edge cases and negative scenarios are explicitly curated**, not left to chance.
- **A version-controlled golden dataset with known answers** underpins repeatable, regression-safe testing.
- **Production-derived data is masked before it leaves production**, by decision and owner.
- **The baseline is resettable**, so every test run is repeatable evidence.

Teams pour effort into test cases and starve the data those cases run on — then wonder why a thoroughly-tested system still surprises them in production. Invest in the data as much as the cases: representative, edge-covering, anonymized, golden and repeatable. Do it and your test results become evidence you can stake a go-live on. Skip it and you'll have a green test report describing a system nobody actually tested hard.

***

_See also [user acceptance testing for finance systems](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) and [finance systems environment strategy](https://gravam.com/blog/finance-systems-environment-strategy)._

## Questions this article answers

**Q: What is test data management?**

Test data management is the deliberate design, creation and maintenance of the data your tests run on — so that testing actually proves the system works, not just that it works on convenient data. It covers representative volume and structure (so you find the problems real data causes), curated edge cases and negative scenarios (so you test what breaks, not only the happy path), anonymization of any production-derived data (so testing doesn't create a data-protection exposure), and a repeatable, resettable baseline (so a test can be re-run and its result trusted). Bad test data is the quiet reason a well-tested system still fails in production: the tests passed because the data never challenged them.

**Q: What is a golden dataset in testing?**

A golden dataset is a known, curated, version-controlled set of test data whose expected results are also known — so running a test against it produces an answer you can check against a defined 'correct.' It's the opposite of testing on a random production copy where nobody knows what the right output should be. A golden dataset makes tests repeatable (reset to it and re-run) and regression-safe (a change that alters a golden result is caught immediately). For finance systems it typically includes representative master data, opening balances, and a spread of transactions covering the normal, the edge and the deliberately broken.

**Q: Should test data be anonymized?**

Any test data derived from production should be masked or anonymized before it leaves the production environment, because finance data is sensitive — bank details, counterparties, payment amounts — and copying it into lower environments in the clear creates a security and data-protection exposure. The goal is to keep the realistic structure, volume and messiness that make testing meaningful while removing the real sensitive values. Fully synthetic data avoids the exposure entirely but often misses real-world edge cases; a masked production extract plus curated synthetic edge cases is the common, pragmatic middle.

---

# Finance Systems Environment Strategy: Dev to Prod

Source: https://gravam.com/blog/finance-systems-environment-strategy
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: How to design the environment landscape for a finance-system rollout — Dev to Prod — what data lives where, how config is promoted, and who owns each gate.

**A finance-system rollout doesn't fail in Production — it fails because Production was the first place something was ever really tested.** The environment landscape is the least glamorous decision on a programme and one of the most consequential: get it right and every change earns its way to live through controlled gates, so go-live is boring. Get it wrong — config hand-keyed differently in each environment, tests run on data that looks nothing like reality, no production-like rehearsal — and the [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) becomes the first honest test of the whole system, at the worst possible moment. This is how to design the landscape so it doesn't.

## Each environment has one job

The trap is thinking of environments as copies of each other. They're not — they're stages with distinct purposes, and the design work is deciding what each is _for_ and what lives in it.

| Environment | Purpose | Data | Integrations | Config | Owner |
| --- | --- | --- | --- | --- | --- |
| **Development** | Build & configure | Minimal, synthetic | Stubbed / mocked | Authored here | Build team |
| **Test** | Verify changes technically | Curated test data + known scenarios | Test endpoints of key integrations | Promoted from Dev | QA / test lead |
| **UAT** | Business validates against real scenarios | Masked production-like data | Test/simulated bank & system connections | Promoted from Test | Business owner |
| **Pre-Prod** | Dress rehearsal, performance, cutover practice | Full masked prod-like volume | Production-like (as close as safely possible) | Promoted, frozen | Cutover lead |
| **Production** | Live operation | Real | Live bank & system connections | Promoted, change-controlled | Service owner |

Two design decisions carry most of the value:

- **Integration realism climbs the chain.** Dev stubs integrations; Pre-Prod gets as close to real bank and system connections as is safe. The riskiest part of a finance system is where it touches banks and other systems — so the environment _before_ Production must exercise those connections, not simulate them away.
- **Data realism climbs too — but never becomes real too early.** Test data is curated and known; UAT and Pre-Prod use masked production-like data so validation meets real-world mess; only Production holds real sensitive values.

## Config promotion: one direction, owned gates

The single most damaging environment mistake is **changing configuration directly in a higher environment** — a "quick fix" in UAT, a tweak straight in Production. The moment you do, what you tested is no longer what's live, and every downstream assumption is void.

The discipline is simple to state and hard to hold:

- **Config is authored in Development** and **promoted forward** — transported or deployed — through each environment in one direction.
- **No changes in higher environments.** If UAT needs a fix, it's made in Dev and promoted up. Painful in the moment, decisive over the programme.
- **Each promotion is an owned gate.** Someone approves that a change is ready to move up — not a free-for-all, not automatic.

> What you test is exactly what you promote, and what you promote is exactly what goes live. Break that chain once — a fix keyed straight into Production — and every test you ran is now evidence about a system that no longer exists.

This is the environment counterpart to [change management](https://gravam.com/blog/change-management-for-finance-system-rollouts): the org side manages people through change; the environment side manages _config_ through change, with the same insistence on control over convenience.

## Production data in lower environments: the decision to own

Realistic data is how testing finds what invented data can't — the counterparty with the odd name, the payment volume that breaks a batch window, the opening balance that doesn't tie. But production finance data is sensitive, and copying it down the chain wholesale is a data-protection incident waiting to happen. Make it an **explicit, owned decision**, not an ad-hoc extract:

- **Mask or anonymise** by default: representative structure and volume, without the real bank details, counterparties and amounts.
- **Curate known scenarios** alongside the masked bulk — the edge cases, negative paths and opening balances you _want_ to test, which random data won't contain. Representative volume finds performance problems; curated scenarios find logic ones. You need both — building and maintaining that set is [test data management](https://gravam.com/blog/test-data-management) in its own right.
- **Name who may copy production data, how it's masked, and where it may land.** No unmasked production extract reaches a lower environment without an owner and a reason.

## Common failure modes

- **Config keyed per environment.** Hand-maintained config that drifts, so Production behaves like nothing you tested. The root cause of a startling share of go-live surprises.
- **No production-like environment.** UAT sat on stubbed integrations, so the first real bank connection is attempted in Production during cutover.
- **Real data everywhere.** Unmasked production data copied into open lower environments — a breach with a delay on it.
- **Too many environments, none owned.** A sprawl of environments nobody's accountable for, so state is unknown and refreshes are chaos.
- **UAT as a second system test.** The business "validates" by re-running technical checks instead of real end-to-end scenarios, so genuine business defects surface after go-live.

## What good looks like

- **Each environment has one purpose, one data profile, one owner** — and you can say, for any environment, what's real and what isn't.
- **Config flows one way through owned gates**, so what's live is exactly what was tested.
- **Integration realism peaks in Pre-Prod**, where the cutover is rehearsed against production-like connections before it's run for real.
- **Production data is masked by decision, not by luck**, with a named owner for every copy.

The environment strategy is invisible when it works and catastrophic when it doesn't — which is exactly why it's worth designing deliberately at the _start_ of a programme, not assembling under pressure before UAT. Get the landscape right and every change earns its way to live through gates that caught the problems early. Leave it to improvisation and the [reasons implementations fail](https://gravam.com/blog/why-tms-implementations-fail) will find you at cutover, where they cost the most to fix.

***

_See also [cutover & go-live for finance systems](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) and [change management for finance-system rollouts](https://gravam.com/blog/change-management-for-finance-system-rollouts)._

## Questions this article answers

**Q: What environments do you need for a finance-system implementation?**

Typically a chain of Development, Test, UAT, Pre-Production and Production — though the exact number depends on the platform and the risk. Development is where configuration and build happen; Test is where the team verifies changes technically; UAT is where the business validates against real scenarios; Pre-Production is a production-like environment for dress rehearsals, performance and cutover practice; Production is live. The point isn't the count — it's that each environment has a distinct purpose, a defined data and integration profile, and a clear owner, so a change earns its way up the chain one controlled promotion at a time.

**Q: How should configuration be promoted between environments?**

In one direction, through a controlled, repeatable process — never by re-keying config by hand in each environment. Configuration is built in Development and transported or deployed forward through the chain, so what's tested is exactly what goes live. The two disciplines that make this work are a strict no-changes-in-higher-environments rule (you don't 'quick fix' config directly in UAT or Production) and an owned promotion gate at each step, where someone approves that a change is ready to move up. Config that's hand-maintained per environment guarantees that Production behaves differently from everything you tested.

**Q: Should you use production data in test environments?**

Only with care, and usually masked. Realistic data makes testing meaningful — edge cases, volumes and messy real-world records that invented data never reproduces — but production finance data is sensitive (bank details, counterparties, payments), so copying it wholesale into lower environments creates a data-protection and security exposure. The common answer is masked or anonymised production data: representative structure and volume without the real sensitive values, plus a curated set of known scenarios and opening balances. Whatever the approach, who may copy production data, how it's masked, and where it may land must be an owned, explicit decision — not an ad-hoc extract.

---

# Defect Triage & Exit Criteria for Finance Go-Lives

Source: https://gravam.com/blog/defect-triage-and-exit-criteria
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-28
Reviewed: 2026-07-28
Summary: How to run defect triage on a finance-system project: severity vs priority, blockers, accepted defects and workarounds, and the exit criteria that gate go-live.

**Every finance go-live comes down to one honest question asked under pressure: are the defects that are still open acceptable to run the business on?** By the final week, the backlog is never empty — real projects go live with known defects. What separates a controlled go-live from a gamble is whether those defects were _triaged_ (understood, classified, owned) and whether the decision to proceed was made against _exit criteria_ agreed in advance, rather than against fatigue and hope. This is how to run both — so the go/no-go is a check against evidence, not a vote on optimism.

## Severity and priority are two different questions

The most common triage mistake is treating "how bad" and "how soon" as one dial. They're independent axes, and keeping them separate is what stops teams fixing trivia urgently while deferring something that should have blocked go-live.

- **Severity** = impact if it occurs. Does it produce a wrong number? Break a process? Fail a control?
- **Priority** = how soon it must be fixed, relative to everything else competing for the same days.

A cosmetic error on a high-traffic screen: low severity, high priority (it's embarrassing and everyone sees it). A wrong calculation in a rare edge case: high severity, lower priority (fix it, but maybe not before an event that can't occur for weeks). Triage sets _both_, on purpose.

| Severity ↓ / Priority → | Fix now | Fix before go-live | Fix after go-live |
| --- | --- | --- | --- |
| **Critical** (wrong number / broken process / control fail) | Blocker — stop and fix | Blocker — gates go-live | Only with an _accepted_ workaround |
| **Major** (significant but contained) | If quick and safe | Usually yes | With owner + plan |
| **Minor** (cosmetic / rare / easily worked around) | Rarely | If cheap | Default home |

The grid isn't the point — the _conversation_ it forces is. Every open defect gets placed on it deliberately, with the business in the room, so nothing drifts into go-live unexamined.

## Blockers: defined in advance, non-negotiable at the end

A **blocker** is a defect that makes go-live unacceptable no matter what else works. Define the category _before_ testing, agreed with the business owner, so it can't be argued away at 11pm on cutover eve. The reliable tests:

- It produces a **wrong financial number** with no workaround.
- It **breaks a critical process end-to-end** — a payment can't be made, a bank statement can't be posted, a period can't close.
- It causes a **control or compliance failure**.

> The question a blocker answers is never "is this annoying?" It's "can the business operate correctly and safely with this live?" If the answer is no, it's a blocker — and one open blocker is a no-go, however green everything else looks.

This is exactly the hard gate in the [cutover go/no-go decision](https://gravam.com/blog/cutover-and-go-live-for-finance-systems): blockers gate absolutely, and a passed gate still isn't a "go" until someone with authority decides. The [go-live readiness checklist](https://gravam.com/tools/cutover-go-live-checklist) makes that separation concrete.

## Accepted defects and workarounds: the honest middle

Real go-lives carry open defects across the line — and that's fine, _if it's done honestly_. An **accepted defect** is one the business has consciously agreed to live with, for now, with three things attached:

1. **An assessed impact** — what it does, how often, to whom. Not "minor," but a real description.
2. **A workaround** — the manual or interim step that makes it survivable — _tested_, not assumed, and owned by someone who'll actually do it.
3. **A fix plan and owner** — when it gets resolved and who's accountable, so "accepted" doesn't quietly become "forgotten."

The failure mode isn't going live with open defects — it's going live with defects nobody _decided_ to accept. A defect you chose to carry, with eyes open and a workaround in hand, is managed risk. The same defect discovered live, with no plan, is an incident. An accepted defect with real business impact belongs on the programme's [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) as well as in the test tool, so steering sees the risk it signed for.

## Exit criteria: agree them before you need them

**Exit criteria** are the conditions that must be true to complete a test phase or proceed to go-live — and their power comes entirely from being set _in advance_. Agreed at the end, under pressure, they're just a renegotiation of optimism. A workable set:

- [ ] **No open blockers or critical defects.** (The absolute gate.)
- [ ] Every remaining open defect has an **owner, an assessed impact, and either a fix plan or an explicitly accepted workaround**.
- [ ] **Critical business processes have passed end-to-end** — not component checks, real scenarios (the point of proper [UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems)).
- [ ] **Defect trend is under control** — the open count is falling and inflow has slowed, not a backlog still growing.
- [ ] **The business owner has signed off** against this evidence.

Watch two signals that a project is drifting toward a bad go-live even when the headline numbers look fine:

- **Defect ageing.** Old open defects that never move are usually the hard ones being avoided — the backlog's true risk hides in its oldest entries, not its newest.
- **Reclassification pressure.** Blockers quietly downgraded to "major" as the date approaches. When severity starts falling without the defect changing, the deadline is driving the triage — exactly backwards.

## What good looks like

- **Severity and priority set separately** on every defect, with the business, against a shared grid.
- **Blockers defined up front** and treated as an absolute gate — no end-of-project reclassification.
- **Open defects are _decided_, not just present** — each with impact, a tested workaround, and an owner.
- **Exit criteria agreed before testing starts**, so go/no-go is a check against evidence.
- **Ageing and reclassification watched** as the early-warning signals they are.

Do this and go-live becomes a defensible decision you can put your name to: here's what's open, here's why it's acceptable, here's who owns what's left. Skip it and the decision gets made anyway — by the calendar, on the night, with the hardest defects quietly reclassified so the date can hold. Triage and exit criteria are how you make the honest call instead of the convenient one. Running intake and defect decisions across a programme is exactly the kind of queue [Delivery Sheet](https://gravam.com/products/delivery-sheet) is built to keep straight.

***

_See also [user acceptance testing for finance systems](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) and [cutover & go-live for finance systems](https://gravam.com/blog/cutover-and-go-live-for-finance-systems)._

## Questions this article answers

**Q: What is the difference between defect severity and priority?**

Severity is how bad the defect is if it happens — its impact on the business or the numbers. Priority is how soon it must be fixed relative to everything else. They're independent: a cosmetic label error on a screen thousands of people see might be low severity but high priority; a wrong calculation in an obscure edge case might be high severity but lower priority if it rarely occurs before a later fix. Triage sets both, deliberately, because conflating them is how teams either fix trivia urgently or defer something that should have blocked go-live. Severity describes the defect; priority describes the plan.

**Q: What counts as a go-live blocker?**

A blocker is a defect that makes go-live unacceptable regardless of how much else works — typically anything that produces a wrong financial number with no workaround, breaks a critical process end-to-end (a payment can't be made, a statement can't be posted), or creates a control or compliance failure. The test is not 'is it annoying' but 'can the business operate correctly and safely with this live?' Blockers are defined in advance, agreed with the business owner, and they gate the decision absolutely: an open blocker means no-go, however good the rest of the picture looks.

**Q: What are exit criteria for testing and go-live?**

Exit criteria are the agreed conditions that must be true to declare a test phase complete or to proceed to go-live — set before testing starts, not negotiated under pressure at the end. They typically cover: no open blockers or critical defects; every remaining open defect has an owner, an assessed impact and either a fix plan or an explicitly accepted workaround; critical business processes have passed end-to-end; and the business owner has signed off. Good exit criteria turn go/no-go from an argument about optimism into a check against evidence.

---

# Solution Design and Blueprint for Finance Systems

Source: https://gravam.com/blog/solution-design-and-blueprint-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: How to turn agreed requirements into a signed solution design before build starts — and why skipping the blueprint is what quietly buys you months of rework.

**Solution design is where a finance-systems project decides _how_ the solution will actually work — and the blueprint is where that decision gets written down and signed before anyone builds it.** Requirements told you what the business needs. [Fit-gap analysis](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) told you where the standard system covers it and where the gaps are. Design is the next step: it takes those answers and turns them into a concrete, agreed target that build and test can both work from. Skip it, or do it badly, and you don't save the time — you just move it to UAT and pay interest on it.

## Where design sits

By the time you get here, two things should be settled. You know _what_ is needed, because you [wrote the requirements](https://gravam.com/blog/how-to-write-good-requirements-for-finance-systems) properly. And you know _where the standard falls short_, because fit-gap classified every requirement as fit, gap, or change-the-process. What you don't yet have is the _how_.

Design is the _how_. It's the stage that decides, concretely:

- **The target process design** — how the future-state process will actually run, end to end, once the system is live. Not "we do month-end close," but the specific sequence of steps, who does what, and where the system fits into it.
- **The configuration design** — how the standard system will be set up to meet the fits: the settings, the structures, the rules.
- **The integration and interface design** — what data flows in and out, from and to which systems, in what shape, on what trigger, and what happens when a flow fails.
- **The data and reporting design** — the data model, the master data, and the reports, extracts and controls the business will actually rely on.

All of it lands in one place: a design document, or blueprint. That document is the deliverable of this stage — not a working system, a _described_ one.

## Every decision has to trace both ways

The discipline that makes a design worth signing is traceability. Every design decision should trace _backward_ to a requirement — so you can point at any configured behaviour and say which agreed need it exists to satisfy. And every requirement should trace _forward_ into the design and then into [test cases](https://gravam.com/blog/testing-strategy-for-finance-systems) — so you can prove nothing agreed got quietly dropped.

That two-way trace protects you from the two failure modes that cost the most. Without the backward trace, you build things no one asked for. Without the forward trace, you miss things people did ask for, because they fell between two workstreams and no one noticed until go-live. A design that traces both ways is boring in the best way: nothing surprising is in it, and nothing agreed is missing from it.

Design is also where the config-versus-custom calls get made concrete. Fit-gap decided _whether_ a gap warrants building; design decides _how_ — and that's the moment to be honest about [configuration versus customization](https://gravam.com/blog/configuration-vs-customization-finance-systems), because the design is where a "small custom tweak" either gets scoped properly or gets waved through to haunt you later.

## Design is where decisions get made — and signed

Here's the part teams under-weight. The blueprint isn't documentation you produce _after_ deciding. It's the artefact you decide _through_. The act of writing the target process design forces the business and the delivery team to agree how it will actually work — before a single setting is configured or a line of code is written.

> A signed design is the cheapest scope freeze you'll ever get. Everything after it — build, test, cutover — is more expensive to change. So the design review is where you want the arguments to happen, not UAT.

Sign-off is not a formality, it's the mechanism. When the business reviews and signs the design, three things become true at once: scope is frozen against an agreed reference, build has a stable specification, and test has something concrete to verify against. Without sign-off, you have opinions each stakeholder still holds privately, and they'll surface — one at a time, as change requests — at the worst possible moment. And once signed, the design becomes the baseline that a [decision log and change control](https://gravam.com/blog/decision-log-and-change-control) protect: the choices stay traceable, and later changes get decided against the baseline rather than absorbed into it.

## The finance-specific texture

Finance is where a vague design gets expensive fastest, because finance systems _post_. A loose requirement in some domains produces an ugly screen. A loose design in finance produces a wrong number in a ledger, and then a very tense conversation that starts with "why did it post that?"

So the design has to get specific about the things finance actually runs on:

- **The month-end close** — the actual sequence of the close, the dependencies, the timing, and where the system automates versus where a person still checks. Design the _process_, not just the feature that supports it.
- **The chart of accounts and ledger design** — the account structure, the hierarchy, how the ledger is organised. Get this wrong and every report downstream is wrong, and it's brutal to unwind after go-live.
- **Reconciliation and control points** — where the design builds in the checks: what reconciles against what, where the controls sit, and who owns the exception.
- **The postings** — which transactions post where, with what accounting treatment. This is the "why did it post that?" surface. Every posting rule that's vague in the design is a defect waiting to be found in test — at ten times the cost of pinning it down now.

None of this is glamorous. All of it is the difference between a close that runs and a close that doesn't.

## When UAT becomes the design review

Here's what actually happens without the discipline. Design gets skipped, or it gets "done" inside the configuration tool by whoever's building — the target is whatever they typed, and it lives in the system, not in a document anyone reviewed. There's no agreed, reviewable blueprint. There's just a build that reflects one person's reading of the requirements.

Then UAT arrives, and it becomes the design review that should have happened months earlier. The business sees the solution for the first time, doesn't recognise it, and the "design" gets discovered as a pile of change requests — every one now a change to something built, configured and tested, the most expensive place in the project to be making design decisions.

I've watched this pattern more times than I can count, and the lesson is always the same: the design didn't cost less because you skipped it. You paid for it later, in a currency called re-test. A document costs a review. A built-and-tested configuration costs a rebuild, a re-test, a re-migration of data, and the credibility you spend explaining the slip. A signed design is cheaper than a re-test — every time.

Get the design right and signed, and build becomes execution against a spec instead of interpretation, and test becomes verification instead of discovery. That's the whole point of the blueprint: to move the hard conversations to the cheapest place to have them.

***

_See also [fit-gap analysis](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) and [testing strategy for finance systems](https://gravam.com/blog/testing-strategy-for-finance-systems)._

## Questions this article answers

**Q: What is solution design in a finance-systems project?**

Solution design is the stage where you decide how the system will actually work to meet the agreed requirements — the target process design, the configuration design, the integration and interface design, and the data and reporting design. Requirements and fit-gap tell you what the business needs and where the standard falls short; design decides how each of those needs is met, and captures the decisions in a design document before anyone configures or codes.

**Q: What is a blueprint document?**

A blueprint, or design document, is the written, reviewable record of the target design — the future-state processes, the configuration choices, the interfaces between systems, the data model, and the reports and controls. It exists so the business and the delivery team can see and agree how the solution will behave before it's built, rather than discovering the design one screen at a time during testing. Its value is that it's a single agreed reference that build and test both work from.

**Q: Why sign off the design before build?**

Because sign-off is what freezes scope and turns a set of opinions into an agreed target. Once the business has reviewed and signed the design, build has a stable specification and test has something to verify against. Skipping sign-off means the 'design' only becomes visible during UAT, as a stream of change requests — and reworking a built, tested configuration costs far more than reviewing a document would have.

---

# RAID Logs: Risks, Assumptions, Issues and Dependencies

Source: https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-09-02
Reviewed: 2026-09-02
Summary: A RAID log tracks a programme's risks, assumptions, issues and dependencies — and works only when you actually mitigate and chase them, not file them.

**A RAID log is the single working record of a programme's Risks, Assumptions, Issues and Dependencies — the things that could knock delivery off course, each with an owner, a due date and a next action.** Done properly it's the instrument [governance](https://gravam.com/blog/governance-and-steering-for-finance-programmes) actually steers on. Done badly it's a beautiful register that gets updated the night before the steering meeting and forgotten the morning after — while the real risks live in people's heads and the real issues get worked in Slack.

I've kept RAID logs on a lot of finance-transformation programmes, and the difference between the ones that helped and the ones that didn't had nothing to do with the template. It came down to whether anyone worked the log, or just filed it.

> **Figure — The four lists in a RAID log**
>
> Four cards. R, Risks, might happen. A, Assumptions, treated as true. I, Issues, has happened. D, Dependencies, needed from others. Under them, the words one working record.
>
> Four different kinds of entry in one working record — and the differences between them are the point.

## What the four letters actually mean

The letters look interchangeable. They aren't, and the distinctions are the whole point.

- **Risk** — something that _might_ happen. It has a probability and an impact, and you manage it by _mitigating_: reducing the chance, reducing the damage, or both. A risk lives in the future and in the conditional.
- **Assumption** — something you've decided to treat as true _unless proven otherwise_, because you can't confirm it yet and you need to keep moving. The danger is that it's silent. An assumption that quietly turns out false doesn't announce itself; it just detonates later as an issue.
- **Issue** — something that _has_ happened and is affecting the work _now_. It doesn't get a mitigation. It gets a resolution, an owner, and urgency.
- **Dependency** — something your work needs from someone or something else, usually outside your control: data from another team, a decision from a committee, an environment from IT, onboarding from a bank.

## The distinction everyone gets wrong

The one that costs real money is risk-versus-issue. A risk is future and probabilistic and gets a mitigation. An issue is present and certain and gets a resolution and a named owner. They are not two flavours of the same thing.

Here's the failure I've watched happen more times than I can count: a live problem gets logged as a "risk." It's already true — the data migration is already failing, the interface is already rejecting records — but calling it a risk makes it feel less alarming, so onto the risk register it goes. And risks get _watched_. Issues get _worked_. The moment you file an issue as a risk, you've taken something that needed an owner and a fix this week and turned it into a line item somebody glances at monthly.

> A risk is something that might happen and gets a mitigation. An issue is something that already happened and gets a resolution. Log an issue as a risk and you've quietly decided nobody owns it.

If it's already true, it's an issue. Promote it out of the maybe column and give it a name.

## What a working log looks like

Descriptions of RAID logs are abstract in a way the thing itself isn't. Here's a slice of one from a finance-systems programme a few weeks out from UAT — six entries, all four letters, the columns that make it workable:

| Type | Description | Owner | Due | RAG | Next action |
| --- | --- | --- | --- | --- | --- |
| Dependency | Bank A host-to-host channel: test certificates and sandbox account not yet issued, blocking payment testing | Treasury systems lead | 12 Sep | Amber | Chase the bank's onboarding manager for a written date; escalate to steering if nothing by the 12th |
| Issue | Vendor master migration: 1,340 records failing IBAN validation on load into the test system | Data migration lead | 08 Sep | Red | Split failures by country, agree the cleansing rule with AP, reload the first country by the 8th |
| Risk | UAT starts before all three bank interfaces are live, so payment scenarios can't be tested end to end | Test manager | 19 Sep | Amber | Re-sequence the UAT script to run the connected bank first; re-rate once Bank A gives a date |
| Assumption | The existing bank signatory list is current and no new mandates are needed for the new payment channel | Treasury operations manager | 15 Sep | Amber | Confirm the list against the bank's records in writing; convert to an issue if it doesn't match |
| Dependency | TMS vendor release containing the camt.054 handling fix, needed before reconciliation testing | Programme manager | 26 Sep | Red | Get the release date in writing from the vendor account manager; agree a manual workaround for UAT |
| Risk | Cutover weekend collides with the month-end close for two entities | Finance transformation lead | 30 Sep | Green | Confirm the close calendar with both controllers and fix the cutover date at the next steering |

Read the next-action column rather than the description column: every one of them is a verb, a person and a date, and none of them restates the entry. That's the test. Note also that the owner is a role, not a team — "Treasury operations manager" is somebody who can be asked; "Treasury" is not.

The free [RAID log template](https://gravam.com/tools/raid-log-template) builds this table in the browser — type, description, owner, due date and next action, with an open/closed status where this example carries a RAG rating.

## Every entry needs three things

A RAID log is a _working instrument_, not a register you populate for the deck. Every single entry — risk, assumption, issue or dependency — needs three fields that most logs treat as optional and shouldn't:

- **An owner.** One person, not a team. A risk owned by "Finance" is owned by [no one](https://gravam.com/blog/07-cost-of-unclear-ownership), and it will sit there un-mitigated until it becomes an issue.
- **A due date.** The date the next action happens or the item is reviewed. No date means no urgency means it never moves.
- **A next action.** Not the risk restated — the specific next thing someone is going to do about it. "Risk: vendor may miss the connectivity deadline" is not an action. "Chase written commitment from vendor PM by Friday" is.

An entry without those three is decoration. This mirrors the discipline that starts at [intake](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams): a thing without an owner and a next action isn't being managed, it's being noted.

The [template](https://gravam.com/tools/raid-log-template) above is built around exactly those three. It won't chase your owners for you, but it makes the fields impossible to skip, and it exports as markdown or CSV for the week the log has to leave the browser.

## Work it weekly, not monthly

The cadence is the difference between the log that helped and the log that didn't. A RAID log reviewed monthly, as agenda item six of a status meeting, is a report. A RAID log worked weekly, in a fifteen-minute session of its own, is an instrument.

The weekly session has one question per entry: _what changed, and what happens next?_ The dependency owner reports on the chase. The mitigation gets its next step or the risk gets re-rated. Issues that got resolved get closed — visibly, because closing entries is what keeps the log small enough to work. Anything that needs authority the team doesn't have goes on the steering agenda as an escalation, which is exactly the [governance](https://gravam.com/blog/governance-and-steering-for-finance-programmes) join described above.

Two rules keep the session honest. First, no entry is discussed without its owner present or heard from — an entry nobody can speak to is an entry nobody owns, whatever the owner column says. Second, if the session regularly runs past half an hour, the log is too big: close what's done, promote the stale "risks" that quietly became issues, and delete what nobody would actually chase.

## Dependencies: the silent killer of finance programmes

If I had to point at the single column that sinks finance programmes, it's the D. Risks you can mitigate and issues you can fix, but a dependency is by definition the part of your timeline you don't control.

Think about what a finance-systems programme actually waits on. Bank onboarding on the bank's schedule, not yours. Reference data from another team that has its own backlog and no reason to prioritise you. A go/no-go from a committee that meets monthly. A [test environment](https://gravam.com/blog/finance-systems-environment-strategy) from IT that's three tickets deep. You can run your own workstream flawlessly and still miss the date, because the critical path runs straight through work that isn't yours.

This is why connectivity and cross-team data are almost always the real critical path — and why dependencies bite hardest near [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems), when every deferred dependency comes due in the same fortnight. A dependency logged in month one with an owner and a chase date is a dependency you can escalate while there's still time. A dependency nobody owned is the reason the go-live slips, discovered the week it was needed.

## How the log connects to governance

The RAID log is the natural agenda for a steering committee — because the items on it are precisely what steering exists to steer. When a risk needs a decision above the team's authority, or an issue needs a blocker cleared, or a dependency needs someone senior to lean on another function, the RAID log _is_ the escalation path.

That's the join with [governance](https://gravam.com/blog/governance-and-steering-for-finance-programmes): the team works everything it can own, and everything that exceeds its authority becomes an escalation the steering committee actually resolves. A steering meeting that reviews a RAID log without deciding anything is the status theatre I've written about elsewhere. A steering meeting that clears three blocked dependencies is governance doing its job.

## When the RAID log only serves the deck

Here's the honest failure mode, and I've been on both sides of it. The RAID log is maintained beautifully — colour-coded, RAG-rated, immaculate — for the monthly deck. Meanwhile the risks people actually lose sleep over were never written down, because saying them out loud felt political. The real issues are getting worked in a Slack thread that never touches the log. And the assumptions that will hurt you are the ones nobody flagged as assumptions at all — they were just _what everyone thought was true_.

A risk logged and never mitigated is not risk management. It's a paper trail for the post-mortem — proof that someone saw it coming and did nothing. The test of a RAID log isn't whether it's complete. It's whether anything on it _changed_ since last time: an owner chased a dependency, a mitigation dropped a probability, an issue got resolved and closed. If the log looks the same month after month, it isn't managing your programme. It's watching it.

Keep it small, keep it owned, and work it every week. A RAID log earns its place the moment it stops being a document and starts making someone do something before the date it was due. Its companion is the [decision log and change control](https://gravam.com/blog/decision-log-and-change-control): the RAID log tracks what's still open; the decision log records what was chosen and why.

***

_See also [governance and steering for finance programmes](https://gravam.com/blog/governance-and-steering-for-finance-programmes) and [the cost of unclear ownership](https://gravam.com/blog/07-cost-of-unclear-ownership)._

## Questions this article answers

**Q: What is a RAID log?**

A RAID log is a single working record of a programme's Risks, Assumptions, Issues and Dependencies. Each entry carries an owner, a due date and a next action, and the log is reviewed and worked on a regular cadence. Its purpose is to keep the things that could derail delivery visible and owned — not to produce a tidy register for the steering deck. A RAID log that's only updated before a status meeting isn't managing anything; it's documenting it.

**Q: What is the difference between a risk and an issue?**

A risk is something that might happen — it has a probability and an impact, and it gets a mitigation to reduce one or both. An issue is something that has already happened and is affecting the work now — it gets a resolution and an owner, urgently. The distinction matters because logging a live issue as a 'risk' is how it quietly goes unowned: risks get watched, issues need working. If it's already true, it's an issue, and treating it as a maybe is how it drifts.

**Q: How often should a RAID log be reviewed?**

Weekly, as a short working session — not monthly as part of a status meeting. The session isn't a read-through: for each open entry the only question is what changed and what happens next. Owners chase their dependencies, mitigations get their next step, resolved issues get closed, and anything that exceeds the team's authority becomes an escalation for steering. A log reviewed monthly is a report; a log worked weekly is an instrument. If the review takes more than half an hour, the log is too big — close what's done and delete what nobody would chase.

**Q: Why do dependencies sink projects?**

Because dependencies are the things your work needs from someone or something outside your control — data from another team, a decision from a committee, an environment from IT, onboarding from a bank — and their timelines aren't yours to set. You can run your own workstream perfectly and still miss the date because a dependency you flagged in month one didn't land. In finance programmes, cross-team data and external connectivity are usually the critical path, and they bite hardest near cutover.

---

# Hypercare and Post-Go-Live Stabilization

Source: https://gravam.com/blog/hypercare-and-post-go-live-stabilization
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-02
Summary: Hypercare is the intensive, time-boxed support period right after go-live — and cutting it to save money is a false economy that moves the cost downstream.

**Hypercare is the intensive, time-boxed support period immediately after go-live — the project team staying on, close to the users, triaging defects fast and turning fixes around quickly, before the system is handed to business-as-usual support.** It exists because go-live is the _start_ of the real test, not the end of it. And for finance systems it is the first thing cut when the budget's tight and the launch "looked fine" — which is exactly the mistake this piece is about.

## Go-live is the beginning, not the finish line

[Cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) gets the new system live and the old one retired. That is a genuine achievement, and it's tempting to treat the weekend that lands it as the end of the project. It isn't. Cutover proves the migration; it does not prove the _design under load_.

Everything before go-live runs on a controlled diet — test data, rehearsed scenarios, a handful of friendly users clicking through [agreed cases](https://gravam.com/blog/user-acceptance-testing-for-finance-systems). The morning after go-live, live volumes hit, and with them come the real edge cases and the real users doing what real users do: the transaction nobody scripted, the vendor whose master data is subtly wrong, the workflow someone was quietly working around in the old system for years. Testing narrows the unknowns. It never eliminates them. Hypercare is how you catch the ones that were always going to slip through — while the people who know why the build behaves the way it does are still in the room.

## What hypercare actually is

Hypercare is a deliberate, staffed phase, not a vibe. The defining features:

- **The project team stays on.** The people who designed, built and configured the system are the ones fielding issues — not because BAU support is weak, but because on day one nobody else yet knows the build well enough to diagnose it fast.
- **They work close to the users.** Physically or virtually, the loop between "something's wrong" and "someone who understands it is looking" is measured in minutes.
- **It's time-boxed with an intent to hand over.** Hypercare is a bridge from project to steady state, not a permanent staffing model. It ends — but on criteria, not on a guess.

## Why finance makes hypercare non-negotiable

For most systems, the shakeout is a rolling stream of small issues you fix as they come. Finance is different, because finance runs on a **cycle**, and the cycle has an exam at the end of it: the **period-end close**.

The true test of a new finance system is not go-live day. It's the _first close_ on it — and, along the way, the first payment run and the first reconciliation. That's when the design meets reality in full: every posting rule, every mapping, every accrual and allocation and intercompany elimination gets exercised for real, against real balances carried across at [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems). Plenty of designs sail through go-live and then fall over at close, because close is the first time the whole machine turns over under its own weight.

> Exiting hypercare before the first clean close is exiting before the exam. Go-live tells you the system starts; the first close tells you it works.

Which sets the single most important sizing rule: **hypercare must span the first period-end close.** If go-live is early in the month and your hypercare window closes before month-end, you have withdrawn your experts precisely when the system faces its hardest test with nobody left who can explain what it just did.

## How to run it

A hypercare that works has structure, not just goodwill:

- **A war room and daily triage.** One channel for issues, one standing daily meeting to triage what came in, set priority and assign it. The point is that nothing sits in a queue for three days while the books are open.
- **Severity levels and turnaround targets.** Agree up front what "critical" means (a payment can't run, a close step is blocked) versus cosmetic, and the response time each carries. Without this, everything is either an emergency or ignored. It is the same [defect triage](https://gravam.com/blog/defect-triage-and-exit-criteria) discipline as in testing, carried past go-live.
- **A defect log that feeds fixes.** Every issue recorded, triaged and tracked to closure — a problem isn't done until it's proven done. The log is also the evidence base for the exit decision, and the raw material for the [user communication](https://gravam.com/blog/change-management-for-finance-system-rollouts) that keeps people trusting the system while it stabilises.
- **Defined exit criteria.** This is what separates a managed hypercare from one that just runs out of budget. Exit on things like: a clean close achieved on the new system, the defect backlog below an agreed threshold with no open criticals, and volumes running stable — _then_ transition to steady-state support with a proper handover. Not "it's been four weeks, we're done."

The exit is a decision, made against a standard agreed in advance — the same principle as the [go/no-go checklist](https://gravam.com/tools/cutover-go-live-checklist) that gated go-live in the first place.

## Docs-versus-reality: the false economy

Here's what the plan says, and here's what happens.

The plan says hypercare runs six weeks with the full project team. Then go-live weekend goes smoothly, the demo looked clean, and someone senior asks the reasonable-sounding question: _do we really need all these expensive people sitting around now that it's live?_ The budget's tight, the launch "looked fine," and hypercare is the easiest line to trim because its value hasn't been tested yet. So the team is released early. The consultants roll off. The internal experts go back to their day jobs or straight onto the next programme.

Then the first month-end arrives, and the close breaks — a suspense account that won't clear, a reconciliation out by an amount nobody can source, a posting that went somewhere it shouldn't. And the people who could have said "that's because we mapped it this way, here's the fix in an hour" are gone. Now it's a support ticket, then an investigation, then a specialist re-hired at a premium to reverse-engineer a decision they made themselves three months earlier. The saving was illusory. The cost didn't disappear — it moved downstream, landed at the worst possible moment, and got bigger on the way.

That is the whole argument for holding the line on hypercare. You are not paying for people to sit around. You are paying to keep the knowledge in the room until the system has passed the one test that proves it — and to [stabilise the system before you can credibly realise any of the benefits](https://gravam.com/blog/benefits-realization-for-finance-systems) it was built for. A system limping through its first three closes hasn't delivered anything yet.

## Landing it

Run hypercare as a real phase: project team retained, close to the users, war room and daily triage, clear severities and turnaround targets, a live defect log, and exit criteria that include a clean first close. Size it to span the first period-end, not to a tidy number of weeks. Then hand over to steady-state support deliberately, once the criteria are met.

Cut it instead, and you don't save the money — you defer it, with interest, to the first month-end. For something as unforgiving as a finance close, that's a trade worth refusing. Hypercare is the net _after_ go-live; proving the run team can actually operate the system _before_ it is [operational readiness and acceptance](https://gravam.com/blog/operational-readiness-and-acceptance) — and using hypercare to substitute for that readiness is the mistake to avoid.

***

_See also [cutover and go-live](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) and [change management for finance system rollouts](https://gravam.com/blog/change-management-for-finance-system-rollouts)._

## Questions this article answers

**Q: What is hypercare?**

Hypercare is the intensive, time-boxed support period immediately after go-live, when the project team stays on and works close to the users — triaging defects fast, turning fixes around quickly, and stabilising the new system before it's handed to business-as-usual support. It exists because go-live is when the design first meets live volumes, real edge cases and real users, and you want the people who built it on hand to fix what surfaces.

**Q: How long should hypercare last?**

Long enough to span the first real test. For a finance system that means the first period-end close on the new system — and usually the first payment run and first reconciliation too — because that's when the design meets reality. Sizing hypercare to a round number of weeks that ends before the first close is sizing it to end before the exam. Cover the first clean close, then some margin, before you exit.

**Q: When can you exit hypercare?**

Against defined exit criteria, not an arbitrary date. Typical criteria: a clean period-end close completed on the new system, the defect backlog down below an agreed threshold with no open criticals, and transaction volumes running stable. When those are met, you transition deliberately to steady-state support with a handover, rather than the team simply dispersing when the calendar says the project is over.

---

# Configuration vs Customization in Finance Systems

Source: https://gravam.com/blog/configuration-vs-customization-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-08-19
Summary: Configuration fits your process using shipped settings; customization builds bespoke — a permanent liability paid at every upgrade.

**Configuration means fitting your process using the settings and options the system already ships; customization means building something bespoke the vendor doesn't — a report, an interface, a code enhancement, a form, a workflow.** Both can satisfy the same requirement. They are not the same decision, because they carry completely different costs — not at build time, but for every year the system lives afterwards. This is the build-phase choice that quietly decides whether your finance system stays maintainable or slowly becomes something no one dares touch.

I've watched this decision get made well and badly, and the difference almost never shows up in the go-live. It shows up three upgrades later.

## The distinction

Configuration is working _within_ what the system was designed to flex. You set tolerance limits, define a posting rule, switch on an approval step, map an account structure — using the vendor's own settings, in the way the vendor supports. When the next release ships, your configuration comes with it. It's part of the standard's contract with you.

Customization is code and objects the vendor never shipped and never accounts for. In [fit-gap terms](https://gravam.com/blog/fit-gap-analysis-for-finance-systems), a gap is a requirement the standard doesn't meet as-is; customization is one of the things you do with a gap — you build the missing piece yourself. A bespoke report because the standard ones don't show what finance wants. An interface to a system the package doesn't know exists. An enhancement that injects your logic into a standard process. A custom form, a custom workflow. Useful, sometimes unavoidable — and permanently yours to carry.

The SAP world has a tidy way of cataloguing this: RICEFW — Reports, Interfaces, Conversions, Enhancements, Forms, Workflows. It's not a method, it's a checklist of the categories where custom tends to appear, used so a programme can _count_ its custom footprint instead of pretending it doesn't have one. You don't need SAP to borrow the idea. The value is simply this: make the customizations visible and countable, because the ones nobody counted are the ones that hurt.

| Dimension | Configuration | Customization |
| --- | --- | --- |
| What it is | Fitting your process with shipped settings, options, rules | Building bespoke the vendor doesn't ship (RICEFW) |
| Vendor support | Supported; part of the standard's contract | Code the vendor never accounts for |
| Upgrades | Comes with the next release | Must be regression-tested at every upgrade; can break |
| Lifetime cost | Low | A permanent liability on the books |
| Maintenance | Within the standard | Needs documentation and specific skills |
| When to use | Default, standard-first | A true differentiator or hard regulatory gap only |

## The real cost is the lifetime, not the build

Here is the number that gets missed. When someone estimates a customization, they estimate the build — a week of development, a bit of testing, done. That number is almost irrelevant.

The real cost is everything after. Every customization has to be [regression-tested at every upgrade](https://gravam.com/blog/testing-strategy-for-finance-systems), because a release can change the standard underneath it and silently break it. Every customization needs documentation, or the knowledge of why it exists walks out the door with the person who built it. Every customization needs someone who still has the skills to maintain it. And every customization narrows what you can safely change next, because now there's bespoke logic entangled with the thing you wanted to touch.

> A customization is not a task you complete. It's a liability you take onto the books — and you keep paying it, in testing and maintenance and lost flexibility, for every year the system runs. The build is the cheapest thing about it.

One customization is fine. The problem is that they don't stay singular. Each one seems reasonable on its own, and together they compound into a system that's expensive to run, frightening to upgrade, and understood by no one still employed. I've inherited estates with hundreds of custom objects where nobody could tell me what half of them were for — so nobody could remove them, so all of them got regression-tested, forever.

## Standard-first is a discipline, not a slogan

Fit-to-standard means changing the _process_ to fit the supported standard before you build bespoke to preserve a process. It sounds obvious and it's genuinely hard, because it means telling a room full of finance people that the way they've done something for fifteen years is going to change — and doing that is far less comfortable than saying "sure, we can build that."

Standard-first isn't dogma that forbids all custom. Sometimes the standard genuinely can't meet a real need — a true competitive differentiator, or a hard regulatory requirement the package doesn't cover in your jurisdiction. Those cases are real, and building for them is the right call. The discipline is spending your customization budget _only_ there, deliberately, rather than everywhere the standard is merely unfamiliar. Reserve custom for where your process is a defensible differentiator, not where it's just habit.

## Govern it like the liability it is

Because customizing is easier in the moment than changing a process, it becomes the path of least resistance for whoever's configuring under a deadline. That's the trap. Left ungoverned, the config-vs-custom choice defaults to custom — not because anyone decided it should, but because a difficult conversation got avoided.

So make it a decision with an owner. A customization should require someone to sign it — to say, on the record, "this bespoke object is justified, and I accept the lifetime cost." Not the developer under pressure at 6pm; someone accountable for the estate's long-term health. This is exactly what a [solution design and blueprint](https://gravam.com/blog/solution-design-and-blueprint-for-finance-systems) is for: it's where config-vs-custom gets decided on purpose, before build, rather than object by object under delivery pressure. And it starts even earlier, in the [intake and shaping](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) that turns a vague ask into a requirement clear enough to fit against the standard at all.

## The conversation you're really avoiding

Strip it back and the docs-vs-reality truth is uncomfortable. Teams don't customize because the standard _can't_ work. They customize because making the standard work requires a difficult process-change conversation with the business — and building custom code lets everyone skip that conversation today.

But you don't actually skip it. You defer it, with interest. That avoided conversation comes back as a regression test in every upgrade, a maintenance line in every budget, a constraint on every future change — for a decade. You paid to _not_ have a hard conversation once, and the invoice arrives every single year afterwards.

Configuration versus customization looks like a technical choice at build time. It's really a choice about how much liability you're willing to carry, and whether you'll make that choice deliberately or let a deadline make it for you.

***

_See also [fit-gap analysis](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) and [testing strategy for finance systems](https://gravam.com/blog/testing-strategy-for-finance-systems)._

## Questions this article answers

**Q: What is the difference between configuration and customization?**

Configuration is fitting your process using the settings, options and rules the system already ships — supported by the vendor and safe through upgrades. Customization is building something the vendor doesn't ship: bespoke reports, interfaces, code enhancements, forms or workflows. Configuration bends the standard within its designed flexibility; customization adds code the vendor never accounts for, which is why the two carry completely different lifetime costs even when they solve the same requirement.

**Q: Why is customization expensive?**

Because the real cost isn't the build — it's the lifetime. Every customization must be regression-tested at each upgrade, can break when the vendor changes the standard underneath it, needs documentation and specific skills to maintain, and constrains what you can safely change later. A one-week build becomes a decade of testing, patching and institutional knowledge. Custom code is a permanent liability on the books, not a one-off project cost, and it should be budgeted that way.

**Q: What is RICEFW?**

RICEFW is a common way large SAP programmes catalogue their custom objects — Reports, Interfaces, Conversions, Enhancements, Forms and Workflows. It's a checklist of the categories in which teams tend to build bespoke, used to count and govern the custom footprint of an implementation. The value isn't the acronym; it's that it forces a programme to make its customizations visible and countable instead of letting them accumulate unnoticed.

---

# Agile vs Waterfall for Finance-Systems Delivery

Source: https://gravam.com/blog/agile-vs-waterfall-for-finance-systems-delivery
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-24
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: How to choose a delivery approach for finance systems — why pure agile strains against a hard cutover, and why a hybrid spine usually wins.

**For finance-systems delivery, the honest answer to "agile or waterfall?" is almost always "both, deliberately."** A finance programme has a hard cutover that behaves like waterfall whether you want it to or not, and a build phase that benefits enormously from iteration. The failures I've watched rarely come from picking the wrong method — they come from applying one method to the whole thing because it was the house religion, instead of choosing per phase with eyes open.

Before you argue methodology, it's worth being clear on what you're actually delivering and why — the same discipline that a good [project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) forces early. Method follows the work, not the other way round.

## The two paradigms, honestly

**Waterfall** sequences the work into phases — requirements, design, build, test, deploy — each largely completed before the next begins. Scope is fixed up front, the plan runs to hard dates, and delivery lands as a planned big-bang cutover rather than a stream of small releases. Its strength is predictability and a clear, signed baseline; its weakness is that it assumes you can specify everything correctly at the start, and defers the moment of truth — does this actually work for real users? — all the way to the end.

**Agile** works the opposite way: iterative and incremental, delivering working increments frequently, with scope allowed to evolve as you learn. Requirements are discovered and refined rather than fixed, feedback comes early and often, and the plan adapts. Its strength is that it surfaces reality fast and lets you change course cheaply; its weakness is that "evolving scope" and "frequent delivery" are exactly the two things a hard external deadline and a reconciled ledger are least forgiving of.

| Dimension | Waterfall | Agile |
| --- | --- | --- |
| Scope | Fixed up front | Evolves as you learn |
| Delivery | Big-bang cutover on a date | Frequent working increments |
| Plan | Runs to hard external dates | Adapts to feedback |
| Strength | Predictability, signed baseline | Surfaces reality fast, cheap to change course |
| Weakness | Defers the moment of truth to the end | Evolving scope clashes with hard deadline and reconciled ledger |
| Best fit | The controlled cutover / macro spine | The build and test phases |

## Why finance programmes lean waterfall-ish at the macro level

Finance systems don't ship into a vacuum — they ship into a calendar. Month-end, quarter-end, year-end and regulatory dates are fixed by the outside world, and the programme bends to them, not the reverse. That alone pushes the macro shape toward sequenced phases converging on a chosen date.

Then there's the cutover itself. A general-ledger or close migration is inherently a _planned event_, not an iterative trickle. You move to the new system on a date, with a [reconciled opening balance](https://gravam.com/blog/cutover-and-go-live-for-finance-systems), and you cannot run half the ledger on the old system and half on the new across a single month-end and still reconcile it. Add the integration surface — a finance core touches sub-ledgers, treasury, tax, payroll, consolidation and reporting, and those interfaces have to be consistent at once — and the case for a controlled, coordinated cutover only hardens.

Finally, reconciliation and audit want a _stable, signed baseline_. Auditors check against a fixed set of numbers, and reconciliation compares old to new at a defined point. Continuously shifting scope under a live ledger is the opposite of what that assurance needs.

> You cannot iterate your way into a live general ledger. The build that leads up to go-live can be incremental; the go-live is a controlled event with a plan, a rehearsal and a signed set of numbers.

## Where agile genuinely helps — inside that spine

None of the above means the whole programme should be a two-year waterfall plan drawn once and marched to. Inside the build and test phases, iteration is where the real work gets de-risked.

Configuration and build are far better done iteratively — stand up a chart of accounts, a posting rule, a reporting hierarchy, show it to the people who'll live with it, correct it, move on. Delivering the solution as sprint-based increments means finance sees something real early instead of a specification they can't visualise. Early and repeated **UAT** matters more here than almost anywhere: finance users find the edge cases — the odd intercompany posting, the currency revaluation, the accrual reversal — that no requirements document ever captured cleanly. And that points at the deeper reason to iterate: on genuinely uncertain requirements, you _discover_ what's needed by building and testing, because the users couldn't have specified it up front even with perfect intentions.

## The realistic answer is hybrid

Put those together and you get the shape that actually works: a **waterfall spine** — design, build, test, one controlled cutover — with **agile execution inside the build and test phases**. The spine gives the finance and audit side the predictability, the coordinated cutover (gated by a [cutover and go-live checklist](https://gravam.com/tools/cutover-go-live-checklist)) and the signed baseline they need. The iteration inside gives delivery the fast feedback and requirement discovery it needs. This isn't a compromise nobody wanted; it's the correct decomposition of a problem that genuinely has both characters.

The important word is _deliberately_. Decide per programme — and per phase within it — which character each part has, rather than adopting one label for the whole thing. That decision belongs in [governance](https://gravam.com/blog/governance-and-steering-for-finance-programmes), made explicitly, not defaulted into by whichever method the delivery org happens to brand itself with. And whatever the method, you still owe the programme a [measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome) it's steering toward — method is how you get there, not what "there" is.

## How delivery methods fail on finance projects

The most expensive failure I've watched is "we're agile now" applied to a close-the-books migration. A team, proud of its transformation, treated a general-ledger cutover as something to release incrementally — and discovered at the worst possible time that you cannot half-migrate a ledger across a month-end and reconcile it. The opening balance has to be one reconciled number on one date. No amount of sprint velocity changes that; the close is an event, and pretending it's a backlog just moves the reckoning to the night of go-live.

The opposite failure is just as real and I've seen it more often than people admit. Rigid waterfall applied to genuinely uncertain requirements doesn't remove the uncertainty — it _defers_ it. Every ambiguity you waved through in a design signed twelve months ago comes due in UAT, all at once, at the point in the plan with the least slack to absorb it. You didn't avoid the discovery; you postponed it to the most expensive moment to have it.

So the skill isn't picking a side. It's seeing which parts of a finance programme have a hard, event-shaped, baseline-hungry character — and running those as a spine — and which parts are genuinely uncertain and better discovered by building — and running those iteratively inside it. Get that decomposition right and the methodology argument mostly dissolves. Get it wrong in either direction and you pay, either on go-live night or in a UAT that was quietly loaded with a year of deferred questions.

***

_See also [cutover and go-live for finance systems](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) and [governance and steering for finance programmes](https://gravam.com/blog/governance-and-steering-for-finance-programmes)._

## Questions this article answers

**Q: Should finance systems be delivered agile or waterfall?**

For most finance-systems programmes, neither in its pure form. The realistic answer is hybrid: a waterfall spine — design, build, test, one controlled cutover — because a general-ledger or close migration has hard external dates and needs a stable, reconciled baseline, with agile execution inside the build and test phases, where iterative configuration, sprint-based increments and early UAT genuinely help. Choose deliberately per programme, not by whichever method is in fashion.

**Q: Why is a finance-system go-live not iterative?**

Because a general-ledger or close-the-books cutover is inherently a planned event, not a trickle of increments. You move to the new system on a chosen date with a reconciled opening balance, and reconciliation and audit need a single stable, signed baseline to check against. You cannot run half the ledger old and half new across a month-end and still reconcile it. The build leading up to go-live can be iterative; the cutover itself is a controlled event with a plan, a rehearsal and a signed set of numbers.

**Q: What is a hybrid delivery approach?**

A hybrid approach keeps a waterfall-style spine at the macro level — sequenced design, build, test and one controlled cutover, aligned to hard external dates — while running the build and test phases with agile execution: iterative configuration, sprint-based delivery of increments, and early, repeated UAT. You get the predictability and the signed baseline the finance and audit side needs, plus the fast feedback and requirement discovery that iteration gives you inside the phases.

---

# Governance and Steering for Finance Programmes

Source: https://gravam.com/blog/governance-and-steering-for-finance-programmes
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-24
Reviewed: 2026-09-02
Summary: Programme governance steers a large finance-systems programme — the decision structure, cadence and escalation. Good governance keeps a big programme unblocked.

**Programme governance is how a large finance-systems programme is steered and controlled — the decision structure, the review cadence, and how blockers and changes get escalated and resolved.** Its purpose is to keep a big, cross-functional, long-running programme _aligned and unblocked_ by giving decisions and problems a clear home. Good governance is nearly invisible: the programme just keeps making the calls it needs to make and clearing the obstacles in its way. Bad or absent governance is how programmes drift off course, stall on decisions nobody's empowered to make, and fail slowly — a month of delay at a time, with no single dramatic cause.

## What it is

Governance isn't the delivery work itself — it's the _steering_ of it. Who decides what, who's accountable, how progress is reviewed, and how the inevitable [blockers, risks and changes](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) get surfaced and resolved — in practice, on a [RAID log](https://gravam.com/tools/raid-log-template). For a single small piece of work you barely need it; for a multi-workstream, multi-year finance transformation, it's the difference between a programme that holds together and one that quietly comes apart.

## Why big programmes need it

A large finance programme is long, spans many functions (treasury, accounting, IT, tax, the business), and involves stakeholders with competing priorities. Decisions constantly arise that _no single team can make alone_ — a cross-functional trade-off, a scope call, a resource conflict. Without governance, those decisions have nowhere to go: they drift, get made informally by whoever's loudest, or simply never get made while the programme waits. Governance gives them a home. And a decision, once made, has to _stay_ made — recording it in a [decision log with proper change control](https://gravam.com/blog/decision-log-and-change-control) is what stops the same argument being reopened every quarter.

## The structure

A workable governance structure has clear roles:

- **Sponsor** — a single, senior, accountable owner of the programme's success. Not a committee — a _person_.
- **Steering committee** — the senior forum where cross-functional decisions are made.
- **Programme lead** — runs the programme day to day.
- **Workstream leads** — own the individual streams of work.

The point isn't the org chart — it's that every decision and every blocker has an unambiguous owner and an escalation path.

## The sponsor

The sponsor is the keystone. A programme needs _one_ senior person genuinely accountable for its outcome — with the authority to make cross-functional decisions and the standing to unblock what the programme lead can't. A programme without an empowered, engaged sponsor is one where the hardest decisions have no owner, and those are exactly the decisions that sink it. This is [outcome ownership](https://gravam.com/blog/07-cost-of-unclear-ownership) at the programme level.

## The steering committee — decisions, not theatre

> A steering committee's job is to make the decisions the programme can't make for itself — not to watch a status deck. If everyone leaves the meeting exactly as blocked as they arrived, it wasn't governance; it was theatre.

The most common governance failure is the steering committee that only _receives status_. An effective one is a **decision forum**: it makes the hard cross-functional calls, removes blockers needing senior authority, resolves resource conflicts, and holds the direction. Judge it by one test — does the programme leave each meeting more _unblocked_ than it arrived?

## Decisions and escalation

The real work of governance is _resolving things fast_. There must be a clear path for a blocker or decision to travel up to the level that can resolve it, and a norm that it gets resolved _quickly_ — because a programme waiting weeks on an unmade decision is a programme burning money and momentum. The measure of good governance isn't how many meetings it holds; it's how fast a decision that needs making actually gets made.

## Cadence, risk and change

Governance runs on a **cadence** — regular reviews, but _purposeful_ ones, sized to the programme rather than ritualised. It's also where **risks and changes** get surfaced and decided: material risks escalated to people who can act, and [scope or plan changes](https://gravam.com/blog/how-to-write-scope-in-and-scope-out) decided deliberately rather than absorbed silently. Governance is the programme's mechanism for staying honest about where it really is.

## When steering turns into status theatre

- **Status theatre.** Governance reduced to reporting progress, while the decisions that matter go unmade.
- **No empowered sponsor.** A nominal sponsor without the authority or engagement to unblock, so hard calls have no owner.
- **Decisions that don't get made.** Blockers raised but never resolved or escalated, so the programme waits.
- **Governance overhead.** So many boards and meetings that governance consumes the programme instead of steering it.
- **Governance without teeth.** Forums that discuss but can't decide, so nothing actually moves.

Give the programme one empowered sponsor, a steering committee that _decides_ rather than watches, a fast escalation path, and a purposeful cadence — and governance becomes the quiet machinery that keeps a big finance programme aligned and moving. Get it wrong and no amount of good delivery work downstream will save a programme that can't make the decisions it needs to. Governance is where a programme is steered — or where it drifts.

***

_See also [the cost of unclear ownership](https://gravam.com/blog/07-cost-of-unclear-ownership) and [the project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams)._

## Questions this article answers

**Q: What is programme governance?**

Programme governance is the structure and process by which a large programme is steered and controlled — who makes which decisions (sponsor, steering committee, programme and workstream leads), how progress is reviewed, and how risks, blockers and changes are escalated and resolved. Its job is to keep a big, cross-functional, long-running programme aligned to its goals and unblocked, by giving decisions and problems a clear home rather than letting them drift. Good governance is about enabling decisions, not producing status reports.

**Q: What does a steering committee do?**

A steering committee is the senior decision-making forum for a programme. Its real job is to make the decisions the programme can't make for itself, remove blockers that need senior authority, allocate resources, and hold the direction — not to sit through status updates. A steering committee that only receives progress reports is 'status theatre'; an effective one is where the hard cross-functional decisions actually get made and the programme leaves each meeting more unblocked than it arrived.

**Q: Why do finance programmes need governance?**

Because large finance-systems programmes are long, cross-functional and involve many stakeholders with competing priorities, so decisions and blockers constantly arise that no single team can resolve alone. Without a governance structure, those decisions have no home — they drift, escalate informally or never get made, and the programme stalls or slowly goes off course. Governance gives decisions and risks a clear owner and forum, an escalation path, and a cadence, so a big programme stays aligned and moving instead of quietly losing its way.

---

# Benefits Realization for Finance Systems

Source: https://gravam.com/blog/benefits-realization-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: Benefits realization confirms a system actually delivered the outcomes it was justified on — not just that it went live. The step almost everyone skips.

**Benefits realization is the discipline of confirming that a finance system actually delivered the outcomes it was justified on — not just that it went live, but that the promised benefits materialized.** It is also the step most often missing from an AI programme, where it is [the last item in the sequence](https://gravam.com/blog/where-to-start-with-enterprise-ai) and the one nobody schedules. Faster close, fewer errors, less manual effort, better visibility — the [business case](https://gravam.com/blog/treasury-management-system-business-case) promised them; benefits realization checks whether they arrived. It closes the loop back to the [measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome) defined at intake, and it's the step almost everyone skips — because by the time the benefits would show, the project is "done" and the team has moved on. Skipping it means never learning whether the investment paid off, and quietly funding the next business case on faith.

## What it is

A finance system is justified on _outcomes_ — a case is made that it'll deliver specific benefits. Benefits realization is going back, after go-live, to check: _did those benefits actually happen?_ It's the difference between "we delivered the system" (an [output](https://gravam.com/blog/how-to-define-a-measurable-outcome)) and "the close is genuinely a day faster now" (the outcome the whole thing was for).

## Why it's skipped

> Projects declare victory at go-live — the moment before the benefits could possibly have appeared. By the time they would show, the team is gone and no one's measuring. So success is assumed, never proven.

The reasons are structural: the project ends at go-live, the benefits take weeks or months to materialize, no baseline was captured to compare against, no one owns the _outcome_ (as opposed to the delivery), and measuring honestly risks an uncomfortable answer. All of which conspire to make "we went live" stand in for "it worked."

## Closing the loop

Benefits realization is where the delivery lifecycle _closes back on itself_. The [outcome defined at intake](https://gravam.com/blog/how-to-define-a-measurable-outcome) and the benefits promised in the business case are the exact things you now measure. If the outcome was "month-end close is a day faster," the benefits check is simply: _is it?_ This is why defining a measurable outcome up front matters so much — it's what makes the loop closable at all. Without it, there's nothing to measure against, and benefits realization is impossible by construction.

## How to do it

1. **Baseline before.** Capture the relevant measures _before_ the project — close duration, error rates, manual hours, whatever the case promised. For a treasury system, the [TMS business-case calculator](https://gravam.com/tools/tms-business-case-calculator) is one place those promised numbers are written down. No baseline, no comparison.
2. **Define the benefit measures up front** — as part of the [outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome), so you know exactly what you'll check.
3. **Allow time after go-live.** Benefits don't appear on day one — the system has to bed in and [adoption](https://gravam.com/blog/change-management-for-finance-system-rollouts) has to take hold.
4. **Measure the same things after**, and compare to the baseline and the promised outcome.
5. **Report honestly** — including where benefits fell short, and why.

## Benefits take time — and adoption

Benefits lag go-live, sometimes by months, because they depend on the organization actually _using_ the system well. A system that's live but not yet [adopted](https://gravam.com/blog/change-management-for-finance-system-rollouts) delivers little; the benefits arrive as usage matures. Measuring too early shows nothing; never measuring shows nothing either. The skill is waiting long enough, then actually checking.

## It needs an owner

Benefits realization requires someone accountable for the _outcome_, not just the delivery — the [outcome owner](https://gravam.com/blog/07-cost-of-unclear-ownership) whose job doesn't end at go-live. Without that ownership, benefits realization is nobody's task, gets skipped, and success is assumed forever. The owner is what makes the loop actually close.

## Why it matters

Beyond honesty about a single project, benefits realization is how an organization _learns_: which investments pay off, which business cases were optimistic, what actually moves the needle. Skip it, and every future business case is argued on faith rather than evidence — and the credibility of the whole transformation function slowly erodes, because no one can point to a benefit that was ever actually confirmed.

## Why benefits never get measured

- **No baseline.** Nothing captured beforehand, so there's nothing to measure against afterward.
- **Never measuring.** Success declared at go-live and never revisited.
- **Measuring too early.** Checking before benefits could materialize, then concluding there are none.
- **Vanity metrics.** Measuring something easy that moved, rather than the outcome that mattered.
- **No owner.** No one accountable for the outcome, so the check never happens.

Capture a baseline, define the benefits as measurable outcomes up front, give it time, measure honestly, and give it an owner — and benefits realization closes the loop that most projects leave dangling. It's what turns "we delivered a system" into "we delivered the _outcome_" — and it's the only way to know, rather than hope, that the work was worth it. That honesty is exactly the discipline [Delivery Sheet](https://gravam.com/products/delivery-sheet) is built to protect, from the first problem statement to the benefit finally confirmed.

***

_See also [defining a measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome) and [change management for finance rollouts](https://gravam.com/blog/change-management-for-finance-system-rollouts)._

## Questions this article answers

**Q: What is benefits realization?**

Benefits realization is the discipline of confirming that a project actually delivered the benefits it was justified on — not just that it was completed, but that the promised outcomes (faster close, fewer errors, less manual effort, better visibility) genuinely materialized. It involves defining the benefits and a baseline before the work, then measuring the actual outcomes afterward against that baseline. It closes the loop back to the business case, and it's the step most projects skip because the team has moved on by the time the benefits would show.

**Q: Why do most projects skip benefits realization?**

Because the project is declared successful at go-live and everyone moves on, while the actual benefits take weeks or months to appear and require someone to go back and measure them. There's rarely an owner accountable for the outcome (as opposed to the delivery), no baseline was captured beforehand to compare against, and measuring honestly risks showing the benefits fell short. So success is assumed at go-live and never verified, which is how organizations keep funding business cases whose predecessors never proved out.

**Q: How do you measure the benefits of a finance system?**

Capture a baseline of the relevant measures before the project (close duration, error rates, manual effort hours, whatever the business case promised), then measure the same things after go-live once the system has bedded in, and compare against the outcomes that were defined. The key is that the benefits and their measures were specified up front as measurable outcomes, a baseline exists, and an accountable owner actually goes back to check — allowing enough time after go-live for the benefits to materialize.

---

# Testing Strategy for Finance Systems: SIT, UAT, Regression

Source: https://gravam.com/blog/testing-strategy-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: A testing strategy defines how you prove a finance system works before go-live — unit, SIT, UAT and regression. In finance, the numbers must reconcile too.

**A testing strategy defines how you'll prove a finance system works before go-live — the layers of testing (unit, system integration, user acceptance, regression) and what each proves.** The key insight it encodes: different kinds of defect need different tests to catch them, and skipping a layer means a whole class of failure walks straight into production. In finance especially, testing must prove not just that _functions work_ but that _numbers reconcile_ and _integrations move data intact_ — because a silently dropped record becomes a wrong figure in the accounts. [UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) alone, though vital, is not a testing strategy.

## What a testing strategy is

It's the deliberate plan for proving correctness: which test layers run, what each proves, what data they use, and the entry/exit criteria for each. Without it, testing becomes whatever people happened to check before a deadline — and the gaps are exactly where production incidents come from.

## The layers

Each layer catches a different class of defect:

| Layer | Proves | Run by |
| --- | --- | --- |
| **Unit** | Individual components work | Developers |
| **System integration (SIT)** | Connected systems work together | Technical team |
| **User acceptance (UAT)** | It does what the business needs | Business users |
| **Regression** | Existing function still works after changes | Team / automated |
| **(Performance)** | It holds up under real volume, at period-end | Technical team |

Miss one and its class of defect is untested.

## SIT: does the plumbing work?

**System integration testing** verifies the _connected landscape_ — that interfaces move data intact between the [ERP, the TMS, the banks](https://gravam.com/blog/designing-erp-tms-integration) and other systems, end to end. This is where finance systems most often break in ways UAT can't see: a feed that drops records, a format mismatch, a mapping error. SIT proves the [interfaces](https://gravam.com/blog/interface-monitoring-and-reconciliation) carry the data correctly — using the same control-total logic (counts and sums, source vs target) that monitors them in production.

## UAT: is the result fit for purpose?

[UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) verifies the system does what the business actually needs, run by real users against real scenarios, ending in sign-off. It's the business's judgement that the system is fit for purpose. Crucially, it's _not_ a substitute for SIT — a system can pass UAT on a screen while an interface silently drops data behind it. Different questions, different layers.

## Regression: did we break what already worked?

Every change risks breaking something that previously worked. **Regression testing** re-checks existing functionality after changes, so a fix or enhancement doesn't silently break the close that ran fine last month. In finance, where the same processes run every period, regression is what keeps a change from turning last period's working number into this period's wrong one. It's the layer most often skipped and most quietly expensive.

## Why finance testing is different

> In most systems, testing asks "does it work?" In finance, it also has to ask "does it reconcile?" — because the output isn't a screen, it's a number that has to balance and tie back to source.

Finance testing must run **real end-to-end scenarios** — a full close, a payment run — with **realistic data**, and _check the totals_, not just the navigation. A happy-path click-through with toy data proves almost nothing about whether the month-end position will be right.

## Test data and criteria

Two things make the layers meaningful:

- **Realistic data** — enough volume and messiness to surface the edge cases; clean toy data hides the problems you'll hit live.
- **Entry/exit criteria** — agreed definitions of when a layer can start and when it's genuinely passed, so testing ends because it's _done_, not because time ran out.

## Entry and exit criteria by layer

"Entry and exit criteria" is the phrase that turns a testing plan into a gate. Each layer should say when it can _start_ and when it's genuinely _passed_ — and, in finance, the defect bar that lets you move on, which is what [defect triage and exit criteria](https://gravam.com/blog/defect-triage-and-exit-criteria) set.

| Layer | Can start when (entry) | Passed when (exit) | Defect bar to move on |
| --- | --- | --- | --- |
| **Unit** | Component built | Component tests green | No open critical/major in the component |
| **SIT** | Interfaces built, environment ready | Data ties source ↔ target end to end | No open defect that drops or corrupts data |
| **UAT** | SIT passed; real scenarios + realistic data | Business signs off on real scenarios | No open critical; agreed cap on minors |
| **Regression** | A baseline suite exists | Prior functions still pass after the change | Zero regressions on money-affecting paths |
| **Performance** | Volume test data staged | Holds at period-end volume within SLA | No breach at peak load |

The exit column is the one that gets skipped under deadline pressure — and skipping it is exactly how "testing finished" comes to mean "time ran out," not "the system is proven."

## The gaps that reach production

- **Only UAT.** Relying on user testing alone, so integration and regression defects reach production.
- **No SIT.** Interfaces untested end-to-end, so a feed that drops data is discovered in the first live close.
- **No regression.** Changes break existing function silently, and last period's good number goes wrong.
- **Toy data.** Clean, tiny datasets that never trigger the real-world edge cases.
- **No exit criteria.** Testing "finishes" at the deadline regardless of whether it passed.

Run the layers that catch each class of defect — unit, SIT, UAT, regression, performance — on realistic data, with real entry/exit criteria, and check that the numbers reconcile end to end. That's what turns testing from a pre-go-live scramble into genuine confidence that a [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) will hold. UAT tells you it's fit for purpose; the rest of the strategy tells you it actually works. Gate the go-live itself with the free [Cutover & Go-Live Checklist](https://gravam.com/tools/cutover-go-live-checklist), where the critical items decide the verdict. All of it rests on the data the tests run on — realistic, checkable and safe — which is its own discipline: [test data management](https://gravam.com/blog/test-data-management).

***

_See also [user acceptance testing](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) and [interface monitoring and reconciliation](https://gravam.com/blog/interface-monitoring-and-reconciliation)._

## Questions this article answers

**Q: What is a testing strategy?**

A testing strategy is the plan for how a system's correctness will be proven before go-live — which layers of testing will run (unit, system integration testing, user acceptance testing, regression, and often performance), what each layer proves, what data they use, and the entry and exit criteria for each. It ensures testing is deliberate and complete rather than an ad hoc scramble, and that the different kinds of defect — component bugs, integration failures, wrong business outcomes, and breakages of existing function — are each caught by the layer designed to find them.

**Q: What is the difference between SIT and UAT?**

System integration testing (SIT) verifies that the connected systems work together correctly — that interfaces move data intact between the ERP, the TMS, the banks and other systems, end to end. It's a technical test of the integrated landscape. User acceptance testing (UAT) verifies that the system does what the business actually needs, run by the real users against real scenarios. SIT proves the plumbing works; UAT proves the result is fit for purpose. You need both — a system can pass UAT in isolation and still fail because an interface silently drops data.

**Q: Why is testing finance systems different?**

Because finance testing has to prove not just that functions work but that the numbers reconcile and that data moves intact across integrated systems. A finance system's output is positions, payments and postings that must balance to the penny and tie back to source, so testing has to run real end-to-end scenarios — a full close, a payment run — with realistic data and check the totals, not just click through screens. Integration and reconciliation testing matter far more than in most systems, because a silently dropped record becomes a wrong number in the accounts.

---

# How to Write Good Requirements for Finance Systems

Source: https://gravam.com/blog/how-to-write-good-requirements-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-02
Summary: How to write good requirements: state what the system must do, clearly and testably, without prescribing the solution. Bad requirements are why delivery fails.

**A good requirement states what the system must do to meet a real business need — clearly, testably, and without prescribing the solution.** Good requirements are unambiguous, testable, necessary, feasible and solution-free; bad ones are the single most common root cause of delivery failure, because everything downstream ([design](https://gravam.com/blog/solution-design-and-blueprint-for-finance-systems), build, testing) inherits their flaws. A vague requirement doesn't get clearer [as it moves through delivery](https://gravam.com/blog/agile-vs-waterfall-for-finance-systems-delivery); it gets _built_, wrongly, and the cost surfaces in UAT or production. Getting requirements right is the cheapest quality investment a finance-systems project can make.

## What a requirement is

A requirement is a statement of something the system must do or a quality it must have, to satisfy a real need. It's the bridge between a [shaped problem and outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome) and the thing that gets built. If that bridge is faulty, everything crossing it goes wrong.

## The characteristics of a good requirement

- **Clear / unambiguous:** one interpretation only. If two people can read it differently, they'll build it differently.
- **Testable:** you can objectively verify whether it's met. (See below; this is the acid test.)
- **Necessary:** it traces to a genuine business need, not a preference or a habit.
- **Feasible:** it can actually be done within the constraints.
- **Solution-free:** it states _what's_ needed, not _how_ to build it.
- **Traceable:** linked to the need it serves and to whatever satisfies it.

## Functional vs non-functional

Two kinds, both needed:

- **Functional:** what the system _does_: "produce month-end exposure by entity."
- **Non-functional:** how _well_: performance, security, availability, controls: "the position must generate within N minutes," "changes to bank details require four-eyes approval."

In finance, the non-functional requirements around **accuracy, controls and period-end performance** are often where the real risk hides, and the ones most easily forgotten.

## The "testable" test

> The fastest way to spot a bad requirement: ask _how would we test it?_ "The report must be user-friendly" — how do you test that? It's not a requirement, it's a wish. "The report must generate within 30 seconds for a full month": testable, therefore real. If you can't describe the test, the requirement isn't finished.

## Requirements vs solutions

The most damaging habit is smuggling the _solution_ into the requirement. "Add a screen with these columns" isn't a requirement; it's a design decision wearing a requirement's clothes. State the need ("treasury must see exposure by entity") and leave the _how_ to design. This keeps the requirement stable if the design changes, lets the team find the best implementation, and is the same discipline as separating [problems from solution requests](https://gravam.com/blog/problem-statements-vs-solution-requests) at intake.

## Prioritize them

Not all requirements are equal, so prioritize, commonly as **must / should / could / won't** (MoSCoW). This is what lets [scope](https://gravam.com/blog/how-to-write-scope-in-and-scope-out) and [fit-gap](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) decisions be made on value rather than on whoever argued loudest. An unprioritized requirements list treats a nice-to-have as equal to a must-have, and that's how effort goes to the wrong places.

## Traceability

Every requirement should trace _backwards_ to the need it serves and _forwards_ to what's built and tested to satisfy it. Traceability is what lets you answer "why are we building this?" (back to a need) and "did we build everything we agreed?" (forward to delivery and [test](https://gravam.com/blog/testing-strategy-for-finance-systems)). A requirement that traces to no need is gold-plating; a need that traces to no requirement is a gap.

## Requirement defects that derail the build

- **Ambiguity.** Requirements read differently by different people, so the build is a coin-toss.
- **Untestable.** "User-friendly," "fast," "robust": wishes with no verifiable test.
- **Solution-prescribing.** Design decisions frozen as requirements, foreclosing better answers.
- **Gold-plating.** Requirements with no real need behind them, adding cost for nothing.
- **No prioritization.** Every requirement equal, so effort ignores value.
- **Orphans.** Requirements tracing to no need, or needs with no requirement: hidden waste and hidden gaps.

Write requirements that are clear, testable, necessary, solution-free and traceable; separate functional from non-functional; prioritize them; and keep them traceable both ways — and you remove the most common root cause of delivery failure before a line of anything is built. Requirements are what [fit-gap](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) assesses and [testing](https://gravam.com/blog/testing-strategy-for-finance-systems) verifies, so their quality sets the ceiling for everything that follows.

***

_See also [problem statements vs solution requests](https://gravam.com/blog/problem-statements-vs-solution-requests) and [testing strategy for finance systems](https://gravam.com/blog/testing-strategy-for-finance-systems)._

## Questions this article answers

**Q: What makes a good requirement?**

A good requirement is clear and unambiguous (only one interpretation), testable (you can verify whether it's met), necessary (it traces to a real business need), feasible, and solution-free (it states what's needed, not how to build it). It should also be traceable: linked to the need it serves and to whatever is built to satisfy it. Requirements that lack these qualities are the root cause of most delivery failures, because design, build and testing all inherit their flaws.

**Q: What is the difference between functional and non-functional requirements?**

A functional requirement describes what the system must do: a specific behaviour or capability, like 'produce a month-end exposure report by entity.' A non-functional requirement describes how well it must do it: qualities like performance, security, availability, or that a report must generate within a certain time. Finance systems need both: the functional requirements define the capabilities, and the non-functional ones (especially around controls, accuracy and performance at period-end) are often where the real risk lives.

**Q: Why should requirements not include the solution?**

Because baking the solution into the requirement forecloses better answers and confuses what's needed with one way of meeting it. 'The system must let treasury see exposure by entity' is a requirement; 'add a report screen with these five columns' is a solution. Stating the need without the design lets the team find the best implementation, keeps the requirement stable if the design changes, and makes it testable against the need rather than against one pre-chosen build.

---

# Change Management for Finance System Rollouts

Source: https://gravam.com/blog/change-management-for-finance-system-rollouts
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: A technically perfect finance system fails if the team won't adopt it. Change management wins that adoption — why finance resists, and how to get it.

**A technically perfect finance system fails if the accountants and treasury team don't actually use it.** Change management is the discipline of winning that adoption — the communication, training, involvement and support that get people using the new system as intended, rather than resisting it, working around it, or quietly reverting to the old spreadsheet. It's the "people side" of a project, and it's routinely under-resourced next to the technical build — which is exactly why so many technically sound finance systems deliver a fraction of their promised value. You don't get the benefit from a system that's _built_; you get it from a system that's _used_.

## What it is (and what it isn't)

Change management is about people adopting change. It's easy to confuse with **change _control_** — the process for handling [scope changes](https://gravam.com/blog/how-to-write-scope-in-and-scope-out) — but they're different disciplines. Change _control_ governs what the project builds; change _management_ governs whether the organization takes it up. This article is about the second.

## Why it matters

The benefit case for any finance system assumes people use it correctly and consistently. Every user who resists, works around, or reverts is a hole in that case:

> The most expensive finance-system failure isn't a system that doesn't work. It's a system that works perfectly and sits unused while the team keeps running the old spreadsheet in secret.

Adoption _is_ the benefit. A system nobody trusts or uses properly delivers nothing, however elegant the build.

## Why finance is especially resistant

Finance rollouts face resistance that many other systems don't:

- **Attachment to process and spreadsheets.** Finance teams often own carefully-built spreadsheets and hard-won processes, and giving them up feels like losing control and expertise.
- **Period-end pressure.** Hard, unmovable deadlines make any disruption genuinely risky — "we can't experiment during close" is a legitimate fear, not just obstinacy.
- **Professional risk-aversion.** Finance people are _paid_ to be careful with numbers; a healthy scepticism of a new system that produces the figures they're accountable for is rational.

Take these seriously. Dismissing them as mere resistance guarantees you'll trigger more of it.

## Why people resist

Resistance usually isn't stubbornness — it's a rational response to something real: a loss of control or status, fear of not being able to do the job in the new tool, or the simple fact that the transition period means _extra work_ on top of the day job. Name those honestly and you can address them. Pretend they don't exist and they harden.

## How to win adoption

- **Involve users early.** People support what they helped shape. Bring the actual [users into the process](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) — requirements, testing, design decisions — so it's _their_ system, not one done to them.
- **Communicate the why.** Explain the reason for the change and, crucially, _what's in it for them_ — less manual drudgery, fewer late nights at close. "Because we're told to" earns compliance, not adoption.
- **Train properly, and close to go-live.** Real training on realistic scenarios, timed so the skills are fresh at go-live — not a rushed session months before or a PDF nobody reads.
- **Support intensively through go-live.** Heavy [hypercare](https://gravam.com/blog/hypercare-and-post-go-live-stabilization), especially through the first period-end — the real test, and the moment doubt either resolves or calcifies.
- **Recruit champions.** Respected team members who adopt early and help peers are worth more than any amount of top-down mandate.

## Ownership underpins it

Adoption needs an [owner](https://gravam.com/blog/07-cost-of-unclear-ownership) — someone accountable for the organization actually using the system, not just for it being delivered. Without that, change management becomes nobody's job, gets cut under deadline pressure, and the project ships a system into a team that never truly takes it up.

## Why finance users fall back to the old way

- **Afterthought.** Change management bolted on at the end, when resistance has already set — instead of built in from the start.
- **Training too late or too little.** A token session that leaves users unable to do their job on day one, so they retreat to the old way.
- **No "why."** The change mandated without explaining the reason or the benefit, earning grudging compliance at best.
- **Ignoring resistance.** Treating legitimate concerns as obstruction, which deepens them.
- **No champions.** Relying on top-down instruction with no respected peers modelling adoption.

Involve people early, tell them the why, train them properly, support them through the first hard close, and give adoption a real owner — and change management turns a system that's merely delivered into one that's genuinely used. That's where [a finance system's benefit actually lives](https://gravam.com/blog/benefits-realization-for-finance-systems): not in the go-live, but in the quiet moment months later when nobody's opened the old spreadsheet in weeks. Keep one thing from this discipline when the system contains a model: users lose trust fastest when behaviour changes and nobody told them, which makes [versioning the prompt and the model](https://gravam.com/blog/prompt-and-model-versioning) as much a change-management artefact as a technical one.

***

_See also [cutover and go-live](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) and [the cost of unclear ownership](https://gravam.com/blog/07-cost-of-unclear-ownership)._

## Questions this article answers

**Q: What is change management in a system implementation?**

Change management is the discipline of getting people to actually adopt a new system — through stakeholder engagement, communication, training, early involvement and support — so the organization uses it as intended rather than resisting it, working around it, or reverting to old ways. It's the 'people side' of a project, distinct from the technical build, and it's what turns a delivered system into a used one. A technically excellent system with no adoption delivers none of its expected benefit.

**Q: Why is change management important for finance systems specifically?**

Because finance teams are often deeply attached to established processes and spreadsheets, work under hard period-end deadlines that make disruption risky, and are professionally risk-averse — all of which raise resistance to a new system. On top of that, the benefit of a finance system only materializes if people use it correctly and consistently; a treasury team that quietly keeps its old spreadsheet defeats the whole investment. Winning genuine adoption is therefore as important as building the system right.

**Q: How do you get people to adopt a new finance system?**

Involve the actual users early so they shape the system and own it, communicate clearly why the change is happening and what's in it for them, train properly and close to go-live so the skills stick, support intensively through go-live and the first period-end, and recruit respected team members as champions. The goal is for users to understand the reason, feel heard, be competent, and have help when they hit trouble — which is what converts reluctant compliance into real adoption.

---

# User Acceptance Testing for Finance Systems

Source: https://gravam.com/blog/user-acceptance-testing-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-09-02
Summary: UAT is where the people who'll use a finance system verify it does what they need, with real scenarios and reconciling numbers. Why finance UAT is different.

**User acceptance testing (UAT) is where the people who'll actually use the system verify it does what they need — with real business scenarios — before go-live.** It's the final check that the system is _fit for purpose_, not merely that it technically works. And in finance, that distinction is everything: a system where every button functions but the month-end numbers don't reconcile has passed technical testing and _failed_ the only test that matters. UAT is the business saying, on the record, "yes — this does the job," or catching the reason it doesn't while it's still cheap to fix.

## What UAT is — and isn't

UAT is often confused with technical or system testing. They answer different questions:

|  | System / technical testing | User acceptance testing |
| --- | --- | --- |
| **Asks** | Does the software work as built? | Does it solve the business problem? |
| **Run by** | Developers, QA, the project team | The actual end users |
| **Against** | Technical specs | Real business scenarios |
| **Passes when** | No defects | The business can do its job and signs off |

You need both. But passing system testing tells you the software functions; only UAT tells you it's the _right_ software, correctly configured for how the business actually runs.

## Why finance UAT is different

Most UAT can lean on click-through happy paths. Finance can't, for two reasons:

- **The numbers must reconcile.** A finance system's output isn't "a screen" — it's a position, a payment, a posting, a revaluation that has to _balance and tie back to source_. UAT has to check the numbers, not just the navigation.
- **The processes are periodic and real.** Month-end close, a payment run, a revaluation, a bank reconciliation — these are the scenarios that matter, and they only exercise the system properly with [realistic, well-managed test data](https://gravam.com/blog/test-data-management) and real period logic.

> The finance UAT test that catches the most: run a real prior period end-to-end and reconcile the system's output to the number you already know is right. If they don't match, you've found something a happy-path demo would have sailed straight past.

## What good UAT needs

- **Scenarios from real business processes** — the actual close, the actual payment run, the awkward intercompany case — not a generic script.
- **Realistic data** — enough volume and messiness that edge cases surface. Clean toy data hides the problems you'll hit live.
- **The actual users** — the analysts and accountants who'll operate it, whose judgement of "fit for purpose" is the one that counts.
- **Defined pass/exit criteria** — agreed _before_ UAT starts, so "done" is a standard, not a mood. The same discipline as the [go/no-go checklist](https://gravam.com/tools/cutover-go-live-checklist) that gates cutover.
- **A sign-off** — an explicit, accountable decision at the end.

## Scenarios, not just scripts

A test _script_ checks that a function works step by step; a test _scenario_ checks that a real piece of business can be completed end to end. Finance UAT needs the scenario level — "produce the month-end cash position from these statements and reconcile it" — because that's where configuration gaps and [fit-gap](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) shortcuts reveal themselves. Scripts prove the parts; scenarios prove the whole.

## Sign-off is a decision

The end of UAT is a **sign-off**, and it should be treated as a real decision by the [business owner accountable for the outcome](https://gravam.com/blog/07-cost-of-unclear-ownership) — not a signature collected to hit a milestone. Sign-off means: _we have tested this against how we really work, and we accept it into production, with these known limitations._ That last clause matters — sign-off with a clear-eyed list of accepted issues is honest; sign-off that pretends there are none is how known defects walk straight into go-live. And UAT sign-off says only that the system does the job — whether the organisation is ready to _run_ it is a separate bar, [operational readiness and acceptance](https://gravam.com/blog/operational-readiness-and-acceptance), deserving its own explicit decision.

## How UAT fails quietly

- **UAT as a demo.** The project team drives, the users watch and nod — so nothing is actually tested, and the real problems surface after [go-live](https://gravam.com/blog/cutover-and-go-live-for-finance-systems).
- **The wrong people.** Managers or IT test it instead of the day-to-day users, so "fit for purpose" is judged by people who won't live with it.
- **Happy-path only.** Clean data and the easy cases, so the messy real-world scenarios that break things are never tried.
- **No exit criteria.** No agreed definition of "passed," so UAT ends when time runs out, not when the system is ready.
- **Defects triaged into go-live.** Known problems reclassified as "post-go-live fixes" under deadline pressure — the ones that come back as production incidents.

Run real scenarios with real users and realistic data, check that the numbers reconcile, agree exit criteria up front, and treat sign-off as an accountable decision — and UAT becomes the safety net it's meant to be. Pass it honestly, and [cutover](https://gravam.com/blog/cutover-and-go-live-for-finance-systems) is the calm step it should be rather than the moment the untested truth arrives.

***

_See also [fit-gap analysis](https://gravam.com/blog/fit-gap-analysis-for-finance-systems) and [cutover and go-live](https://gravam.com/blog/cutover-and-go-live-for-finance-systems)._

## Questions this article answers

**Q: What is user acceptance testing (UAT)?**

User acceptance testing is the phase where the people who will actually use a system verify it does what they need, using real business scenarios — the final check before go-live that the system is fit for purpose, not merely technically working. Unlike system or technical testing, which confirms the software functions as built, UAT confirms it solves the business problem, and it ends in an explicit sign-off from an accountable business owner.

**Q: Why is UAT different for finance systems?**

Because finance runs on real, reconciling numbers and periodic processes. Finance UAT can't just click through happy paths — it has to run genuine close, payment, revaluation and reconciliation scenarios with realistic data, and the outputs have to actually balance and tie back to source. A finance system that 'works' in a demo but produces numbers that don't reconcile has failed UAT, even if every button functions.

**Q: Who should perform user acceptance testing?**

The actual business users who will operate the system day to day — the treasury analysts, accountants and controllers — not the project team, IT, or the vendor testing their own build. UAT only means something when it's done by the people whose judgement of 'fit for purpose' is the one that counts, against scenarios drawn from their real work, ending in sign-off by the business owner accountable for the outcome.

---

# Fit-Gap Analysis for Finance Systems

Source: https://gravam.com/blog/fit-gap-analysis-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: A fit-gap analysis compares what a standard system does against what the business needs — fit, gap, or change the process. Avoiding the customization trap.

**A fit-gap analysis compares what a standard system does out of the box against what the business actually needs — classifying each requirement as a _fit_, a _gap_, or a case to _change the process_.** It's how an implementation decides [what to configure, what to build](https://gravam.com/blog/configuration-vs-customization-finance-systems), and — most importantly — what to _not_ build by adapting the business instead. Done honestly, it's the single biggest lever on the cost, timeline and long-term maintainability of a finance system. Done as a formality, it's where over-customization quietly begins.

## What it is

Every packaged finance system does a great deal as standard. A fit-gap analysis is the structured comparison of _that standard capability_ against _your requirements_, requirement by requirement:

- **Fit** — the standard meets it, typically through configuration. No build needed.
- **Gap** — the standard doesn't meet it as-is. You'll need to configure heavily, build something custom, adopt a workaround, or…
- **Change the process** — the third, most-underused option: adapt the business process to the standard instead of bending the system to the process.

## The third option is the point

Most teams treat fit-gap as a binary — it fits or we build it. The valuable move is the _third_ column: some gaps exist only because "we've always done it this way," and the honest answer is to change the way, not the software.

> Every gap you close by building is a cost you pay once to create and forever to maintain. Every gap you close by changing the process is paid once. The art of fit-gap is telling those two apart.

Not every process is sacred, and standard software often encodes a better practice than the local habit it's replacing. Reserve customization for where your process is a genuine, defensible differentiator — not for where it's merely familiar.

## Why it matters

Fit-gap controls three things at once:

- **Scope** — it turns "make it do what we need" into a concrete, decided list.
- **Cost** — configuration is cheap; custom build is expensive to create, test, document and maintain.
- **Risk** — heavy customization is what makes systems fragile, hard to upgrade, and expensive to change later.

The [outcome and scope](https://gravam.com/blog/how-to-write-scope-in-and-scope-out) you agreed at intake are the reference point: a gap only matters to the extent it blocks the agreed outcome.

## How to run one

1. **Start from [agreed requirements](https://gravam.com/blog/how-to-write-good-requirements-for-finance-systems).** Vague requirements produce a vague fit-gap. This is why the [shaping work](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) upstream matters.
2. **Assess the standard.** Through demos, a prototype, or deep product knowledge, establish honestly how the standard meets each requirement.
3. **Classify** every requirement: fit, gap, or process-change.
4. **Decide each gap** — configure, build, work around, or change the process — with the business in the room.
5. **Log the decision and its rationale.** The output is a _decision log_, not a list of gaps someone will re-argue in UAT.

## Classifying gaps well

Not all gaps are equal. Two axes matter:

|  | Must-have | Nice-to-have |
| --- | --- | --- |
| **Cheap to close** | Do it | Maybe |
| **Expensive to close** | Weigh hard — is a process change or workaround acceptable? | Almost always drop or defer |

A "must-have" that's expensive to build deserves the hardest scrutiny: is it _truly_ must-have, or is it a strong preference wearing a must-have label? That conversation, held now, is worth ten times what it costs.

## The customization trap

The most common way finance implementations go wrong is a thousand small "yes, we can build that." Each gap closed by custom code seems reasonable alone; together they produce a system that's expensive to run, painful to upgrade, and understood by no one. Standard-first isn't dogma — it's the recognition that _custom is a permanent liability_, so it should be spent deliberately, on the few gaps that genuinely warrant it.

## Fit-gap mistakes that surface in UAT

- **Fit-gap as a formality.** A spreadsheet filled in to tick a milestone, with no real decisions — so the gaps resurface, uncosted, in build and UAT.
- **Everything is a gap.** No appetite to change any process, so every local habit becomes a customization.
- **Gaps discovered late.** A weak fit-gap, so "the standard doesn't do that" is discovered in [UAT](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) — the most expensive place to learn it.
- **Nice-to-haves built as must-haves.** No honest must/nice classification, so cost goes where preference is loudest, not where value is highest.

Compare standard against need, use all three responses (fit, build, _change the process_), classify gaps by value and cost, and log the decisions — and fit-gap becomes the moment you take control of scope and cost, rather than the formality where you quietly lose it. What you decide here is what UAT will later verify actually works.

***

_See also [writing scope in and scope out](https://gravam.com/blog/how-to-write-scope-in-and-scope-out) and [user acceptance testing](https://gravam.com/blog/user-acceptance-testing-for-finance-systems)._

## Questions this article answers

**Q: What is a fit-gap analysis?**

A fit-gap analysis compares what a standard system does out of the box against what the business actually needs, and classifies each requirement as a fit (the standard covers it), a gap (it doesn't, so you configure, build, or work around it), or a case where the business process should change to match the standard. It's how an implementation decides what to configure, what to build, and what to adapt — before committing to a design.

**Q: How do you perform a fit-gap analysis?**

Take the agreed requirements, assess how the standard system meets each one (through demos, prototypes or product knowledge), and classify every requirement as fit, gap or process-change. For each real gap, decide the response — configure, build a customization, adopt a workaround, or change the business process — weighing must-have against nice-to-have and one-off cost against the permanent cost of custom code. The output is a decision log, not just a spreadsheet of gaps.

**Q: What is the difference between a fit and a gap?**

A fit is a requirement the standard system already meets, usually through configuration alone. A gap is a requirement the standard doesn't meet as-is — closing it needs custom development, a workaround, or a change to the business process. The discipline of fit-gap is being honest about which is which, and resisting the urge to turn every 'we've always done it this way' into a gap that must be built.

---

# Cutover and Go-Live for Finance Systems

Source: https://gravam.com/blog/cutover-and-go-live-for-finance-systems
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: Finance system cutover is the tightly-planned transition from old to new — migration, switchover, go-live — in a short, high-stakes window.

**Cutover is the [tightly-planned transition](https://gravam.com/blog/agile-vs-waterfall-for-finance-systems-delivery) from the old system to the new one — migrating the data, switching over, and going live — usually inside a short, high-stakes window.** Go-live is the moment within it when the new system becomes the system of record. For finance systems, cutover is dominated by two things: getting the _opening balances exactly right_, and timing the whole thing around _period-end_ so the books are clean. It's the phase where months of good work are either landed safely or undone in a weekend — which is why it's run from a rehearsed runbook, not improvised.

## What cutover and go-live are

Cutover is the _sequence_ that takes you from "built and [tested](https://gravam.com/blog/user-acceptance-testing-for-finance-systems)" to "live, old system retired." Go-live is the _point of no return_ inside that sequence — gated by a formal go/no-go decision. Everything before go-live is reversible; everything after commits you to the new system for real.

## Why finance cutover is high-stakes

Most systems start empty. Finance systems start with the entire past carried forward:

- **Opening balances must be exact.** Every account balance in the new system has to tie, to the penny, to the old one at the cut. A wrong opening balance corrupts every report from day one.
- **Open items can't be lost.** In-flight invoices, unreconciled payments, open deals — miss one and it simply vanishes from the books, surfacing months later as an unexplained difference.
- **The window is narrow.** Finance cuts over around a period boundary, so the migration, reconciliation and checks are compressed into the few days the books are quiet.

> Most systems go live empty and fill up. Finance systems go live _full_ — with every balance and open item carried across — which is why the migration, not the software, is where cutover succeeds or fails.

## The cutover plan is a runbook

A cutover plan is not a milestone in a Gantt chart — it's a **runbook**: a minute-by-minute sequence of tasks, each with a timing, an owner, a dependency, and a done-check. "Extract balances from legacy (Fri 18:00, owner: X), load to new (Fri 20:00, owner: Y), reconcile (Sat 09:00, owner: Z)…" The plan's job is that on the day, nobody is improvising — they're executing a script that's already been proven. Dependencies on other teams, banks or vendors that could block a step belong on the programme's [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) weeks before cutover weekend, not in the runbook's margin.

## Data migration is the core

The bulk of finance cutover is [data migration](https://gravam.com/blog/tms-data-migration), in three layers:

- **Master data** — accounts, entities, bank details, counterparties, standing instructions. Migrated and validated _first_.
- **Opening balances** — the carried-forward position at the cut.
- **Open items** — the in-flight transactions that must continue their life in the new system.

And the non-negotiable rule: **reconcile every migrated layer.** Migration isn't done when the data loads; it's done when the loaded data is proven equal to the source. Counts and control totals, source versus target, exactly as with any [interface](https://gravam.com/blog/interface-monitoring-and-reconciliation).

## Timing around period-end

Finance cuts over at a **period boundary** — ideally right after a close — so there's a clean line: the old system owns everything up to the cut, the new system owns everything after. Cutting over mid-period means splitting a period across two systems, which turns [the first close](https://gravam.com/blog/hypercare-and-post-go-live-stabilization) into a reconciliation nightmare. Pick the boundary, and protect it.

## The go/no-go decision

Before go-live, a **go/no-go** checkpoint: against pre-agreed criteria — migration reconciled, critical checks passed, [UAT signed off](https://gravam.com/blog/user-acceptance-testing-for-finance-systems), [operational readiness proven](https://gravam.com/blog/operational-readiness-and-acceptance) — the accountable owners decide, explicitly, to proceed or not: a [governance decision](https://gravam.com/blog/governance-and-steering-for-finance-programmes) in its own right. The value is having defined the criteria _in advance_, so the decision is made against a standard, not against how tired everyone is at 2am. The same discipline transfers, almost unchanged, to promoting an AI step into production — see [what a pilot has to prove first](https://gravam.com/blog/ai-pilot-exit-criteria).

## Rehearse it, and plan the fallback

Two things separate calm cutovers from disasters:

- **A dress rehearsal.** At least one full **mock cutover** on a copy — run the entire runbook end to end, time it, find what breaks. The real cutover should be the _second_ time you've done it, not the first.
- **A fallback plan.** A defined way back if go/no-go fails or something breaks past the point of proceeding. Knowing you _can_ revert is what makes the go decision safe to take.

## Hypercare after go-live

Go-live isn't the end — it's the start of **hypercare**: a period of heightened support right after, when the real users hit real edge cases and need fast help. Staff it deliberately. The first close on the new system is the true test, and it's where issues the whole project missed finally show up.

> **Figure — The cutover sequence, from built and tested to old system retired**
>
> A rehearsed mock cutover and a reconciled three-layer migration precede a go/no-go decision. Go-live is the point of no return, after which hypercare runs until the old system is retired.
>
> Everything before go-live is reversible; everything after commits you to the new system for real.

## What goes wrong on cutover weekend

- **Unrehearsed cutover.** The runbook's first real run _is_ the live one, so the surprises land at the worst possible moment.
- **Unreconciled migration.** Data loaded but not proven equal to source, so a wrong opening balance is discovered weeks later in the books.
- **No go/no-go criteria.** The decision to proceed is made on optimism and fatigue, not evidence.
- **No fallback.** No way back, so a failing cutover has to be pushed forward regardless.
- **Cutting over mid-period.** No clean boundary, so the first close spans two systems and reconciles to nothing.

Run cutover from a rehearsed runbook, migrate and _reconcile_ every layer, cut at a period boundary, gate go-live with real go/no-go criteria, keep a fallback, and staff hypercare — and the riskiest weekend of the project becomes a controlled, boring success. Which, for a finance go-live, is exactly what you want it to be.

**Work the gate:** the free [Cutover & Go-Live Readiness Checklist](https://gravam.com/tools/cutover-go-live-checklist) turns this into a live go/no-go — the critical items gate the verdict, and it never shows GO until open items are owned and an authorized owner has actually decided.

***

_See also [user acceptance testing](https://gravam.com/blog/user-acceptance-testing-for-finance-systems) and [fit-gap analysis](https://gravam.com/blog/fit-gap-analysis-for-finance-systems)._

## Questions this article answers

**Q: What is cutover in a system implementation?**

Cutover is the tightly-planned transition from the old system or process to the new one — migrating the data, switching over, and going live — usually within a short, high-stakes window. It's the sequence of steps that takes you from 'the new system is built and tested' to 'the new system is live and the old one is retired,' and it's governed by a detailed runbook of tasks, timings and owners.

**Q: What is the difference between cutover and go-live?**

Cutover is the whole transition process — the migration, the switchover steps, the reconciliation, the checks. Go-live is the specific moment within it when the new system becomes the system of record and the business starts using it for real. Cutover is the journey; go-live is the point of no return along it, usually gated by a formal go/no-go decision.

**Q: Why is cutover so critical for finance systems?**

Because finance carries balances forward, so the opening position in the new system has to be exactly right — every account balance, every open item, every in-flight payment migrated and reconciled to the penny. A lost open invoice or a wrong opening balance corrupts the books from day one and can take months to unwind. Finance cutover is also timed tightly around period-end to get a clean cut, which compresses everything into a narrow, unforgiving window.

---

# How to Write Scope In and Scope Out

Source: https://gravam.com/blog/how-to-write-scope-in-and-scope-out
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-02
Summary: Scope defines what work includes and — crucially — excludes. The 'out of scope' list is the half that prevents scope creep. How to define it from the outcome.

**Scope defines what the work includes and — just as importantly — what it excludes.** The "in scope" list is the obvious half; the **"out of scope" list is the one that actually protects you.** Scope creep and the "but I assumed that was included" argument almost always come from things that were never explicitly excluded. Anchor scope to the outcome, write both halves, and you've turned a fuzzy expectation into an agreed boundary.

## In scope and out of scope

- **In scope** — what will be delivered. What the work includes.
- **Out of scope** — what will _not_ be delivered, stated explicitly. What the work excludes, even if it's reasonable, related, or someone assumed it.

Most scope documents write the first list and skip the second. That's exactly backwards: the second list is where the value is.

## Why "out of scope" is the half that matters

If you only say what's _in_, everyone fills the silence with their own assumptions — exactly what the A in a [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) exists to write down — and every stakeholder assumes their reasonable-sounding extra is included. Then, mid-delivery, the requests arrive: "and it'll handle the other entity too, right?" You have nothing to point to, so you either absorb the creep or have an awkward fight.

An explicit out-of-scope list does three things: it makes the boundary visible, it forces the hard conversations _early_ (when "no, that's out" is cheap), and it gives you a concrete reference when a new ask appears later.

> Scope creep isn't caused by new requests. It's caused by boundaries that were never drawn — so every request looks like it was always included.

## How to define scope from the outcome

Scope falls out of the [outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome). The test for every candidate item is simple:

> Is this genuinely needed to reach the agreed outcome?

- **Yes** → in scope.
- **No** → out of scope, at least for now — however reasonable it sounds.

This keeps scope tied to what actually matters and stops the drift toward "while we're in there, let's also…" that quietly doubles the work.

## An example

**Outcome:** "Month-end exposure by entity is produced automatically and reconciles first time."

- **In scope:** exposure by entity; the automated month-end feed; reconciliation to the source.
- **Out of scope:** exposure by counterparty (next phase); intraday/real-time exposure; currencies beyond the group's top five; a redesign of the underlying data model.

Now, when someone asks for counterparty exposure mid-build, it's not a fight — it's a scope change to be decided, because you already said it was out.

## Handling scope changes

Out-of-scope isn't "never" — it's "not in this piece of work." When a genuine new need appears, treat it as a **scope change**: name it, decide it explicitly (does it change the outcome, the date, the effort?), and either bring it in with eyes open or park it. What you're avoiding is scope changing by _silent absorption_, where the boundary erodes one reasonable request at a time until the work is unrecognizable and late.

## How scope boundaries leak

- **No out-of-scope list.** Only "in scope" is written, so every assumption is "in" until proven otherwise.
- **Gold-plating.** "While we're here, let's also…" — scope grows toward what's interesting, not what's needed.
- **Scope by omission.** Boundaries that exist only in one person's head, so different people hold different scopes.
- **Silent absorption.** New requests folded in without a decision, so the date slips and no one can say when it happened.

Write both halves, anchor them to the outcome, agree them with the requester and the team, and treat additions as decisions — and scope stops being the thing that quietly sinks the delivery. This is why [Delivery Sheet](https://gravam.com/products/delivery-sheet) makes scope-in and scope-out explicit fields: the boundary is drawn before the work starts, not argued about after.

***

_See also [defining a measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome) and the [project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams)._

## Questions this article answers

**Q: What is scope in and scope out?**

'Scope in' is what the work explicitly includes; 'scope out' is what it explicitly excludes. Writing both — especially the out-of-scope list — sets a clear boundary so everyone agrees on what will and won't be delivered. The out-of-scope half is what prevents scope creep and the 'but I assumed that was included' conversation later.

**Q: Why is defining out-of-scope important?**

Because scope creep and misaligned expectations usually come from things that were never explicitly excluded. If you only list what's in, people assume everything reasonable-sounding is also in. An explicit out-of-scope list makes the boundary visible, forces the hard conversations early, and gives you something concrete to point to when a new request arrives mid-delivery.

**Q: How do you define project scope?**

Anchor it to the outcome. Everything genuinely needed to reach the agreed outcome is in scope; everything else — however reasonable it sounds — is out, at least for now. Write both lists explicitly, get them agreed by the requester and the team, and treat later additions as scope changes to be decided, not silently absorbed.

---

# How to Define a Measurable Outcome

Source: https://gravam.com/blog/how-to-define-a-measurable-outcome
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-19
Summary: A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.

**A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity.** "Treasury sees group cash intraday without touching a spreadsheet" is an outcome. "Build a cash dashboard" is an activity. The difference matters because teams that commit to activities can complete every task and still fail — the dashboard shipped, and treasury is still rebuilding the position by hand. An outcome tells everyone what success actually looks like, and lets you prove whether you got there.

## Outcome vs output

An **output** is what you produce: a report, a feature, a system. An **outcome** is the change that output is meant to create. They're easy to confuse and expensive to confuse:

|  | Output | Outcome |
| --- | --- | --- |
| **Is** | What you delivered | The result it created |
| **Example** | "The exposure report is live" | "Month-end exposure is right first time, no manual rebuild" |
| **You can** | Tick it done | Verify it mattered |

You can hit every output and miss the outcome. That's the whole reason to define the outcome first.

## What makes an outcome measurable

Three things:

- **Specific** — a concrete end state, not "better" or "improved."
- **Observable** — you can point at something and say whether it's true.
- **Tied to the problem** — it resolves the actual pain, not a proxy for it.

> The test: _how would you know?_ If you can describe how you'd verify the outcome — a number, a behaviour that changed, a thing that no longer happens — it's measurable. If the honest answer is "we'd just kind of feel it's better," it isn't an outcome yet.

## How to write one, from the problem

The outcome falls out of a well-stated [problem](https://gravam.com/blog/problem-statements-vs-solution-requests). Take the problem, describe the world once it's solved, and phrase it as something observable:

- **Problem:** "Treasury rebuilds month-end exposure by hand; it's slow and error-prone."
- **Outcome:** "Month-end exposure by entity is produced automatically and reconciles first time, without a manual rebuild."

Notice the outcome names _no solution_ — not a report, not a system. That's deliberate: it leaves room for the best answer — the same solution-free discipline that keeps [a requirement testable](https://gravam.com/blog/how-to-write-good-requirements-for-finance-systems) — and it's what you'll measure regardless of how you build it.

## Leading, lagging and proxy measures

Some outcomes are directly measurable (a number, a cycle time). Others are harder, and you use a **proxy** — an observable signal that stands in for the real result. That's fine, as long as you're honest that it's a proxy and it genuinely tracks the outcome. What you're avoiding is a _vanity_ measure — something easy to move that doesn't reflect the real change (usage of a feature nobody needed, say).

## An example

- **Vague:** "Improve the cash forecasting process." Not measurable — you can't tell when you're done.
- **Measurable:** "The two-week cash forecast is produced weekly with no manual spreadsheet consolidation, and forecast accuracy at the one-week horizon is tracked and improving." Now everyone knows the target and can verify it.

## Outcomes that are really outputs

- **Activity disguised as outcome.** "Deliver the new module" — that's an output; the outcome is what the module changes.
- **Unmeasurable outcomes.** "Make it better" — no way to know if you succeeded, so scope and success float.
- **Vanity measures.** Optimizing something easy to move that doesn't reflect the real result.
- **No owner for the outcome.** A measurable outcome with [no one accountable for it](https://gravam.com/blog/07-cost-of-unclear-ownership) still slips.

Define the outcome first, make it observable, tie it to the problem — and you've given the work a target everyone can aim at and verify. That's exactly the field [Delivery Sheet](https://gravam.com/products/delivery-sheet) forces next to the problem: what's true when this is done, and how you'll know.

***

_See also [problem statements vs solution requests](https://gravam.com/blog/problem-statements-vs-solution-requests), the [project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams), and the same discipline applied to an AI redesign: [how to measure ROI from an AI workflow](https://gravam.com/blog/how-to-measure-roi-from-an-ai-workflow)._

## Questions this article answers

**Q: What is a measurable outcome?**

A measurable outcome states what will be true when the work is done, in a way you can actually verify — a result, not an activity. 'Treasury sees group cash intraday without touching a spreadsheet' is an outcome; 'build a cash dashboard' is an activity. A good outcome is specific, observable, and tied to the problem, so everyone knows what success looks like and can tell whether it was reached.

**Q: What is the difference between an outcome and an output?**

An output is what you produce — a report, a feature, a system. An outcome is the result that output is supposed to create — the change in the world that means the work mattered. 'We delivered the dashboard' is an output; 'treasury no longer rebuilds the position by hand' is the outcome. Teams that measure outputs can complete every task and still fail the outcome.

**Q: How do you write a good outcome statement?**

Start from the problem, describe the desired end state as something observable, and make sure you could tell whether it's true. Avoid naming the solution or the activity. 'Month-end exposure is produced automatically and reconciles first time' is measurable; 'improve the exposure process' is not. If you can't say how you'd verify it, it isn't yet an outcome.

---

# Project Intake Process for Finance and Engineering Teams

Source: https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Updated: 2026-07-29
Reviewed: 2026-08-18
Summary: How a team receives, shapes and decides on incoming work before committing people: the stages, the fields that matter, and four honest decisions.

**A project intake process is how a team receives, shapes and decides on incoming work — before it commits people to it.** It captures the raw request, clarifies the problem, outcome, scope and owner, and then makes an explicit decision: commit, shape further, pause or decline. Its whole purpose is to turn vague demands into decisions, so teams commit to clear work instead of starting on a half-understood ask and discovering what it meant in delivery.

For finance and engineering teams, where requests arrive constantly and each looks urgent, a good intake is the difference between a roadmap you chose and a queue that chose you.

## What a project intake process is

Intake is the step _before_ delivery and _before_ commitment. A request comes in; intake makes sure it's understood well enough to decide on, and then decides. Done well it's fast (minutes, not meetings) and it produces two things: a shaped, decision-ready version of the request, and an explicit decision about it.

## Why teams need one

Without intake, this is the default flow: a request lands as a one-liner, someone says "sure, we can do that," and a nod becomes a commitment before anyone knows the scope, the owner or what success looks like. The bill arrives weeks later as rework, a scope fight, or a slipped date, and it traces straight back to that first thirty seconds. (I've written about exactly [why teams commit before the request is clear](https://gravam.com/blog/05-commit-before-clear).)

> The purpose of intake isn't bureaucracy. It's to make the shaping and the decision explicit and fast — so "yes" is a choice, not a reflex, and "no" happens on purpose, not by neglect.

## The stages of a good intake

Three stages, each quick:

1. **Capture.** Record the request as it actually arrived (the Slack message, the email, the hallway ask) so nothing is lost or paraphrased away. ([Turning that raw ask into something decision-ready](https://gravam.com/blog/06-slack-request-to-initiative) is the core skill.)
2. **Shape.** Clarify the few things that make it decidable, with the requester rather than in isolation. This is where a vague request either becomes clear or reveals that it isn't ready.
3. **Decide.** Make one of four explicit calls (below). The output isn't "it's on the backlog"; it's a decision.

## The fields that make a request decision-ready

You don't need thirty fields. You need these, filled honestly:

- **Problem:** what's actually broken, not the solution someone jumped to.
- **Outcome:** what's true when this is done; how you'll know it worked.
- **Scope:** what's explicitly in, and just as importantly, out.
- **Owner:** one name accountable for the outcome. If it's a team, it's [no one](https://gravam.com/blog/07-cost-of-unclear-ownership).
- **Open questions:** the things you don't know yet. This field is the point; a request with none usually hasn't been looked at hard enough.

## The four decisions

A healthy intake has four outcomes and picks one on purpose:

- **Commit:** clear, owned, worth doing now. Commit with real scope and a real date.
- **Shape further:** matters, but not ready; an open question is big enough to change the plan.
- **Pause:** a good idea at the wrong time; park it honestly with a revisit date.
- **Decline:** the problem isn't real, isn't worth the cost, or is someone else's job. Say no early, with a reason.

The discipline is _forcing the choice_, instead of "yes by default, no by neglect."

## The intake one-pager (steal this)

Everything above fits on one page. This is the whole template: copy it, paste the raw request at the top, and fill the rest _with the requester_. If you can't complete it in a short conversation, that's the signal the request isn't ready to commit to.

```text
Raw request:  <paste the Slack message / email / hallway ask, verbatim>

Problem:      <what's actually broken — not the solution someone jumped to>
Outcome:      <what's true when this is done, and how you'll know it worked>
Scope — in:   <what this explicitly includes>
Scope — out:  <what it explicitly does NOT include>
Owner:        <one name accountable for the outcome>
Open Qs:      <what you don't know yet — the field that earns its place>

Decision:     Commit  |  Shape further  |  Pause  |  Decline
Reason:       <one line — why this decision, on purpose>
Revisit:      <date, if Paused or Shape further>
```

Six fields and a decision. Anything more is intake theatre; anything less isn't decision-ready.

> Prefer to fill it in on screen? Use the free [**intake one-pager generator**](https://gravam.com/tools/project-intake-one-pager): type into the fields and it builds the one-pager live, ready to copy or download. Nothing you enter leaves your browser.

## How intake processes die

- **No intake at all.** Requests become commitments in the moment they're received.
- **Intake theatre.** A heavy form no one fills in properly, so it's bypassed and you're back to one-liners.
- **Yes by default.** Everything is accepted onto a backlog, and "no" never actually gets said; it just rots.
- **Shaping in isolation.** Guessing the problem and outcome without the requester, so the shaped version is as wrong as the original.

## Making it lightweight

Intake fails when it's heavy. Keep it to the few fields that make a request decidable, shape _with_ the requester, and make the decision explicit and quick. The goal is decision-readiness, not documentation: a five-minute shaping conversation that saves a six-week wrong build.

This is exactly the problem [Delivery Sheet](https://gravam.com/products/delivery-sheet) is built for: capture a raw request and shape it into a decision-ready one-pager (problem, outcome, scope, owner, [open questions](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies)) so you decide with eyes open instead of committing to a sentence.

***

_See also [why teams commit before the request is clear](https://gravam.com/blog/05-commit-before-clear), [problem statements vs solution requests](https://gravam.com/blog/problem-statements-vs-solution-requests), and how the same process looks when redesigned around AI: [the anatomy of an AI-native workflow](https://gravam.com/blog/anatomy-of-an-ai-native-enterprise-workflow)._

## Questions this article answers

**Q: What is a project intake process?**

A project intake process is the defined way a team receives incoming requests, shapes them into something clear enough to decide on (problem, outcome, scope and owner), and then makes an explicit decision: commit, shape further, pause or decline. It sits before delivery and before commitment, and its job is to turn vague demands into decisions rather than letting work start on a half-understood ask.

**Q: Why do teams need a project intake process?**

Because without one, requests arrive as one-liners, get an informal 'yeah, we can do that,' and become commitments before anyone knows the scope, owner or success measure. That drives rework, scope fights and slipped dates. A good intake makes the shaping and the decision explicit and quick, so teams commit to clear work (or decline it early) instead of building against a guess.

**Q: What should a project intake process capture?**

At minimum: the raw request as received, the problem it's really solving, the outcome that defines success, what's in and out of scope, who owns the outcome, and the open questions. Those few fields are enough to make an honest decision. The goal is decision-readiness, not a thirty-field form that no one fills in properly.

---

# Problem Statements vs Solution Requests

Source: https://gravam.com/blog/problem-statements-vs-solution-requests
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-07-23
Reviewed: 2026-08-09
Summary: A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.

**A solution request tells you _what_ to build; a problem statement tells you _why_.** "Add a report showing exposure by entity" is a solution. "Treasury rebuilds exposure by hand every month-end and it's error-prone" is the problem behind it. Converting the solutions people ask for back into the problems they're actually solving is the single highest-leverage move in project intake — because a solution built without understanding its problem is how teams confidently deliver the wrong thing.

## The difference

People almost never bring you a problem. They bring you a solution — the first answer that occurred to them — phrased as a request. That's natural, but it's a trap: the requested solution is _one_ answer to a problem you haven't seen yet, and it's often not the best one. The problem statement is the thing underneath: what's broken, for whom, and why it matters.

|  | Solution request | Problem statement |
| --- | --- | --- |
| **Answers** | What to build | What's wrong and why |
| **Example** | "Add an exposure-by-entity report" | "Treasury rebuilds exposure by hand at month-end; it's slow and error-prone" |
| **Fixes** | One pre-chosen answer | The underlying need |
| **Lets you** | Build what was asked | Choose the best answer, or decline |

## Why requests arrive as solutions

Because it's how people think. Someone hits a pain, jumps to a fix, and asks for the fix. By the time it reaches you, the problem has been silently compressed into a solution — and if you build the solution, you've inherited their compression, including whatever they got wrong on the way. The request _feels_ actionable, which is exactly why it's dangerous.

## How to convert a solution into a problem

Work backwards from the request with a few questions, ideally _with the requester_:

- **What's the problem this solves?** ("Why do you need the report?")
- **Who has this problem, and how often?** (One analyst monthly, or the whole team daily?)
- **What breaks if we don't do it?** (The cost of inaction — often the real justification.)
- **What are you doing today instead?** (The current workaround reveals the true need.)
- **Keep asking "why"** until you reach something that isn't a solution.

> The tell that you've reached the problem: you can no longer answer "why?" with another feature. "Add a report" → why? → "to see exposure" → why? → "because we hold too much cash as a buffer and miss investment yield." _That_ is the problem — and it might be solved by something other than a report.

## An example

Take the real-sounding request: _"Can we add a report that shows treasury exposure by entity? Finance keeps asking."_

- **As a solution:** you build an exposure-by-entity report. Six weeks later it's the wrong report.
- **As a problem:** you ask why. It turns out finance doesn't need a _report_ — they need the month-end exposure number to stop being wrong, because today it's [rebuilt by hand and errors slip through](https://gravam.com/blog/03-finance-team-friction). The best answer might be fixing the source data, or an automated feed — not a report at all.

Same request, completely different — and much better — outcome. (This is the shift from [a raw ask to a decision-ready initiative](https://gravam.com/blog/06-slack-request-to-initiative).)

## When the solution really is the request

Occasionally the requester _has_ done the analysis and the solution is genuinely the right, well-understood answer — a specific compliance requirement, a known integration. Fine: confirm the problem quickly and move on. The point isn't to interrogate every request to death; it's to _not build a solution whose problem no one has checked._

## When a solution request gets built as asked

- **Building the solution as stated.** Delivering exactly what was asked for, and discovering it didn't solve the problem.
- **Skipping the requester.** Guessing the problem yourself instead of asking, so you invent a different wrong problem.
- **Interrogation theatre.** Turning "what's the problem?" into a bureaucratic gate that annoys people, instead of a two-minute conversation.
- **Naming a solution in the "problem."** Writing "we need a dashboard" and calling it a problem statement. If it names a build, it's still a solution.

Convert the solution back to the problem, and three good things happen: you often find a simpler answer, you can tell whether it's worth doing at all, and you can define [a measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome) for it. Skip it, and you build precisely what was asked — and precisely the wrong thing. (To capture the converted request as a decision-ready page, the [intake one-pager generator](https://gravam.com/tools/project-intake-one-pager) does it live in the browser.)

This is the core of what [Delivery Sheet](https://gravam.com/products/delivery-sheet) does: it makes the problem, not the requested solution, the first field you fill in.

***

_See also the [project intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) and [turning a Slack request into an initiative](https://gravam.com/blog/06-slack-request-to-initiative)._

## Questions this article answers

**Q: What is the difference between a problem statement and a solution request?**

A solution request tells you what someone wants built — 'add a report showing exposure by entity.' A problem statement tells you what's actually wrong and why it matters — 'treasury rebuilds exposure by hand every month-end and it's error-prone.' The solution is one possible answer; the problem is the thing that actually needs solving, and it usually has better answers than the first one someone thought of.

**Q: Why should you turn a solution request into a problem statement?**

Because building the requested solution without understanding the problem is how teams deliver the wrong thing. When you know the real problem, you often find a simpler or better solution than the one requested, you can tell whether it's even worth doing, and you can measure success. Converting solutions back to problems is the single highest-leverage step in intake.

**Q: How do you write a good problem statement?**

State what's wrong today, who it affects, and why it matters — concretely, with the cost or pain, and without naming a solution. 'Finance can't see group cash intraday, so they hold excess buffers and miss investment opportunities' is a problem statement. 'Build a cash dashboard' is a solution. Keep asking 'why' and 'what breaks if we don't' until you reach the underlying need.

---

# The cost of unclear ownership in enterprise delivery

Source: https://gravam.com/blog/07-cost-of-unclear-ownership
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-06-18
Reviewed: 2026-08-19
Summary: When no one owns the outcome, delivery slips in the seams — invisibly on every status report, until it's too late to fix cheaply.

In a large finance transformation, everyone owns a **task** and no one owns the **outcome**. That gap is where projects quietly go wrong — the most expensive pattern in [finance systems delivery](https://gravam.com/topics/finance-systems-delivery), and the least visible.

## Tasks are owned. Outcomes are orphaned.

Ask who owns a task and you get a name instantly: "Ayşe owns the interface build." Ask who owns the outcome — "month-end close is a day faster" — and you get a pause, then a committee. A RACI chart with three people accountable for one line is a chart with none.

Task ownership _feels_ like accountability. It isn't. You can complete every task on the plan and still miss the outcome, because the failures live in the gaps between tasks: the integration nobody scoped, the edge case in intercompany elimination, the assumption two teams each thought the other owned. A [RAID log](https://gravam.com/blog/raid-log-risks-assumptions-issues-dependencies) with a named owner on every line is the cheapest way to close those gaps. The free [RAID log template](https://gravam.com/tools/raid-log-template) gives you one to start from.

> You can finish every task on the plan and still miss the outcome — because the outcome was never on the plan.

## The slip is invisible until it's red

This is what makes unclear ownership so expensive: it stays green until it's red. Every task tracks to plan. Every team reports "on track." The outcome slips anyway, in the seams, and no single status line ever turned amber to warn you. The first real signal is a stakeholder at UAT saying "this isn't what we needed" — long after the cheap moment to fix it has passed.

## Name the outcome owner before the work

The fix is unglamorous: for every initiative, name one person accountable for the **outcome** — not the task list — before anything is committed. Not a function, not a committee. A person. Their job isn't to do all the work; it's to own the seams, the open questions, and the definition of done.

Make that name explicit [at intake](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams) and two things happen. Genuinely unowned work gets exposed _before_ it's staffed. And the owned work gets someone whose job is to notice the slip while it's still small — someone holding a [measurable outcome](https://gravam.com/blog/how-to-define-a-measurable-outcome), not a wish.

> The most expensive words in enterprise delivery are "I thought your team had that." You prevent them for free, at the start, by asking one question: who owns this outcome?

## Questions this article answers

**Q: Why is unclear ownership so expensive in enterprise delivery?**

Because it stays green until it's red. Every task tracks to plan and every team reports 'on track,' but the outcome slips in the seams between tasks — the integration nobody scoped, the edge case in intercompany elimination, the assumption two teams each thought the other owned. No status line ever turns amber to warn you, and the first real signal comes at UAT, long after the cheap moment to fix it has passed.

**Q: What's the difference between owning a task and owning an outcome?**

Ask who owns a task and you get a name instantly; ask who owns the outcome and you get a pause, then a committee. Task ownership feels like accountability but isn't — you can complete every task on the plan and still miss the outcome, because the failures live in the gaps between tasks, and a RACI chart with three people accountable for one line is a chart with none.

**Q: How do you fix unclear ownership?**

For every initiative, name one person accountable for the outcome — not the task list — before anything is committed. Not a function, not a committee, a person. Their job isn't to do all the work; it's to own the seams, the open questions, and the definition of done. Naming it at intake also exposes genuinely unowned work before it's staffed.

---

# Turning a Slack request into a decision-ready initiative

Source: https://gravam.com/blog/06-slack-request-to-initiative
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-06-03
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: How to take a one-line ask and shape it into something a team can commit to (or decline) in a few minutes, not a few meetings.

Here's a real shape of request, lightly disguised:

> can we add a report that shows treasury exposure by entity? finance keeps asking

That's the whole thing. It _feels_ actionable: there's a noun ("report"), a subject ("exposure by entity"), a hint of urgency ("keeps asking"). So a team picks it up and starts building a report. Six weeks later it's the wrong report.

The problem isn't the request. It's that a one-liner has to be **shaped** before it can be committed to, and most teams skip straight to building.

## Five fields make an ask decision-ready

You don't need thirty fields. You need five, and you need to actually fill them:

1. **Problem:** what's broken today? "Treasury rebuilds exposure by hand in Excel every month-end and it's error-prone": the [friction tax finance teams quietly pay](https://gravam.com/blog/03-finance-team-friction). Not "we need a report"; that's the difference between a [problem statement and a solution request](https://gravam.com/blog/problem-statements-vs-solution-requests).
2. **Outcome:** what's true when this is done? "Treasury sees exposure by entity without touching a spreadsheet." Now you can tell when you've succeeded.
3. **Owner:** whose outcome is this? One name. If it's "finance," it's no one.
4. **Scope:** what's explicitly in, and just as importantly, out. "By entity, yes. By counterparty, later. Real-time, no."
5. **Open questions:** the things you don't know yet. This field is the point. A request with no open questions usually means you haven't looked hard enough.

## Fill them with the person who asked

The leverage isn't in the fields; it's in filling them **out loud, with the requester, before committing**. Half the time the exercise changes the request: "oh, they don't need a report, they need the month-end exposure number to stop being wrong." The other half it surfaces an open question big enough to change the plan, the kind that's cheap to answer now and expensive to discover in UAT.

> Shaping isn't overhead you add before the work. It _is_ the work — the cheapest, highest-leverage part of it.

## Then decide, on purpose

Once the five fields exist, the decision is easy and honest: commit it, shape it further, park it, or say no. What you never do again is commit to a sentence and find out what it meant in production. This shaping step is the heart of a proper [intake process](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams), and the habit that fixes more of [finance systems delivery](https://gravam.com/topics/finance-systems-delivery) than any methodology I've used. If you want the five fields on one page as you go, the free [intake one-pager generator](https://gravam.com/tools/project-intake-one-pager) builds it as you type — nothing you enter leaves your browser.

## Questions this article answers

**Q: How do you turn a Slack request into a decision-ready initiative?**

Shape the one-liner into five fields before committing: the problem, the outcome, the owner, the scope (what's explicitly in and out), and the open questions. You don't need thirty fields; you need five, actually filled in. Only once they exist can a team honestly commit to it, shape it further, park it, or say no.

**Q: Why fill out the fields with the person who asked?**

The leverage isn't in the fields; it's in filling them out loud with the requester before committing. Half the time the exercise changes the request entirely: they don't need a report, they need a number to stop being wrong. The other half it surfaces an open question big enough to change the plan, one that's cheap to answer now and expensive to discover in UAT.

**Q: What's the point of the 'open questions' field?**

The 'open questions' field is the most important of the five. A request with no open questions usually means you haven't looked hard enough. Surfacing what you don't know yet is what stops a one-line ask from being committed to and then discovered — the wrong way — in production.

---

# Why teams commit before the request is clear

Source: https://gravam.com/blog/05-commit-before-clear
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-05-20
Reviewed: 2026-08-19
Summary: The pressure that turns a one-line ask into a commitment before anyone knows the scope — and the bill that shows up weeks later.

Most delivery problems don't start in delivery. They start in the thirty seconds after a request lands — when someone says "sure, we can do that" before anyone knows what "that" is.

It isn't carelessness. It's structure.

> A vague request doesn't get clearer while it waits. It gets committed to.

## Saying yes is the cheap answer

When a leader drops an ask into a channel, the socially cheap response is agreement. "We'll pick it up." "Should be doable." Asking the real questions — what problem is this solving, who owns the outcome, what does done look like — reads as friction, or as not being a team player. So the ask gets a nod. And a nod, three weeks later, is remembered as a **commitment**.

By then the date is already in someone's head, and nobody wrote down the scope it was attached to.

## Nobody owns the request yet

Early on, a request belongs to no one. The person who sent it assumes it's understood. The people who received it assume someone else will shape it. In that gap, no one is accountable for turning a sentence into a scope — so it stays a sentence, and the team builds against its best guess.

I've watched "can we add a revaluation report?" turn into a three-month argument, because _revaluation_ meant month-end FX to finance and intercompany netting to the team that built it. Nobody caught it early, because catching it was nobody's job.

## The bill arrives late, in disguise

The cost of an unclear commitment surfaces weeks later as something else: rework, a scope fight, a slipped date, a stakeholder who "didn't ask for this." None of it traces cleanly back to that first thirty seconds — so the pattern survives to the next request, and the one after that.

## The fix isn't a heavier process

You don't need a thirty-field [intake form](https://gravam.com/blog/project-intake-process-for-finance-and-engineering-teams). You need to make shaping **fast and visible**: capture the raw ask and force four questions to the surface before anyone commits — [what problem](https://gravam.com/blog/problem-statements-vs-solution-requests), whose outcome, what's in scope, how we'll know it worked.

> If those four can't be answered yet, that isn't a delay. It's the most useful thing you learned all week.

Commit to clarity first. The delivery date can wait thirty more seconds. Those thirty seconds are where most of [finance systems delivery](https://gravam.com/topics/finance-systems-delivery) is actually decided — long before anyone opens a project plan.

## Questions this article answers

**Q: Why do teams commit to work before the request is clear?**

Committing before the request is clear is structure, not carelessness. When a leader drops an ask into a channel, the socially cheap response is agreement — asking what problem it solves or what done looks like reads as friction or as not being a team player. So the ask gets a nod, and weeks later that nod is remembered as a commitment, with a date in someone's head but no written scope.

**Q: Why is unclear scope so hard to trace back?**

The cost of an unclear commitment surfaces weeks later disguised as something else: rework, a scope fight, a slipped date, or a stakeholder who 'didn't ask for this.' None of it traces cleanly back to the first thirty seconds after the request landed — so the pattern survives to the next request, and the one after that.

**Q: How do you stop committing to vague requests?**

You don't stop committing to vague requests with a heavier process or a thirty-field intake form. Make shaping fast and visible: capture the raw ask and force four questions to the surface before anyone commits — what problem, whose outcome, what's in scope, and how you'll know it worked. If those four can't be answered yet, that isn't a delay; it's the most useful thing you learned all week.

---

# The friction tax on finance teams

Source: https://gravam.com/blog/03-finance-team-friction
Topic: Finance Systems Delivery — https://gravam.com/topics/finance-systems-delivery
Author: Tan Gravam
Published: 2026-05-13
Updated: 2026-07-29
Reviewed: 2026-08-19
Summary: Finance teams move slowly not because the math is hard, but because every number has to be defended. The real bottleneck is provenance, not compute.

Finance teams don't move slowly because the math is hard. They move slowly because every number has to be **defended**.

> A finance team's velocity is set by how quickly they can answer "where did this come from?", not by how quickly they can compute the number itself.

The actual work — summing transactions, reconciling balances, posting accruals — is mechanical. What takes the time is the layer underneath: the audit trail, the source-of-truth lookup, the explanation for why this period looks different from last.

## Where the time really goes

In one month-end close I tracked hour by hour, well under a fifth of the team's time went to actually computing numbers. The bulk went to everything around the numbers:

- finding the source of a figure someone else had produced
- explaining variances to people who weren't in the original meeting
- waiting for approvals that weren't blocked on anything except calendar availability

One close, one team — but I've sat through enough of them to say the shape holds: the calculation is the small slice, and the defence of the calculation is the meal. The compute step is the only part most tools optimize for. The rest is treated as "process" — meaning nobody owns it and nobody measures it, the same [unclear-ownership tax](https://gravam.com/blog/07-cost-of-unclear-ownership) that sinks much bigger programmes.

## What actually helps

> The highest-leverage tool a finance team can adopt is one that makes the _provenance_ of a number cheap to retrieve — not one that makes the number faster to compute.

A spreadsheet that links cells back to the source query. A dashboard that shows which run, on which date, with which filters. A close checklist that includes the _reason_ for each entry, not just the entry itself.

Compute is solved. Context is the bottleneck. That's the thread running through everything I write on [finance systems delivery](https://gravam.com/topics/finance-systems-delivery): the slow part is almost never the calculation — it's the [request that was never shaped into a problem](https://gravam.com/blog/problem-statements-vs-solution-requests) in the first place.

## Questions this article answers

**Q: Why does finance work feel so slow?**

Finance work is slow, but not because the math is hard. The actual compute — summing transactions, reconciling balances, posting accruals — is mechanical. Teams slow down because every number has to be defended: finding its source, explaining variances to people who weren't in the original meeting, and waiting on approvals all take far more time than the calculation itself.

**Q: Where does the time go in a month-end close?**

This is one observation, not a benchmark: in a single month-end close I tracked hour by hour, well under a fifth of the team's time went to computing numbers. The bulk went to finding the source of figures, explaining variances, and waiting for calendar-bound approvals. Most tools optimize only the computing slice and treat the rest as 'process' that nobody owns or measures.

**Q: What actually speeds up a finance team?**

A tool that makes the provenance of a number cheap to retrieve, not one that makes the number faster to compute. Think a spreadsheet that links cells back to the source query, a dashboard that shows which run and filters produced a figure, or a close checklist that records the reason for each entry. Compute is solved; context is the bottleneck.