# Do You Need a TMS? TMS vs ERP vs Spreadsheets

Source: https://gravam.com/blog/tms-vs-erp-treasury-vs-spreadsheets
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.