How Much Does a Treasury Management System Cost in 2026?

The bands a treasury build falls into

The first release band is $80,000 to $180,000 over 12 to 18 weeks. That covers automated statement ingestion across every bank in the group with format handling and expected arrival monitoring, an entity, account and ownership model matching your legal and funding structure, a same morning global cash position with drill down to the transaction, cash flow categorisation, and a rolling forecast built from your own business drivers with variance tracking. It is deliberately read only.

The full platform band is $220,000 to $550,000 phased over 6 to 12 months. That adds payment initiation with structural approval controls, in house banking and intercompany netting with interest accrual, debt and investment tracking, and deeper enterprise resource planning (ERP) integration for receivables, payables and expected settlement dates.

There is a narrower start worth costing on its own. Connectivity and the position alone, meaning statement ingestion, the entity model and a same morning position with no forecasting, runs $45,000 to $75,000 over seven to nine weeks. It answers the question the treasurer asks every morning and nothing else, and it establishes whether the data is trustworthy before anything is built on top of it.

What drives a treasury build up

Bank count and connectivity method dominate. The formats themselves are standard enough: prior day statements as MT940 or camt.053, intraday as MT942 or camt.052, payments as pain.001 or a domestic format. The cost is in the edges. Each bank populates reference fields differently and your reconciliation depends on those fields, so format handling is per bank rather than per standard.

Payment initiation is the second driver and it changes the risk profile of the whole system rather than adding a module. Once money can move, the control work, the segregation, the audit logging and the testing all expand.

Entity and currency count is the third. Four entities in three currencies is a model. Twenty entities across nine currencies with internal funding relationships is a structure that has to be configurable by your own team, because it changes with every acquisition.

In house banking and intercompany loan mechanics are the fourth, and they bring interest accrual and tax considerations that are as much finance work as engineering.

Enterprise resource planning version and quality is the fifth. An older on premise instance with customised tables is a different integration from a clean cloud one, and the difference is not superficial.

What keeps the number down

Read only first. A position and forecast system with no payment capability delivers most of the value at a fraction of the control burden, and it lets the treasurer establish trust in the numbers before anything can move cash. Payments can be added later once the data foundation is proven, and they will cost less then because the account and entity model is already right.

Start bank onboarding immediately, in week one, before the build. Each relationship needs an agreed format, a delivery channel, credentials or certificates and a test cycle, and some banks move in weeks while others take months. This is the item most likely to determine your go live date and the item least affected by how you spend the budget.

Categorise with rules learned from your own history rather than building a classification model. A rules engine over transaction descriptions, refined over the first two months, gets you an analysable position without a machine learning workstream.

Take enterprise resource planning integration read only in phase one. Receivables, payables and expected settlement dates flowing in one direction is a fraction of the cost of two way posting and covers the forecasting need.

Finally, do not model instruments you do not hold. Debt and investment tracking is worth building when you have the instruments. Building it speculatively is a common and avoidable overspend.

A worked example that adds up

A group with four legal entities, three currencies, six banking relationships across two connectivity methods, one enterprise resource planning instance, and no payment initiation in the first release.

• Statement ingestion for six banks across prior day and intraday formats, with per bank reference field handling, expected arrival windows, completeness checks and alerting: $46,000
• Entity, account and ownership model including accounts you observe but do not control: $18,000
• Same morning global position by entity, currency and bank with drill down to the transaction: $22,000
• Cash flow categorisation with rules refined against your own history: $14,000
• Rolling forecast built from your business drivers, with actual against forecast variance by category and entity: $30,000
• Foreign exchange exposure aggregation across entities so netting opportunities surface before hedging: $10,000
• Read only enterprise resource planning integration for receivables, payables and expected settlement dates: $16,000
• Discovery, bank onboarding support and testing: $18,000

Total $174,000 over 17 weeks. Adding payment initiation with segregation, approval limits mirroring your delegation of authority and beneficiary change controls typically adds $60,000 to $110,000. Adding in house banking with intercompany netting and interest accrual adds $50,000 to $95,000.

How the spend phases

