AI belongs in the forecast and in the analysis. It does not belong in the ledger. The distinction matters because the two jobs have opposite requirements: a forecast is expected to be an estimate, and a ledger entry is expected to be defensible.
Why the ledger runs on rules
An accounting entry has to be reproducible. The same event, under the same rules, should always produce the same entry, and anyone should be able to trace that entry back to the event that caused it. An auditor, a lender or an acquirer will ask exactly that question. A system that decides case by case, however sophisticated, cannot answer it the same way twice.
Why the forecast is different
Projecting cash from payout timing, receivables and committed purchase orders is estimation work, and everyone reading the output knows it is an estimate. That is the right place for a model, because being approximately right early is more useful than being exactly right late.
The part most conversations skip
A model is only as good as the records it reads. Point one at five systems that were never reconciled with each other, and it will inherit every disagreement between them and answer anyway, fluently and with confidence. The answer will be wrong in ways that are hard to spot, because the reasoning looks sound and the numbers look precise.
This is the practical argument for putting operations and financials on the same records before adding intelligence on top. Not because AI is risky, but because the quality of any answer is set by the quality of what it read.
What to ask a vendor
Where do the numbers come from, and can a specific figure be traced back to the event that created it? If the answer involves a nightly sync between two systems, the intelligence layer sits on top of a reconciliation problem.
Focal posts ledger entries from operational events by rule, so each one traces back to what caused it, and keeps prediction in the forecast layer where an estimate is the point.
