# Business history and cash control

Business history uses plain-language activities, the staff member, business reference, branch and decision explanation. Date, branch, staff and category filters help locate an event. Raw codes, field changes and JSON are on a separate administrator-only page with date, branch, actor, action, record type, record ID and payload-search filters. A CEO is denied raw data even if also assigned the administrator role. Branch-limited audit readers see only events attributed to their assigned branches. New events snapshot their branch when recorded. Old events are attributed only when their original payload already recorded a valid branch; other historical events remain visible to organisation-wide readers without invented attribution.

## Accounts and opening balances

Cash control appears under More. A preparer proposes an account for a branch and payment method, supplies opening evidence and selects an opening date. A different CEO approver activates it. There is one active account per branch/payment method (Cash, Bank transfer or Mobile money), in ZMW. The opening balance is the start-of-day balance on that date: activity before the date must already be reflected in the supplied opening balance. Verified activity on or after the date is linked at activation and then during subsequent verification. Choose this cutover carefully to avoid including the same transaction in both opening cash and linked movements. Pending proposals never affect cash.

Verified loan payouts, repayments, recovery proceeds, client surplus returns and operating expenses create immutable linked movements once. A sale records gross proceeds and approved selling costs separately in its selected payment method; the costs are treated as paid from that same account. Do not record those selling costs again as an operating expense. Surplus returns are counted once, including when they have a linked surplus-expense record. Reloan debt transfers are not cash. Repayment posting corrections retain their original effective payment date, following the existing repayment-reversal policy; they do not claim to represent a new physical refund. Expense reversals use their documented effective date. Account positions may be negative after legitimate linked transactions; dispatch cannot exceed available funds. Accounts are internal records, without automatic bank feeds.

Account activation and verification serialize on the branch to prevent a source transaction being missed during cutover. Source/leg uniqueness prevents retry duplication. Account movements have date filters and a protected CSV export. Existing verified transactions do not stop solely because a branch has no account yet; they are linked when an account is activated with an appropriate cutover date.

## Transfers

A source-branch preparer requests a fixed transfer to an active account. The destination selector shows branch/account labels across branches, without granting access to destination balances or account evidence. A different CEO approver checks the request and available source funds, including other approved reservations. Approval reserves funds but does not move the book balance.

Source staff record actual dispatch with proof. Source funds then decrease and the transfer remains in transit. A different staff member with destination access records receipt with proof; only then does the destination increase. Receipt cannot precede dispatch. Repeated dispatch/receipt and branch bypasses are blocked. Both participating branches can see the transfer and its evidence; account balances and opening evidence remain scoped separately. Pending approvals notify the CEO, dispatch notifies source preparers and in-transit receipts notify eligible destination preparers.

## Closing reconciliation

A preparer supplies a counted cash or statement balance, closing date, explanation and evidence. The system records the book balance and difference as an immutable snapshot. CEO approval acknowledges the comparison; it never inserts an adjustment to force the balance to match. Resolve differences through evidenced business corrections. If a late verification changes movements through the closing date, the snapshot becomes stale and cannot be approved: reject it and prepare a new one. Previously approved snapshots also display subsequent changes. This is a review workflow, not a ledger-period lock. Future transactions are not prevented by an approved reconciliation.

Run `php yii migrate` after deployment. Migration 000013 adds the account tables, audit branch attribution and permissions; rollback requires a reviewed data-preservation plan.