# TMS Pricing, Licensing and Total Cost of Ownership

Source: https://gravam.com/blog/tms-pricing-and-licensing-models
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.