Article map
Bank-account rationalisation is often presented as a simple cost-saving exercise: count the accounts, identify the inactive ones and ask the bank to close them. That approach is dangerous. A bank account may appear quiet while still supporting tax payments, customer collections, payroll, guarantees, direct debits, cash pooling, local regulatory requirements or a rarely used contingency process. Closing it without understanding those dependencies can interrupt operations; leaving it open without a valid purpose can enlarge the fraud surface, increase fees and weaken access governance.
A disciplined rationalisation programme therefore aims for the smallest defensible account estate, not the smallest possible number of accounts. The target state must support business needs, legal-entity autonomy, resilience and banking strategy while giving treasury complete visibility over ownership, purpose, connectivity and authorised use.
This article sets out a practical method for using a Treasury Management System to convert account rationalisation from a periodic spreadsheet campaign into a controlled, evidence-based operating process.
1. Define the account universe and the decision criteria
The programme should begin with an authoritative account population and a transparent rule for deciding whether each account is retained, redesigned, migrated or closed. Activity alone is not enough. Treasury needs to understand why the account exists, which processes rely on it and whether those needs can be served through another structure.
The operating boundary should define:
- all operating, collection, disbursement, payroll, tax, escrow, margin, investment and dormant accounts
- legal owner, country, currency, bank, branch, account purpose and accountable business owner
- contractual, regulatory, tax, customer, supplier and financing dependencies
- participation in cash pools, sweeping structures, virtual-account arrangements or security packages
- objective retain, consolidate, migrate, suspend or close criteria with documented exceptions
A TMS account master should record the rationalisation disposition and the evidence behind it. This prevents a future review from reopening the same debate or treating an account as redundant merely because its recent transaction volume is low.
2. Build an evidence base that combines master data and behaviour
Account decisions improve when static master data is joined with transaction history, fee data, access information and downstream mappings. A clean account list without behavioural evidence can miss operational dependencies, while transaction data without ownership and purpose cannot explain whether the activity remains legitimate.
The governed data record should capture:
- twelve to twenty-four months of balances, transaction counts, value and counterparty patterns
- bank fees by account, service, channel, currency and pricing arrangement
- ERP ledger mapping, payment-format usage, direct-debit mandates and collection references
- signatories, digital users, tokens, approval groups and last access-review date
- open reconciling items, pending investigations, unpresented instruments and legal holds
The analysis should distinguish genuine use from noise. Bank charges, automated sweeps, interest postings or occasional fee reversals may make an otherwise unused account look active. Conversely, an account with no recent postings may still be required for a seasonal collection cycle or emergency settlement route.
3. Run rationalisation as a controlled dependency-removal workflow
Account closure should follow the same discipline as a production-system change. Treasury first confirms the target structure, then removes dependencies, migrates activity, validates that the replacement works and only then issues closure instructions. The workflow should remain visible across treasury, finance, tax, legal, procurement, payroll and local management.
The end-to-end workflow should make visible:
- nomination of an account owner and closure coordinator for every candidate account
- dependency confirmation by relevant functions using a time-bound attestation
- migration of payment templates, collection instructions, direct debits and ERP mappings
- controlled balance transfer after unresolved items and restrictions are cleared
- bank closure confirmation followed by post-closure monitoring for rejected or misrouted activity
The TMS should prevent closure status from being treated as a single manual flag. Each dependency, approval, bank instruction and confirmation should be a dated task with an owner, evidence and escalation path.
4. Protect against operational, fraud and accounting gaps
Rationalisation reduces control complexity only when closure itself is controlled. Weak programmes close accounts before outstanding items are resolved, leave digital entitlements active, fail to update payment instructions or lose evidence that the bank accepted the closure. Those gaps can create misdirected cash and unresolved ledger balances.
The control architecture should address:
- maker-checker approval for the retain, migrate and close decision
- independent verification of destination accounts and balance-transfer instructions
- revocation of bank users, signatories, tokens, API credentials and file-routing rules
- reconciliation of the final statement to the ledger and resolution of all exceptions
- retention of closure letters, bank confirmations, final statements and master-data history
A closed account should remain visible historically in the TMS, with its closure date and prior relationships preserved. Deleting the record destroys lineage and makes later investigations unnecessarily difficult.
5. Use the TMS as the account-governance system of record
The most valuable technology outcome is not a one-time list of accounts to close. It is a sustainable account-governance capability that stops the estate from expanding again without scrutiny. New accounts should enter through a business case, approval and onboarding workflow, and retained accounts should be periodically revalidated.
The TMS configuration should support:
- one bank-account master linked to entities, ledgers, payment channels and cash structures
- account lifecycle statuses covering request, approval, opening, active use, suspension and closure
- automated identification of low-activity, high-fee, duplicate-purpose and stale-connectivity accounts
- periodic owner attestation and access recertification triggered by risk and materiality
- dashboards showing closure pipeline, fee savings, unresolved dependencies and overdue confirmations
The system should also flag new bank statement records for accounts not present in the approved master. Such exceptions often reveal unofficial accounts, incomplete onboarding or bank-side identifiers that were never mapped correctly.
6. Measure value without rewarding indiscriminate closure
A programme that celebrates only the number of accounts closed can encourage poor decisions. Performance should combine financial savings, control simplification, coverage and service continuity. The most credible savings are those verified after closure rather than estimated from tariff sheets.
Management reporting should measure:
- accounts eliminated as a percentage of the review population and by risk tier
- annualised fees removed, avoided implementation costs and reduced token or channel charges
- percentage of active accounts with confirmed owner, purpose, ledger mapping and connectivity
- ageing of closure dependencies and time from approval to bank confirmation
- post-closure incidents, rejected payments, misdirected receipts and unresolved ledger items
Treasury should separately report accounts retained by exception. A high-value exception can be entirely appropriate, but it should have an expiry or review date so that temporary reasoning does not become permanent architecture.
7. Sequence the programme around risk and feasibility
Rationalisation is easier to control when the population is divided into waves. Start with clearly redundant, low-risk accounts where ownership and dependencies are known. Use the lessons to improve data and workflows before addressing regulated, high-volume, pooled or customer-facing accounts.
The implementation plan should sequence:
- pilot with dormant and duplicate-purpose accounts in a small number of entities
- validate the dependency questionnaire and closure evidence standard
- establish bank-specific closure lead times and escalation contacts
- schedule high-risk migrations outside payroll, tax, quarter-end and peak collection periods
- embed annual account certification and new-account governance after the project ends
A staged approach creates visible benefits early without turning the programme into a mass closure event. It also allows treasury to distinguish data-quality problems from genuine business complexity before committing to a target number.
Practical illustration: twenty accounts that looked redundant
A regional group identifies twenty accounts with fewer than five external transactions in the prior year. A spreadsheet review initially recommends closing all twenty. The TMS dependency analysis shows a different picture: four receive annual insurance recoveries, three support statutory payments, two are pledged under financing arrangements and one is the fallback payroll account for a country with periodic banking outages.
Treasury closes the ten genuinely redundant accounts, migrates two statutory processes into existing operating accounts, retains the pledged accounts with a documented review date and redesigns the fallback payroll arrangement so that it can be activated without maintaining a continuously open account. Verified annual fees fall, digital access is reduced and the group avoids disrupting legally significant flows.
The practical insight is that the value came from classifying purpose and dependency, not from applying an inactivity threshold mechanically.
Implementation checklist
A treasury team preparing to operationalise this topic should be able to answer yes to the following questions:
- Is every material account recorded in one approved master?
- Does each account have a confirmed owner, purpose and legal entity?
- Have transaction, fee, access and reconciliation data been reviewed together?
- Are tax, payroll, collection, financing and regulatory dependencies documented?
- Is there a controlled disposition for retain, migrate or close?
- Are replacement processes tested before closure instructions are issued?
- Are balances and open items independently reconciled?
- Are users, signatories and technical credentials revoked?
- Is bank confirmation retained and post-closure activity monitored?
- Will retained accounts be revalidated periodically?
Common design failures
The most common failures arise when rationalisation is treated as procurement savings rather than treasury architecture.
- closing accounts based only on transaction count or closing balance
- relying on local confirmation without validating system and mandate dependencies
- transferring balances to unverified destination instructions
- leaving bank access, tokens or file routes active after closure
- deleting closed accounts from the master instead of preserving history
- claiming savings before invoices and service charges actually reduce
A defensible programme can close fewer accounts than originally expected and still create more value, because it removes unnecessary complexity without transferring risk into operations.
Closing perspective
Bank-account rationalisation is a control-design exercise disguised as a cost project. Done well, it improves cash visibility, reduces attack surface, simplifies connectivity and clarifies the banking model. Done badly, it interrupts collections and payments while leaving historical evidence incomplete.
A TMS makes the programme sustainable when it links account purpose, behaviour, access, dependencies, workflow and closure evidence in one lifecycle record. The end state is not merely a smaller account list; it is an account estate that treasury can explain and govern.
Frequently asked questions
How should treasury identify redundant bank accounts?
Use a combination of account purpose, ownership, transaction behaviour, fees, access, ledger mapping and operational dependencies. Low activity is an indicator for review, not sufficient evidence that an account can be closed.
Should dormant accounts always be closed?
Not automatically. Some dormant accounts support contingency, legal, financing or seasonal requirements. Treasury should document the reason for retention, confirm that the arrangement remains effective and set a future review date.
What role should a TMS play in bank-account rationalisation?
The TMS should maintain the authoritative account master, connect each account to its dependencies, coordinate closure tasks and approvals, retain evidence, monitor post-closure exceptions and enforce ongoing account-lifecycle governance.