Understanding cash proof

Cash proof examines the relationship between accounting records and bank activity over a defined period. It is not a shortcut for concluding that reported revenue or earnings is correct in every respect.

Start with account completeness. Identify the relevant bank accounts, currencies, entities, and statement periods. Missing accounts or partial statements limit the analysis even when the available records reconcile.

Establish opening and closing balances and reconcile movements. Confirm how transfers, financing activity, owner transactions, and other non-operating flows are treated before comparing cash with operating performance.

Separate cash receipts from revenue recognition. Collections may relate to earlier sales, customer deposits, tax amounts, or non-revenue activity. A bank deposit is evidence of a cash movement, not a complete accounting conclusion.

The core of a cash proof is a simple bridge, built for every month and every account: opening bank balance, plus deposits, less disbursements, equals closing bank balance. The same bridge is then built from the ledger. The two should agree, and every difference should have a name.

A monthly bridge

• Opening balance per bank statement
• Deposits per bank, grouped into customer receipts, transfers in, financing, and other
• Disbursements per bank, grouped into vendor payments, payroll, transfers out, debt service, distributions, and other
• Closing balance per bank statement
• The same four lines from the general ledger cash accounts, with reconciling items listed between them

Use supporting schedules where necessary. Receivables, deferred revenue, merchant settlement reports, and intercompany records can explain differences that a simple comparison of totals would leave unresolved.

Maintain source references for reconciling items. Reviewers should be able to trace a material difference to the bank statement, ledger entry, or schedule that supports the explanation.

Most differences between bank and ledger are timing: deposits in transit, outstanding cheques, merchant settlements that land days after the sale, and credit card payments cleared in the following month. These are expected, and they should reverse. A timing item that never reverses is not a timing item.

Classification differences are the second group. A loan draw booked as revenue, an owner contribution booked as a customer receipt, or a refund netted against sales all leave the bank total correct and the income statement wrong. The cash proof is often the only test that catches them.

Compare receipts to revenue by month, not only for the year. A business that bills in advance or collects on long terms will show receipts leading or lagging revenue, and the pattern should be stable. A sudden change in the gap near a measurement date deserves a question.

Where the ledger comes from an accounting system with bank feeds, the posting dates and bank dates are already paired, which makes timing analysis routine. Where the ledger is uploaded from statements and exports, agree the month boundaries and date conventions before building the bridge.

Treat missing evidence as a scope limitation. If a period cannot be assessed, state that directly and identify the records needed to complete the work.

Report unresolved differences by amount, direction, and month, and say what was tried. A difference of a few hundred dollars that has been searched is different from a difference of the same size that has not been looked at.

Keep the proof separate from the opinion. The proof shows that the bank activity and the ledger agree within explained items. Whether the resulting revenue is high quality, sustainable, or correctly recognized is a different question answered by other work.

In Finsider Platform, cash proof runs once bank transactions have been ingested for the period; without bank data the check is reported as not applicable rather than passed. This methodology note proposes a review sequence. It does not present empirical benchmark results or certify the accounting treatment of any transaction.