Weeks one to three cover the entity and account model and, critically, the start of bank onboarding. The model is quick to build and slow to agree, because it forces a conversation about which entity actually owns which account and who is authorised on it. Some groups discover the answer is not what the organisation chart implies.

Weeks two to ten build connectivity, one bank at a time, hardest first. Treat it as a monitored pipeline rather than a parser: expected arrival windows, completeness checks and alerting when a feed is missing rather than empty. A silently failed feed producing a partial position is worse than an obviously failed one, and it is the single fastest way to lose the treasurer's trust permanently.

Weeks eight to fourteen deliver the position, categorisation and foreign exchange aggregation. This is where the system becomes usable, and it is worth going live on the position before the forecast is finished.

Weeks twelve to eighteen build the forecast and variance tracking, then run it alongside the existing workbook for a full month. The workbook is the acceptance test, and every difference between the two is either a defect or a rule nobody had written down.

The ongoing costs nobody quotes

Connectivity is the standing cost that surprises people. Host to host file transfer means certificates that expire and rotate, and someone has to own that with alerting attached. A service bureau relationship carries its own fees. Bank application programming interfaces sometimes carry per call or per statement charges. None of these end at go live and all of them scale with bank count.

Hosting for a system of this shape typically runs $400 to $1,200 a month. The data volume is small, but availability matters more than volume, because a position that is unavailable at eight in the morning is a position that does not exist.

Support and enhancement typically runs 15 to 20 percent of the build cost annually, and in this category the enhancement half is dominated by bank changes. Format tweaks, new accounts, closed accounts and new relationships arrive continuously and each is small.

Payment initiation, if you add it, brings a recurring control cost rather than only a build cost. Access reviews, approval matrix maintenance and periodic testing of the beneficiary change controls are annual obligations.

The cost that belongs in the business case rather than the software budget is the local finance teams' forecast inputs. Variance tracking by driver makes them accountable, which is the point, and it also means somebody has to maintain the drivers.

Comparing a build against your current renewal

If you already licence a treasury platform, you have a clean number to compare against, and the honest comparison includes the part the licence does not cover.

Start with the licence and the support contract. Then add what you spent on implementation, amortised over the term, because a treasury management system is largely an integration project regardless of the label and that spend is real. Then ask the question that decides most of these business cases: what still runs in a spreadsheet alongside the platform. In our delivery experience it is usually the intercompany loan mechanics, the in house bank rules and the approval matrix that mirrors your actual delegation of authority, because those are the parts most specific to your group.

If you have no platform today, the comparison is against labour and against decisions. Count the hours between the first bank portal login and the finished position, every working day, and multiply across a year. Then look at the funding decisions made on a position that was two hours old. Idle balances at one subsidiary while the group draws on a revolver is the classic example, and your treasurer can price it because they know both rates.

Add foreign exchange exposure that was never netted because nobody could see it aggregated across entities in time to act. That is a number your treasurer can estimate from last year with more confidence than any external benchmark.

When buying beats building

Do not build if you operate under roughly fifteen bank accounts in one currency and one legal entity. Your bank's portal plus a disciplined workbook is genuinely adequate, and we would tell you to spend the money elsewhere. The threshold that matters here is structural complexity rather than revenue.

Licence Kyriba, GTreasury, ION Treasury, FIS Quantum or Coupa Treasury if you need a broad bank connectivity network quickly, your group structure is conventional, you want a vendor accountable for format changes and bank onboarding, and your internal technology capacity is thin. Those are good reasons and they apply to a lot of companies. Their bank format libraries alone represent work you should not want to repeat if your relationships are numerous and spread across many countries.

Build when two or more of these are true. Your entity and funding structure is unusual or changes frequently through acquisition. Your forecast depends on business drivers that live in your own systems, such as certified progress claims, billing schedules, purchase order commitments or card settlement lag. You have already implemented a treasury platform and still run spreadsheets around it. Your bank relationships are concentrated enough that connectivity is a small number of integrations rather than dozens. Or the licence and implementation quote exceeds what a focused build would cost, which happens more often than vendors would like.

If you would rather someone argued with your brief than agreed with it, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. The document is yours whichever way you go.