# Operating expenses — first delivery of branch cash control Apply migration `m261001_000012_expenses` with `php yii migrate`. This adds operating expense categories, expense drafts, payment records and reversal requests. New references use EXP, EPM and ERV prefixes. Existing surplus-return expenses remain separate and are not imported or recreated here. ## Capture and approval Loan officers, branch managers, finance officers and the CEO can prepare expenses within their permitted branches. The administrator's support role has no financial preparation or approval authority. Auditors and authorised branch staff can read records and evidence within their existing branch scope. Choose an operating category, branch, payee, incurred date and positive ZMW amount; attach the invoice or supporting evidence. Save as a draft, then submit. Only the original preparer can edit or submit a draft, and its originating branch stays fixed. Submission freezes the details and evidence. The CEO approves or rejects with a reason and cannot approve their own preparation. Rejected records remain immutable; create a new draft for a corrected expense and cite the rejected reference in the description. Approved costs are unpaid obligations. Approval does not record a payment, deduct cash or create an account movement. ## Payment and corrections For approved expenses, record the actual date, amount, payment method and proof. Partial payments are supported. Pending payments reserve the remaining approved amount so two submissions cannot overpay the same expense. The CEO separately verifies or rejects the evidence and cannot verify their own payment submission. Verified payments move the expense to partially paid or paid. Repeat decisions cannot post twice. Cash payments receive an automatic internal code without requiring a manually invented receipt number. Bank and mobile-money payments also require the genuine provider transaction ID. Provider references use the shared outgoing-reference registry, which prevents reuse across loan disbursements, surplus returns and expense payments. Pending and rejected submissions retain their reference reservation and evidence; a correction must explain the earlier submission rather than bypass duplicate protection. A verified payment can have one pending full reversal request. Record the effective date, reason and supporting correction or refund evidence. The CEO approves or rejects with a reason, separately from preparation. Approval preserves the original amount, provider reference and proof, marks its posting reversed, and records a separate dated reversal. The expense's unpaid obligation reopens accordingly. Rejected reversals leave the payment unchanged. A reversal is a documented posting correction or evidenced refund, not an automatic transfer of money. ## Reports and alerts The register and reports filter by permitted branch, operating category, current stage and date range. The incurred-cost report uses incurred dates and shows captured amount, net verified paid through the end date, and approved unpaid amounts. Draft and rejected amounts are shown as captured records but are not approved payables. Review status reflects current knowledge, including later verification or correction of earlier dated evidence. The separate payment report uses payment and reversal effective dates. Positive amounts are verified expense payments; approved corrections are separate negative rows. Pending and rejected payments, surplus returns, loan disbursements and recovery transactions are excluded. Totals are not account balances. Export CSV or print/save PDF with the same access checks, metadata and definitions as the screen. CEO alerts cover expense approval, payment verification and reversal approval. Approved unpaid amounts appear as payment tasks for staff with expense preparation permission in the originating branch. Rejection decisions notify their preparer and disappear when acknowledged. Approval tasks disappear automatically when resolved. Success and informational flash banners disappear after five seconds. Hovering, keyboard focus or a hidden browser tab pauses automatic dismissal; the close button remains available. Errors and warnings stay visible for correction or review. This banner behaviour applies throughout the system. ## Client nationality selection Client create/edit and inline application client creation use the same searchable country/territory dropdown. New clients default to Zambia; staff can select another country or leave the optional field blank. The bundled 249-country/territory list derives from the public-domain IANA ISO 3166 table with familiar country labels. Existing free-text nationality values remain selectable on their original records, while newly entered values must come from the list. Existing records are not rewritten. ## Application client and collateral context Starting an application from a client profile validates and preselects that client. The form renders only collateral belonging to that client at their branch; changing the client refreshes the list and clears previous choices. No collateral is rendered before a client is selected, or while creating a new client. The read endpoint enforces application preparation permission and client branch scope. Inline collateral derives its owner and branch from the selected client, or from the new client saved in the same transaction. Submitted collateral owner/branch fields cannot override this. Intake details remain unset because application entry creates a pledge; physical receipt is a separate step. Existing applications cannot change client, and the service independently rechecks collateral ownership and branch on save and submission. ## Following delivery Financial accounts, opening floats, integration of source transactions with account movements, paired branch fund transfers, recurring expense templates and daily cash reconciliation remain the next part of this phase. They must link to existing verified expense payments and surplus returns once, rather than recreating costs. No production data is imported by this migration.