Agicap's 13-week forecast needs a weekly roll-forward ledger

Freeze one week before advancing the horizon

A rolling forecast should retain each published version instead of overwriting it when the 13-week window moves. Identify legal entity, account or cash pool, currency, opening balance, included bank and ERP feeds, forecast week boundaries and time zone, issue time, data cutoff, scenario, category map, formula or model version, owner, and approved use. Keep the prior version, later revisions, and the decision that used each version linked by stable identity.

At weekly close, map each prior forecast row to an observed bank or accounting actual, a confirmed but still unsettled item, a re-dated item, a canceled item, or an unresolved exception. A row that moves from week one to week two must retain its original expected date and change reason. Do not call a forecast 'actual' because an invoice was approved, a payment was submitted, or a transaction appeared in only one system.

Reconcile categories and source clocks

The Agicap page says bank and accounting flows, receivables, payables, reconciliation, and transfers can feed the cash cycle. Those are provider-documented positions, not proof of a particular customer's feed completeness or latency. A buyer should map each category to its source records: invoice, purchase commitment, payroll, tax, debt, intercompany movement, collection estimate, bank transaction, and manual adjustment. Preserve source identifier, value date, booking date, observation and receipt times, and data-quality flags.

A bank transaction can close several forecast rows; one forecast row can settle partially; a transfer can leave one account before reaching another; a reversal can arrive after the week closes. Define matching keys, tolerances, currency treatment, duplicate rules, split and merge logic, and escalation before computing variances. Keep restricted and encumbered cash, unconfirmed receipts, and forecast-only items visible. A consolidated view must not imply that every entity's money is interchangeable.

Explain variance without changing the old answer

Report a roll-forward bridge by week, entity, currency, and category: prior forecast, actualized amount, timing shift, amount revision, new item, removed item, unresolved item, and new forecast. Use a declared denominator and exclude rows whose actual cannot yet be observed from an accuracy calculation. Record source corrections and revised category mappings separately so the historic forecast can still be reproduced as it was known at its decision cutoff.

The bridge should answer the next treasury action—funding, payment release, borrowing, investment, or escalation—without becoming an instruction by itself. Treasury, finance, accounting, and authorized bank signers retain approval, settlement, valuation, policy, and books-and-records decisions. Agicap's public claim that its platform may improve visibility or returns is not an independently observed financial result.

Test a deliberately messy 13-week cycle

A buyer demonstration should freeze one 13-week version, then add a late bank feed, duplicate invoice, partial collection, transferred cash, canceled payable, delayed payroll item, currency conversion change, reversal, and prior-period accounting correction. Advance one week and require the system to explain every original row's disposition, regenerate opening balances, preserve the old decision view, and show which exceptions still need a person. Compare the resulting bridge with the same source records outside the product.

Treasury Operations Review reviewed Agicap's registered official page on September 15, 2026 but did not access a tenant, customer bank, ERP, account, forecast, formula, feed, actual, matching rule, payment, reconciliation, or decision. The page establishes the stated 13-week and integrated-cash positioning only. It does not establish any configured customer workflow, completeness, accuracy, efficiency, liquidity result, debt or investment return, control effectiveness, or outcome.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Treasury Operations Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.