An AI cash forecast should not turn a missed customer receipt into an unreviewed funding move. Treasury needs a record that shows what changed, whether the number was calculated from approved inputs, which policy limit is implicated, and who accepted the response.
This guide supplies that record: a cash forecast variance and policy exception card. It is a practical control for a daily or rolling forecast when an AI assistant detects, explains, or prioritizes a variance. The card keeps calculation, explanation, and authority separate. It does not predict liquidity, authorize a transfer, or provide investment, legal, or accounting advice.
The timing is practical. On September 10, 2026, Ripple said its Treasury product expanded AI capabilities across forecasting, liquidity, risk, reconciliation, and reporting. Its description separates deterministic financial calculation from AI interpretation and says human approval remains required for financial actions. Treat that as a vendor statement about its product, not evidence of any firm’s control effectiveness. The useful design lesson is broader: an explanation can help a treasurer investigate, but it must not replace the approved calculation or the person authorized to act.
That distinction matters because cash forecasting is an operating input, not merely a dashboard. The U.S. Treasury describes advance forecasting and continual updates as important to daily cash-balance management. A corporate treasury team has different rules and obligations, but the same basic discipline applies: material movements need a known source, timing, owner, and review path.
Why a forecast variance needs its own control record
A forecast-to-actual gap has more than one possible cause. A collection may have moved by two days. A payment file may have been omitted. An ERP extract may be stale. A forecast owner may have changed an assumption. Or the actual may be right while the prior forecast was not. A chat-style answer such as “liquidity is tight because receivables slipped” collapses those possibilities before a reviewer can test them.
Use a separate card for each material forecast event. It preserves four boundaries:
- Deterministic calculation: The approved forecast engine, spreadsheet, or treasury-management system calculates opening cash, inflows, outflows, and variance from versioned inputs.
- AI interpretation: The AI may group cited drivers, draft questions, flag inconsistencies, and summarize an approved policy clause. It must not invent a receipt date, change a number, or classify an exception as approved.
- Policy evaluation: A rules engine or reviewer tests the calculated result against the firm’s approved liquidity floor, concentration limit, facility rule, or other policy.
- Action authority: A named person—not the assistant—approves, rejects, or escalates any move of cash, facility draw, payment change, or external communication.
This is narrower than an AI debt and Treasury-yield scenario card, which examines competing market narratives and their limits. Here the decision object is an internal cash forecast variance and the evidence required before a liquidity response. It also differs from a reconciliation exception handoff: reconciliation establishes whether recorded effects agree after the fact; this card governs a forecast exception before a treasury action is accepted.
The cash forecast variance and policy exception card
Create the card when a variance breaches the team’s documented materiality threshold, reduces policy headroom, reveals missing source data, or recurs beyond the team’s review rule. Do not copy balances, bank credentials, account numbers, or sensitive customer data into an AI prompt. Store links or approved record identifiers instead.
| Field | Record | Gate it answers |
|---|---|---|
| Forecast event ID | Legal entity, currency, forecast horizon, run timestamp, and prior/actual or revised version IDs | Can a reviewer reproduce the comparison? |
| Deterministic result | Opening cash, approved inflows/outflows, calculated variance, and calculation owner | Did an approved system calculate the number? |
| Variance driver | Timing, amount, new event, cancellation, FX, data-quality issue, or UNRESOLVED | Is the cause evidenced rather than guessed? |
| Evidence references | Bank, ERP, AP, AR, payroll, tax, procurement, or approved forecast-owner records | Can every material claim be traced? |
| Policy test | Policy ID/version, relevant limit, measured headroom, and rule-engine or reviewer result | Is this inside the approved boundary? |
| AI contribution | Exact source references, draft explanation, confidence limitation, and prohibited actions | Did AI organize evidence without becoming the authority? |
| Proposed response | Investigate, revise forecast, hold for review, or request an authorized liquidity decision | Is the response merely a recommendation? |
| Approval and segregation | Forecast owner, treasury reviewer, authorized approver, timestamp, and conflict check | Did the right people make the decision? |
| Follow-up | Actual outcome, root-cause disposition, retraining/configuration decision, and due date | Will the forecast improve without overwriting history? |
The card should remain immutable after approval. A corrected forecast is a new version linked to the prior card; it is not a silent edit. That same event-and-version discipline supports reliable ledger and reconciliation design, where an apparently successful process is not proof that the financial record is complete or unique.
Set the decision gates before an exception occurs
Do not ask a model to choose a threshold or infer a policy. Treasury should document thresholds and owners in its own risk appetite and procedures. The workflow below turns those existing rules into operational states.
| Status | Meaning | Human next step |
|---|---|---|
EVIDENCE_REQUIRED | A source, timestamp, calculation version, or variance explanation is absent or conflicts | Obtain or correct the evidence; no liquidity recommendation passes |
WITHIN_POLICY_REVIEW | Calculation and evidence are complete; headroom remains inside policy | Named reviewer may accept the forecast revision or request more analysis |
POLICY_EXCEPTION_PENDING | Calculated position or proposed response exceeds a policy boundary | Route to the authorized exception approver; do not execute from the card |
CONTROL_STOP | Conflicting source records, an unapproved write path, stale material data, or a missing approver exists | Stop automated routing and use the incident or manual procedure |
CLOSED_WITH_LEARNING | Actual outcome and root cause are recorded after the approved response | Review recurring drivers under the firm’s model/change controls |
These are workflow labels, not universal liquidity classifications. A firm may use different thresholds for a daily cash position, a 13-week forecast, a subsidiary, or a regulated entity. The important rule is that the model cannot turn an undefined policy into a confident green status.
A copyable prompt for evidence-bound triage
Use this prompt only with approved, minimized documents and record IDs. It drafts a review artifact; it must not change forecasts or act on a bank account.
You are a treasury forecast-variance evidence reviewer.
Use only the supplied approved records. Do not estimate cash, alter a forecast,
approve a policy exception, initiate a payment, transfer funds, draw a facility,
or communicate externally.
Return valid YAML with exactly these fields:
forecast_event_id:
entity_and_currency:
horizon_and_run_timestamp:
forecast_versions_compared:
deterministic_calculation_ref:
variance_amount_and_direction:
variance_driver: TIMING | AMOUNT | NEW_EVENT | CANCELLATION | FX |
DATA_QUALITY | UNRESOLVED
cited_evidence_refs:
evidence_gaps:
policy_id_and_version:
policy_test_result:
headroom_or_limit_ref:
permitted_recommendations:
prohibited_actions:
required_human_owners:
follow_up_test:
status: EVIDENCE_REQUIRED | WITHIN_POLICY_REVIEW |
POLICY_EXCEPTION_PENDING | CONTROL_STOP
Set EVIDENCE_REQUIRED if a material amount, timing, source, calculation version,
or policy reference is missing. Set CONTROL_STOP if records conflict, a source is
stale under the supplied rule, an unapproved write path exists, or no authorized
owner is named. Never fill gaps with assumptions. Cite record identifiers for
every driver and explicitly list the person or team that must resolve each gap.The output is deliberately constrained. It makes a useful handoff easier, but the approved forecast process and the authorized treasury role remain the decision makers.
Test the card against failure cases
Run a controlled test before connecting the workflow to production data or a treasury-management system. These cases probe whether the card fails safely.
| Test case | Expected result |
|---|---|
| AR says a major receipt moved, but no source record or customer-approved update is supplied | EVIDENCE_REQUIRED; the AI cannot make up a new receipt date |
| The forecast workbook version differs from the version cited in the policy test | EVIDENCE_REQUIRED; recompute and relink the result |
| Calculated end-of-day cash is inside the floor, but a proposed facility draw would exceed a separate policy limit | POLICY_EXCEPTION_PENDING; preserve both policy tests |
| Two sources give different amounts for the same payroll run | CONTROL_STOP; route to the named record owner before any action |
| A reviewer asks the assistant to release a bank transfer because the explanation is persuasive | CONTROL_STOP; the action is outside the assistant’s boundary |
| A one-off timing shift is evidenced and the authorized reviewer accepts a revised forecast | WITHIN_POLICY_REVIEW; retain the original, revised version, evidence, and approval |
For broader availability failures—such as an upstream bank feed or model provider outage—use an AI outage recovery drill alongside this card. The drill restores a safe operating mode; the card records whether a particular forecast difference has enough evidence to proceed through the normal policy path.
Measure learning without rewarding overconfidence
Avoid using a single accuracy figure as proof that an AI-assisted forecast is controlled. Track measures that expose uncertainty and handoff quality:
- Share of material variance cards with a reproducible calculation and complete evidence references.
- Time from material variance detection to named human ownership.
- Variance drivers by type, entity, forecast horizon, and recurrence.
- Share of cards stopped for stale data, source conflict, or missing authority.
- Policy exceptions by policy version and final human disposition.
- Difference between a forecast revision and the later actual, separated from the quality of the original evidence.
- Reopened cards caused by an incorrect driver classification or a missing record.
Review the measures in the firm’s existing forecast, risk, and change-control cadence. Do not use them to pressure teams into classifying uncertain data as complete. A growing EVIDENCE_REQUIRED count can reveal a source-data problem sooner than a polished but unsupported forecast narrative.
Keep the AI on the explanation side of the line
The best use of AI in treasury is often to make a variance review more legible: list the evidence, expose a missing timestamp, identify the relevant policy clause, and prepare questions for the authorized reviewer. It is not to calculate an unauditable balance or make a liquidity decision because the answer sounds plausible.
Adopt the card first in shadow or recommendation mode. Compare its classifications with the existing human process, correct its evidence mapping, and test stop conditions before any wider integration. The NIST AI Risk Management Framework is a useful general reference for treating AI risk as a lifecycle practice; the card gives a treasury team a small, reviewable artifact for that practice at the forecast-to-action boundary.
Sources
- Ripple Treasury: Governed AI for Enterprise Treasury, September 10, 2026. Vendor product announcement; cited only for its stated product design.
- U.S. Treasury Fiscal Service: Cash Forecasting
- U.S. Treasury Fiscal Service: Disbursing Forecasting
- NIST AI Risk Management Framework
About Enis
AI Engineer specializing in Machine Learning and LLMs. Combining Computer Engineering and Economics to build data-driven financial tools.