Treasury Management System Problems: The 7 That Cost You Cash, and How to Avoid Them
The most expensive failure in a treasury build is a bank feed that fails silently. The statement does not arrive, the system produces a position anyway because it has no concept of what was expected, and at 8am the treasurer sees a number that is missing two accounts. A funding decision gets made on it: the group draws on a revolver while a subsidiary sits on idle cash in a currency nobody netted. That is real interest expense on a real day, and it happens more than once before anyone identifies the cause. The lasting damage is worse than the interest. Once a treasurer has been wrong in front of the chief financial officer because of the system, the workbook comes back permanently and the $80,000 to $180,000 you spent buys nothing.
Why does the project get scoped as a dashboard when the work is bank connectivity?
Treasury projects are almost always sold and bought on the screen: a global cash position by entity, currency and bank, with drill down. It is the artefact everyone wants and it takes a competent team about three weeks to build once the data exists.
The data does not exist. Underneath that screen sits an integration project wearing a product label, and this is true whether you build or license. You still map every bank account, every statement format, every legal entity, every enterprise resource planning (ERP) company code and every cash flow category. Companies routinely spend more implementing a packaged treasury platform than they expected for exactly this reason, and then discover the parts specific to their structure still live in workarounds. A build has the same shape. If a quote does not have a line item per bank relationship, it is a quote for the screen.
Reorder the plan so connectivity leads. Start bank onboarding on day one, before any interface design, because it runs on the banks' timetable and not yours: an agreed format, a delivery channel, credentials or certificates, and a test cycle per relationship. Some banks complete in weeks and some take months. The acceptance test for the first release is not that the dashboard renders, it is that every account in the group produced a complete prior day statement, on time, for twenty consecutive business days, with alerting proven by deliberately withholding one.
What goes wrong when you migrate the cash sheet and account inventory?
The first surprise is that nobody knows how many bank accounts the group has. The treasury workbook covers the ones treasury manages. Then discovery finds accounts opened by a local finance manager for a payroll requirement, dormant accounts from an acquisition that were never closed, escrow and deposit accounts held for a customer contract, and accounts the group can see but not control because a joint venture partner is the mandate holder.
The second surprise is categorisation. Your existing cash flow categories live as a formula referencing text in a description field, maintained by one person, and they work because that person corrects the exceptions each morning without mentioning it. Load the same rules into a system and the exceptions become visible for the first time, usually as several percent of transaction value landing in an uncategorised bucket. Teams read that as the new system being wrong. It is the old process being invisible.
Run an account discovery exercise before scoping, not during build. Ask every entity controller to confirm every account with a mandate, including dormant and observed accounts, and reconcile that against bank confirmations. Model accounts you observe but do not control as a distinct type, because they belong in the position and not in the funding logic. Then build categorisation as rules learned from history with an explicit review queue, and accept that the queue is the honest measure rather than a defect.
Why do the bank feeds and enterprise resource planning integration break after launch?
The formats are standard enough on paper. Prior day statements arrive as MT940 or ISO 20022 camt.053, intraday as MT942 or camt.052, payments go out as pain.001 or a domestic format, delivered by host to host file transfer, a service bureau, EBICS in parts of Europe or a bank interface. Every bank then populates reference fields its own way, and your reconciliation depends on those fields.
What breaks after launch is rarely dramatic. A bank changes how it populates a reference on one transaction type after a platform migration, and your reconciliation match rate drops from 94 percent to 71 percent over a weekend with no error raised anywhere. A certificate expires and the transfer fails at 3am. A bank that is habitually late becomes later. On the ledger side, an upgrade changes a table your receivables extract depends on, or a company code is added for a new entity and nothing maps it.
Treat connectivity as a monitored pipeline with expected arrival windows, completeness checks and alerting, and give certificate rotation a named owner with a calendar. The rule that matters most is that a partial position must be labelled as partial and must not be publishable. Match rate should be a tracked metric with a threshold alert, because a falling match rate is the earliest signal that a bank changed something, and it is the one that otherwise takes a quarter to surface.
What happens when payment approval controls are not covered?
The moment you put payment initiation in the system you have built a fraud target, and the control set that matters is structural rather than procedural. Business email compromise works by changing beneficiary bank details and manufacturing urgency. If the only defence is a person recognising a name and noticing that something feels wrong, then the system has made fraud faster rather than harder, because it removed the friction that used to slow a payment down.
The failure pattern is consistent. Payment capability gets added in the same release as everything else because it feels like the natural completion of the product, controls are specified as policy in a document, and the delegation of authority is implemented as a single approval limit rather than as the entity specific matrix your board actually approved. Then a beneficiary account is edited by the person who also releases the payment run, and nothing in the software objects.
Keep payments out of the first release. A read only position and forecast system delivers most of the value at a fraction of the control burden and lets you establish trust in the data before anything can move money. When payments do arrive, require segregation between creating a beneficiary and approving a payment, a mandatory second approval and cooling period on any new or changed bank detail, approval limits mirroring your delegation of authority including entity specific rules, and out of band verification above a threshold. Payment files should be generatable only for approved beneficiaries, so urgency has no path at all.
Should you build custom or configure what you already own?
License, and do it without embarrassment, 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. Kyriba, GTreasury, ION Treasury, FIS Quantum and Coupa Treasury all have real connectivity networks, and their bank format libraries alone represent work you should not want to repeat.
Under roughly fifteen accounts in one currency and one legal entity, do neither. Your bank portal plus a disciplined workbook is genuinely adequate and the money belongs elsewhere. The threshold that matters is structural complexity rather than revenue: several entities funding each other, multiple currencies, more than a few banking relationships, or a shared service centre making payments.
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 your bank relationships are concentrated enough that connectivity is a handful of integrations rather than dozens, or when you have already implemented a treasury platform and still run spreadsheets around it. That last signal is the decisive one. It means the vendor's model does not fit your structure, and another configuration round will not change that.
How do hidden costs get into the quote?
Bank count and connectivity method is the first and largest. Host to host file transfer with certificate management, a service bureau relationship and a bank interface are three different projects, and a quote written for four banks on one method does not extend to seven banks on three. List every relationship and its method before you ask for a price.
Payment initiation is the second and it does not scale linearly, because it changes the risk profile of the whole system and therefore the volume of control, testing and audit work. Adding it later as a phase is cheaper than adding it late in a phase. The third is in house banking and intercompany loan mechanics, which bring interest accrual, transfer pricing considerations and a reconciliation obligation that looks small on a slide.
The fourth is the ledger. An older on premise instance with customised tables is a materially different integration from a clean cloud one, and the difference is not superficial. Go read only first, name every bank and method, defer in house banking, and confirm the exact version and deployment of your enterprise resource planning system in writing. Under those constraints the $80,000 to $180,000 first release band across 12 to 18 weeks holds.
What separates a build that works from one that fails here?
Ask a candidate developer which bank statement formats they have parsed in production and what broke. Someone 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. Vague reassurance means your group is their first.
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 publish a partial position, and after that nobody trusts the number again. Ask how they would design approval controls for a beneficiary bank detail change, and if the answer does not include segregation, a second approver and a delay, do not give that system payment capability under any circumstances. Ask about ledger experience by name and version, because a customised on premise instance and a clean cloud one are different problems.
Settle ownership before kickoff: repository, cloud accounts, and bank connectivity credentials held by your treasury team rather than by the developer, with the unrestricted right to hire another firm. A system that touches group cash must never be one where an outside party controls the access path to your banks. Then build the forecast from your own drivers and track variance by category and entity, because that is the feature that changes behaviour: it makes local finance teams accountable for their own inputs and turns a report into a management tool.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Organizations that scaled intelligent automation report an average cost reduction of 32% (up from 24% in 2020), and respondents expect an average 31% cost reduction over the next three years. Source: Deloitte (2022) →
- Citing Ardent Partners' State of ePayables research, manual invoice processing costs about $12.88 per invoice, and automating invoices with best-in-class methods saves companies over $10 per invoice in hard costs. Source: Bottomline Technologies (citing Ardent Partners) (2024) →
- Deloitte's research found that digitally advanced small businesses experienced revenue growth nearly 4x as high as the prior year, were about 3x as likely to have exported, were nearly 3x as likely to have created new jobs, and were more than 3x as likely to have seen more sales inquiries in the last year. Source: Deloitte (research summarized by Google) (2017) →
- Brandon Hall Group research on onboarding reports that done well, structured onboarding drives measurable gains in new-hire productivity, employee engagement, and retention; the page notes 41% of organizations experience greater than 5% turnover among new hires. Source: Brandon Hall Group (2024) →
Growth strategy at an agency means figuring out which lever actually moves revenue before anyone spends on it. Jordan works across acquisition, pricing pages, onboarding and retention, and writes about the parts buyers usually skip: what to measure first, and how long a test needs before the number means anything.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
What should be in the first release if we only fund one phase?
Automated statement ingestion across every bank with expected arrival monitoring and completeness alerting, an entity and account model matching your legal and funding reality including accounts you observe but do not control, a same morning global position with drill down to the transaction, and a rolling forecast built from your own business drivers with variance tracking. That combination runs $80,000 to $180,000 over 12 to 18 weeks. Deliberately leave payment initiation out, because it changes the control burden of the entire system.
How do we know the position is complete rather than merely produced?
Every account needs an expected statement arrival window, and the system must treat a missing statement as a blocking condition rather than as a zero. A position with any account unaccounted for should be visibly labelled partial and should not be publishable to the people who make funding decisions. Test this before go live by deliberately withholding one bank's file and confirming that the alert fires and the position refuses to publish. That single test tells you more about the build quality than any demonstration.
Why does our reconciliation match rate fall without anything erroring?
Because banks change how they populate reference fields after platform migrations and format upgrades, and your matching logic depends on those fields rather than on the standard. The file still parses, the balances still agree, and the transaction level matching quietly degrades. Track match rate per bank as a monitored metric with a threshold alert, since a falling rate is the earliest available signal that something changed upstream. Without it, the discovery usually happens a quarter later when someone questions a reconciliation backlog.
How many bank accounts do we actually have?
Almost certainly more than the treasury workbook shows. Run a discovery exercise asking every entity controller to confirm every account with a mandate, then reconcile that list against bank confirmations. The usual finds are accounts opened locally for payroll, dormant accounts inherited through an acquisition and never closed, escrow accounts tied to customer contracts, and accounts the group can see but not control because a joint venture partner holds the mandate. Model that last category explicitly, since it belongs in the position but not in the funding logic.
Should payment initiation ever be in the first release?
Only if payments are the specific problem you are solving and you are prepared for the control work that comes with them. A read only position and forecast system delivers most of the value at a fraction of the risk and lets you establish trust in the data first. When you do add payments, the controls have to be structural: segregation between creating a beneficiary and approving a payment, a second approval and cooling period on changed bank details, entity specific approval limits mirroring your delegation of authority, and payment files generated only for approved beneficiaries.
How do we build a forecast people actually use?
Forecast from your own business drivers rather than from a generic module. A construction group forecasts from certified progress claims and retention releases, a subscription business from billing schedules, a manufacturer from purchase order commitments and supplier payment terms, a retailer from daily takings and card settlement lag. Then track actual against forecast variance by category and by entity every period. The variance view is what changes behaviour, because it makes each local finance team accountable for the quality of their own inputs rather than for a group total nobody owns.
How long does bank onboarding take and can it run in parallel?
It must run in parallel and it should start on day one, because it moves at the banks' pace regardless of your project plan. Each relationship needs an agreed format, a delivery channel, credentials or certificates and a test cycle, and the range across banks is genuinely weeks to months. Sequencing it after software build is the most common cause of a treasury project slipping a quarter, since the interface is finished and there is nothing complete to put through it.
Who should hold the bank connectivity credentials?
Your treasury team, without exception. The repository, the cloud infrastructure accounts and the certificates or credentials sit with the company, and the agreement should give you the unrestricted right to bring in another firm without touching the access path to your banks. Any arrangement where a developer holds production banking credentials is a control failure regardless of how much you trust them, and it is the arrangement your auditors will question first when they see the system for the first time.
How long does it take to build custom accounting software?
Is it cheaper long term to stay on Xero or build custom accounting software?
What does it cost to maintain custom accounting software each year?
How do I vet a development agency for an accounting software project?
What questions should I ask a development agency on the first call?
Will an app built for 10 users survive growing to 500?
Who owns the code when an agency builds my software?
Can custom accounting software connect to my bank, payment processor, and payroll provider?
What are the biggest mistakes first-time software buyers make?
What happens to my accounting software if the agency shuts down?
Who can build a custom accounting software system?
Digital Heroes builds custom accounting software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other accounting software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
