In Kyriba’s 2026 CFO Risk Radar survey, only 26% of finance teams reported running continuous or automated scenario modeling. The other 74% are still working off a calendar, monthly, quarterly, sometimes annually, while the risks they are modeling do not wait for the next review cycle. Manual forecasting and fragmented payment workflows look like two separate problems. They are the same problem, showing up in two places.

The same survey found that 83% of finance teams cannot quantify a risk’s financial impact in real time. For a CFO, the relevant question is whether treasury can price an exposure while decision options still exist, not whether a model appears in the monthly reporting pack.

Both findings point to the same maturity gap: the absence of a centralized, real-time cleansed data foundation connecting planning with execution. Finance teams often describe the gap as a staffing or tooling constraint. The deeper issue is governance design. The data and controls are not connected closely or timely enough to the decisions treasury is expected to make.

Two symptoms of one maturity gap

Spreadsheet-dependent forecasting is the planning-side symptom. Fragmented payment execution is the execution-side symptom. The processes look different, yet both require practitioners to reconcile disconnected information before the organization can see its liquidity position clearly enough to act.

Process inefficiency is slow work. Data fragmentation is a blind spot. Corporates with lower practice maturity lean on additional overhead to reduce the queue of files waiting for review, while leaving the blind spot intact. The distinction matters most when finance leaders are allocating investment across separate forecasting and payments initiatives, with separate owners, priorities, business cases, and milestones.

A forecast cannot stay current when payment data arrives late or in inconsistent formats. Faster payment execution cannot compensate for a risk view built on balances that have not been consolidated. The shared constraint sits underneath both workflows: treasury lacks one dependable view of what has happened, what is in motion, and what may require funding next.

Why manual forecasting cannot scale

A manual forecast usually fails in the same places, regardless of how experienced the team may be. Data arrives from multiple banks and entities. The analyst downloads or requests files, maps different formats, reconciles balances, investigates variances, and then updates the model. The forecast becomes available after the work is complete.

The reconciliation step that consumes two hours on a Monday morning is rarely the calculation. It is the variance investigation: an entity settled on Tuesday in one system, Wednesday in another, and now shows a balance discrepancy no one can explain until the right person responds to an email. The model may be mathematically sound. The inputs still depend on timing, interpretation, and tacit knowledge.

The process creates a single-point-of-failure dependency at scale. The practitioners who run the model know which account file to use, which entity has an unusual settlement pattern, which intercompany balance requires adjustment, and which assumption changed since the last cycle. When they are unavailable, another analyst rebuilds the logic under time pressure.

Workforce concerns make the fragility harder to ignore. 57% of finance teams report being very or somewhat concerned about workforce issues, including hiring, retention, and skills. Adding headcount fixes a staffing problem. It does not fix a structural one. More people performing manual workflows can increase throughput for a period, while preserving the same dependency on fragmented data and tacit knowledge.

The cadence data explains why the quantification problem persists. Only 26% of teams run continuous or automated scenario modeling, while 34% model monthly, 35% quarterly, and 3% annually. A calendar-based model can support a scheduled review. It cannot reliably answer what a new counterparty issue, delayed customer receipt, unexpected funding need, or currency move means for liquidity in the hours after the event occurs.

An 83% inability to quantify financial impact in real time is therefore a workflow finding, not just a modeling finding. When the scenario model updates after the risk event, treasury is measuring an exposure after the decision window has narrowed.

Why fragmented payments compound the problem

Payment fragmentation creates the same visibility lag on the execution side. A multi-portal operating model may contain the required information, yet information spread across multiple portals and entity processes is not the same as a governed, decision-ready cash position.

Analysts still need to compare and ensure balance availability, confirm released and pending payments, reconcile exceptions, and determine whether a payment has cleared the control process.

The operational detail matters. A payment may be approved in one workflow, released through another, and confirmed in a bank portal that the forecast does not yet reflect. The result is a gap between the position treasury plans and the position the organization is actually executing. Cash becomes visible after movement rather than before it. The impact can be in the form of a costly overdraft or suboptimal yield on cash.

Only 38% of finance teams report high confidence in their ability to analyze real-time risk exposure. Data integrity, availability and decision confidence are different capabilities. A balance or transaction that technically exists somewhere in a disparate environment is not a trusted input for forecasting, funding, hedging, or liquidity governance.

Controls expose the same divide. A control performed after a payment has moved is a review. A control embedded in the payment workflow can prevent, route, or escalate an exception before funds leave the account. One approach produces audit evidence. The other protects money in motion.

A payment process that cannot configure controls based on audit requirements cannot support the governance structure that continuous liquidity intelligence requires. Payment centralization coupled with systematic auditability and traceability is therefore a maturity prerequisite, not simply an efficiency initiative.

One misstep or control weakness can have significant reputational impact. A payment process must have a continuous, autonomous, always-on framework that protects ahead of an incident not after the fact. You cannot get there if your payment workflows still live in multiple different bank portals.

Centralization does not mean eliminating judgment or forcing every entity into a standardized operating model. It means creating a consistent foundation for account data, payment status, approvals, exceptions, fraud detection and liquidity movements across banks, entities, and currencies. A connected data layer can then automatically feed the forecast with current execution data and give payment decisions the context of the liquidity position treasury is managing toward.

Build the infrastructure, not just the mindset

Finance teams do not reach continuous liquidity intelligence by asking practitioners to work harder, document more carefully, or add another review meeting. Discipline matters, yet discipline applied to disconnected data will produce delayed answers when treasury can least afford them.

The real cost of manual treasury work is the narrowing of options. By the time a manual process surfaces the risk, the decision that would have mattered most may already be unavailable.

Start with a data-structure audit. Map where payment data lives, who consolidates it, and how long it takes to reach the forecast. Those answers will show where the maturity gap sits and which controls need to move inside the process.

Stop treating forecasting and payments as separate line items. Start treating them as one maturity problem.