Do You Need a TMS? TMS vs ERP vs Spreadsheets

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

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.

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.

Head-to-head

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.

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 and evaluate vendors inside it — the 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 and how to build the TMS business case.