Custom Treasury Management System Development: How Do You See Group Cash Before the Banks Tell You Tomorrow?

The position that is always one day old

It is 8:15am. The treasurer needs to know what the group holds, where, in what currency, and what is committed today. The answer requires logging into six bank portals, exporting prior day statements in four different formats, pasting them into a workbook with a tab per region, applying yesterday's rates, and manually adding the two payments the shared service centre mentioned in an email. By the time the position exists it is 10am, the European entities have already made funding decisions, and one subsidiary is sitting on idle cash while the group draws on a revolver at a rate nobody has connected to that balance.

The cost of this is not theoretical and it does not require a spreadsheet error to appear. It shows up as avoidable borrowing, as idle balances earning nothing, as foreign exchange exposure that was never netted, and as a payment fraud surface where the control is a person recognising a beneficiary name.

Treasury is a small team moving the entire company's cash. That asymmetry is why building here pays back faster than almost anywhere else in a finance function.

Why packaged treasury systems still leave you integrating

Kyriba, GTreasury, ION Treasury, FIS Quantum and Coupa Treasury are capable products with real bank connectivity networks, and for many companies they are the right answer. Their bank format libraries alone represent work you should not want to repeat.

The honest issue is that a treasury management system is mostly an integration project wearing a product label. You still map every bank account, every statement format, every entity, every ERP company code and every cash flow category. You still build the forecast logic around your own business drivers. You still negotiate connectivity with each bank. The licence buys you a framework and a support contract, not an absence of implementation. Companies routinely spend more on implementing a treasury platform than they expected, and then find the parts specific to their structure, the intercompany loan mechanics, the in house bank rules, the approval matrix that mirrors their delegation of authority, sit in workarounds anyway.

So the question is not build versus buy in the abstract. It is whether your structure is close enough to the vendor's model that their framework saves you more than it constrains you.

Problem one: connectivity is a solved problem with unsolved edges

The formats are standard enough. Prior day statements arrive as MT940 or as ISO 20022 camt.053, intraday as MT942 or camt.052, and payments go out as pain.001 or in domestic formats. Corporates connect through host to host file transfer, through a SWIFT service bureau, through EBICS in parts of Europe, or increasingly through bank APIs.

The edges are where the work is. Every bank implements the standard with its own quirks in reference fields, and the reference field is what your reconciliation depends on. Statement delivery times vary and some banks are habitually late, so the system needs to know what is expected and alert when it is missing rather than silently producing a partial position. Certificate rotation and connectivity monitoring have to be someone's job with alerting attached, because a silently failed feed is worse than an obviously failed one.

A build that treats connectivity as a monitored pipeline with expected arrival windows, completeness checks and alerting is doing the part that actually determines whether the treasurer trusts the number at 8am.

Problem two: the forecast is a business model, not a treasury module

Every packaged system offers cash forecasting. Almost none of them forecast your business, because your cash flow drivers are specific: a construction group forecasts from certified progress claims and retention releases, a subscription business from billing schedules and churn, a manufacturer from purchase order commitments and payment terms by supplier, a retailer from daily takings and settlement lag by card scheme.

The forecast that gets used is built from those drivers, pulled from the systems that hold them, and compared against actuals with variance analysis by category and by entity. That last part is what turns a forecast into a management tool: when the 30 day forecast misses by a material amount, the treasurer needs to know which category and which entity drove it, and whether the same pattern recurred last month. In our delivery experience, variance tracking by driver is the feature that changes behaviour, because it makes local finance teams accountable for their own inputs.

Problem three: payment initiation is where fraud actually happens

If you put payments in the system, you have built a fraud target. The controls that matter are structural: segregation between creating a beneficiary and approving a payment, a mandatory cooling period and secondary approval for new or changed bank details, approval limits mirroring your delegation of authority including entity specific rules, and out of band verification for anything above a threshold.

Business email compromise works by changing bank details and creating urgency. A system where a beneficiary bank account change requires two approvals and a wait, and where the payment file is generated only from approved beneficiaries, removes the mechanism rather than relying on someone noticing. This is a design decision, not a policy document, and it should be in the first release if payments are in scope at all.

Problem four: entity structure and intercompany

The reason spreadsheets survive in treasury is that they can represent anything. Your legal entity structure, your account ownership, which entity funds which, and your intercompany lending arrangements are specific to your group and change with every acquisition. Packaged systems model this, but adapting their model to yours is where implementations stall.

A build should model entities, accounts, ownership and internal funding relationships explicitly, then compute the group position, the netting proposal and the intercompany interest accrual from that structure. When the group buys a company, adding it should be configuration by your own team, not a vendor change request.

What a first release should include

• Automated statement ingestion across every bank in the group with format handling, expected arrival monitoring and completeness alerting.
• An entity, account and ownership model matching your legal and funding structure, including accounts you observe but do not control.
• Same morning global cash position by entity, currency and bank, with drill down to the transaction.
• Cash flow categorisation with rules, learned from history, so the position is analysable rather than just a total.
• A rolling forecast built from your own business drivers with actual versus forecast variance by category and entity.
• Foreign exchange exposure aggregation across entities so netting opportunities are visible before hedging.
• Read only ERP integration for receivables, payables and expected settlement dates.

Cost, timeline and drivers

A first release with connectivity, structure, position and forecast runs $80,000 to $180,000 across 12 to 18 weeks. Adding payment initiation with approval controls, in house banking, intercompany netting, debt and investment tracking and deeper ERP integration takes it to $220,000 to $550,000 over 6 to 12 months.

What increases cost: bank count and connectivity method, since a host to host file transfer with certificate management, a SWIFT bureau relationship and a bank API are three different projects. Currency and entity count. Payment initiation, which roughly changes the risk profile of the whole system and therefore the amount of control work. In house banking and intercompany loan mechanics, which bring interest accrual and tax considerations. ERP version and quality, because an older on premise instance with customised tables is a different integration from a clean cloud one.

What holds it 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 you can add payments later once the data foundation is trusted.

When to license instead

License Kyriba or GTreasury if you need a broad bank connectivity network quickly, if your group structure is conventional, if you want a vendor accountable for format changes and bank onboarding, and if your internal technology capacity is thin. Those are good reasons and we say so regularly.

Build when your entity and funding structure is unusual or changes frequently through acquisition, when your forecast depends on business drivers that live in your own systems, when you have already implemented a treasury platform and still run spreadsheets around it, when your bank relationships are concentrated enough that connectivity is a small number of integrations rather than dozens, or when the licence and implementation quote exceeds what a focused build would cost, which happens more often than vendors would like.

How to choose a developer

Ask which bank statement formats they have parsed in production and what broke. A developer who has done this will immediately talk about reference field inconsistencies between banks and about statements arriving late, because those are the two things that ruin an 8am position.

Ask how the system knows a feed is missing rather than empty. If there is no expected arrival window and no alert, the treasurer will eventually make a decision on a partial position, and once that happens trust is gone.

Ask how they would design approval controls for a beneficiary bank detail change. If the answer does not include segregation, a second approver and a delay, do not give that system payment capability.

Ask about their ERP integration experience by name and version, because SAP ECC, S4HANA, Oracle and NetSuite are four different problems and the differences are not superficial.

Settle ownership before kickoff: repository, cloud accounts, bank connectivity credentials held by you, and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. A system that touches the group's cash should never be one where an outside party controls the access.