Article map
Treasury transformation programmes often compare features: how many bank feeds are automated, whether a dashboard exists or whether payments can be released from one platform. Those indicators are useful but incomplete. A process can be automated and still rely on weak master data, hidden overrides and manual reconciliation.
A control maturity model assesses how reliably treasury produces complete, authorised, timely and explainable outcomes. It provides a common language for current state, target state and sequencing. This article presents a five-level model and the domains that should be assessed.
1. Use evidence, not aspiration
Maturity should be based on observed process, system records, exceptions, reconciliations and user behaviour. Policy documents alone do not prove operation.
Interviews should be supported by sample transactions, access lists, close evidence, incident history and metrics.
A defensible assessment distinguishes design from operating effectiveness.
2. Level 1: fragmented and person-dependent
At the first level, data is collected manually, definitions vary and key knowledge sits with individuals. Approvals and evidence rely on email. Reconciliation occurs late and exceptions are informal.
The process may still produce results through experienced staff, but resilience and repeatability are low.
The priority is visibility of the process and material risks, not sophisticated analytics.
3. Level 2: documented and repeatable
Procedures, templates and calendars exist. Roles are partly defined and routine work follows a consistent sequence. Some controls are evidenced.
However, data remains duplicated, approvals may be manual and monitoring is retrospective. Local variations are common.
The priority is common definitions, ownership, inventory and basic workflow.
4. Level 3: controlled and governed
Authoritative data, maker-checker, limits, change control, reconciliation, exception ownership and periodic access review are established. Outputs can be reproduced.
Controls are linked to risk and materiality. Governance reviews trends and unresolved issues.
The priority is reducing manual handoffs and connecting domains without weakening assurance.
5. Level 4: connected and observable
Banks, ERPs and treasury workflows share a common data and identity model. Status, lineage and exceptions are visible end to end. Automation is monitored by business outcome.
Cash, forecast, payment, deal, accounting and evidence remain linked. Management receives decision-ready views.
The priority is optimisation, predictive insight and resilience across the connected platform.
6. Level 5: adaptive and continuously improved
The organisation adjusts rules, scenarios, buffers and workflows from measured performance. Controls are risk-based and data-driven. Resilience is regularly tested.
Advanced analytics support judgement without becoming opaque. Product governance manages ongoing change.
The level is not “fully autonomous treasury”; accountability and challenge remain central.
7. Assess governance and decision rights
Review policy ownership, delegated authority, committees, escalation, change and risk acceptance. Mature governance makes decisions and tracks actions rather than merely receiving reports.
Evidence includes approved policies, matrices, minutes, overdue actions and exception decisions.
Unclear ownership can hold back every other domain.
8. Assess data and master foundations
Review entity, account, counterparty, instrument, beneficiary and currency masters; source ownership; quality rules; lineage and reconciliation.
A dashboard cannot exceed the reliability of its data foundation. Duplicate identities and manual mapping are maturity constraints.
Measures include coverage, stale data, unknown records and manual adjustment.
9. Assess process and workflow
Review cash positioning, forecasting, payments, deals, settlement, accounting and close from source to outcome. Look for handoffs, rekeying, offline files and control duplication.
Mature workflow retains status and version and routes exceptions. It supports standard service with controlled local variation.
Cycle time should be considered with accuracy and control.
10. Assess access and segregation
Review roles across treasury, ERP, banks and administration; joiner-mover-leaver; authentication; recertification; service accounts and privileged access.
A mature environment detects cross-system conflicts and monitors unusual activity.
Completed annual review alone is not sufficient evidence.
11. Assess integration and observability
Review connection inventory, canonical data, expected events, business monitoring, recovery, idempotency and vendor dependency.
Maturity is shown by whether the organisation knows a financial event completed, not merely whether a file moved.
Incident history and recovery tests provide evidence.
12. Assess reconciliation and exception management
Review population completeness, matching, ageing, manual adjustment, certification, root cause and corrective action.
Mature processes reduce recurring causes rather than expanding repair teams.
Open value and age are more informative than auto-match percentage alone.
13. Assess evidence and auditability
Review source lineage, versions, approvals, before-and-after values, documents, settlement and retention. Select samples and attempt to reproduce decisions.
Maturity means evidence is generated during work and retrieved quickly.
A large archive of screenshots is not connected evidence.
14. Assess resilience and continuity
Review critical-service mapping, alternate banks or channels, staff cover, cyber response, recovery objectives and scenario testing.
Maturity requires testing the business outcome, such as completing a payment or cash position under disruption.
Unexercised procedures and expired credentials should lower the assessment.
15. Assess analytics and decision support
Review whether dashboards use governed definitions, expose freshness and enable action. Assess forecast learning, scenario use, limit insight and board narrative.
Advanced analytics without data quality and explainability should not receive a high score.
Decision latency and action completion are relevant measures.
16. Set target maturity by risk, not perfection
Not every process needs level five. Target should reflect materiality, volume, complexity, regulatory expectation and business strategy.
A low-volume local account may remain controlled at level three with a manual step, while global payments require connected level four capability.
The target should state outcomes, not technology labels.
17. Sequence the roadmap through dependencies
Data inventory and ownership usually precede automation. Access and master controls precede straight-through payment. Bank actuals and taxonomy precede predictive forecasting. Reconciliation and evidence should be designed with each release.
Initiatives should produce usable outcomes in stages. A foundation-only programme with no operating benefit can lose support.
Dependencies and interim controls should be explicit.
18. Measure progress and reassess
Roadmap metrics can include account coverage, approved-position time, forecast notice, straight-through payment, exception age, access conflicts, reconciliation and evidence retrieval.
Score changes should require evidence. Independent review can challenge optimistic self-assessment.
Maturity should be reassessed after material acquisition, system change or incident.
Assess maturity by domain, not by one average score
Cash visibility may be highly automated while beneficiary governance, valuation control or reporting remains manual. A single enterprise score can hide these differences. The assessment should rate domains such as data, access, payments, liquidity, instruments, reconciliation, evidence and governance against clear observable criteria.
For each domain, the reviewer should examine design, coverage, operating consistency, exception management, data quality and evidence. The result should distinguish missing control, partially deployed control and control that exists but is not used effectively. This makes the assessment suitable for prioritisation rather than marketing.
Define stage gates and outcome measures
Moving from one maturity level to another should require specific outcomes. Examples include authoritative account inventory, measured statement timeliness, policy-enforced approvals, controlled exception ownership, reconciled exposure data or repeatable board reporting. Technology installation alone is not a maturity outcome.
A roadmap should identify dependencies and exit criteria for each wave. Management can then decide whether to deepen a weak foundation or extend capability. Stage gates also reduce the risk that a transformation declares success when the operating process is still dependent on manual workarounds.
Use maturity assessment in acquisitions and operating-model change
An acquisition can introduce banks, entities, systems and local controls that materially change the treasury risk profile. The maturity framework can provide a rapid but disciplined view of connectivity, cash authority, payment controls, debt obligations, exposures and evidence in the acquired business.
The assessment should not force immediate uniformity where local requirements differ. It should identify minimum group controls, accepted local variation and the integration sequence. Repeating the assessment after major change shows whether risk has actually reduced.
Connect investment to measurable control improvement
The business case should link each initiative to the weakness it addresses and the metric expected to move: time to cash position, forecast error, rejected payments, aged breaks, excess access, concentration or reporting effort. Benefits should include avoided risk and capacity as well as direct cost.
Post-implementation review should compare the promised outcome with operating evidence. Where the metric did not improve, management should determine whether the design, adoption, data or measurement was wrong. Maturity becomes a continuous management discipline rather than a one-time diagnostic.
Reassess after control incidents and major change
A scheduled annual assessment may miss rapid deterioration after system replacement, organisational restructuring or a significant incident. The framework should define trigger-based reassessment for affected domains. This targeted review tests whether the event exposed a design gap, weak adoption or an inaccurate prior rating and ensures the roadmap reflects the current operating reality.
Practical illustration: automation without control maturity
A company automates bank-statement ingestion and reports high technical coverage. Review shows an incomplete account inventory, duplicate account mappings and no stale-data alert. Cash positioning is faster but can still omit material balances.
The maturity assessment rates connectivity above data governance and control. The roadmap prioritises account confirmation, stable identity, completeness and reconciliation before adding real-time analytics. Automation becomes a platform for control rather than a faster path to the same uncertainty.
Implementation checklist
A useful maturity assessment should include:
- evidence-based design and operating review;
- defined five-level scale;
- governance and decision rights;
- data, master and lineage foundation;
- end-to-end process and workflow;
- cross-system access and segregation;
- integration and business observability;
- reconciliation and exception resolution;
- versioned evidence and reproducibility;
- tested operational and cyber resilience;
- explainable analytics and action;
- risk-based target by process;
- dependency-led transformation sequence;
- interim controls during transition; and
- outcome metrics and periodic reassessment.
Common maturity-model failures
Common failures include scoring from policy alone, treating software implementation as maturity, averaging domains so a critical weakness disappears, setting level five as the target everywhere and producing a heat map without funded actions.
Another failure is measuring progress by completed projects rather than control and decision outcomes.
Closing perspective
A treasury control maturity model is a planning tool, not a badge. It helps management see where person-dependency, weak data or disconnected controls limit the operating model and where investment will create the greatest resilience.
By assessing evidence across governance, data, workflow, access, integration, reconciliation and analytics, treasury can sequence transformation on foundations that support both speed and assurance.
Frequently asked questions
What does treasury control maturity measure?
It measures how consistently treasury governance, data, workflow, access, integration, reconciliation, evidence, resilience and analytics produce controlled and explainable outcomes.
Is automation the highest level of maturity?
No. Automation can scale weak data or rules. Higher maturity combines automation with ownership, control, observability, evidence, adaptability and measured business outcomes.
How should treasury use a maturity assessment?
Use evidence to identify current level by domain, prioritise material risks and dependencies, define target outcomes and sequence initiatives with owners and metrics.