Bank transfer and deposit workflows

Capture bank references, confirm transfer attempts, govern cash deposits and preserve the P6 reconciliation handoff.

Product-truth rule

Makronexus keeps several records deliberately separate. A payer's intention, a provider session, a Payment record, an invoice allocation, a receipt, a cashier count, a bank deposit and a reconciliation match answer different questions. Never collapse them into one green badge. A safe operator follows the evidence chain and names the exact record that proves each claim.

At Mupfure Learning Academy, use the authenticated tenant and selected school on every collection action. Confirm the student, invoice, currency, amount, channel and business date before mutation. Use generated identifiers and audit fields after mutation; do not rely on a toast, copied reference or printed page as the sole proof. Where a provider is missing, inactive or lacks credentials, provider workspaces may show warnings or placeholder data. Placeholder rows are not transactions and must never enter a handover, receipt or reconciliation total.

Learning outcomes

By the end of this chapter, you can:

• explain the records and lifecycle dimensions used by this workflow;
• choose the correct workspace and exact permission for each action;
• perform the workflow without treating a UI success message as financial proof;
• identify exceptions before they alter invoices, cash, receipts or external evidence;
• assemble an audit trail another reviewer can reproduce.

Prerequisites

• Active bank-transfer provider or approved manual method
• Verified school bank account
• P6 reconciliation boundary understood

Key definitions and boundaries

Bank-transfer attempts may represent ZIPIT, RTGS, EFT or manual-deposit flows. The provider workspace reads Payment Attempts and can manually confirm a transfer under route-specific edit authority. A confirmed attempt should be linked to a Payment before allocation or receipt. A cash deposit batch is not a student Payment: it moves already collected physical cash from accepted custody into Cash in Transit and later bank evidence.

Roles and exact permissions

Use only abilities assigned for the active tenant and school. Backend enforcement remains authoritative, and route aliases do not replace endpoint-specific permissions.

• payment_attempt:view
• payment_attempt:read
• payment_attempt:update
• payment_attempt:confirm
• financial_payment:create
• financial_payment:verify
• financial_payment:reconcile
• finance_control:read
• finance_control:approve
• finance_control:readiness

A role that can view a record does not automatically have authority to create, confirm, verify, allocate, refund, approve or delete it. Apply segregation of duties for independent monetary decisions.

Workflow map

Guided procedure

1. Verify configuration and real-data status

Confirm the school has an active bank-transfer provider or approved manual process and that the target bank account belongs to the selected school. Provider pages can display configuration warnings and demo data. Do not confirm, receipt or report placeholder rows.

2. Capture payer transfer evidence

Record student, invoices, amount, currency, payer, method and bank reference. For an asynchronous transfer, initiate or locate the Payment Attempt. Preserve idempotency and gateway/reference identifiers. ZIPIT, RTGS, EFT and manual deposit can have different settlement timing; do not convert “reference received” into “funds cleared” without evidence.

3. Confirm under segregation

Manual confirmation is a monetary action. The reviewer checks amount, currency, beneficiary account, payer reference, student identity and duplicate search. Confirm the attempt only once. Then read the resulting Payment and verify that the attempt's paymentId, amount and invoice allocations agree. If no Payment exists, the collection lifecycle is incomplete.

4. Keep verification and reconciliation distinct

Payment verification records that an authorised reviewer accepted the available evidence. Payment reconciliation links to a bank transaction, statement line or batch and belongs to the downstream external-match control. P4 can record the reference and leave the Payment unreconciled. Full statement import, matching and discrepancy resolution are taught in P6.

5. Govern deposits from physical cash

Use Deposit Batches only after cash-up approval and custody acceptance. The manifest must be derived from custody, not typed from memory. Record witnesses, dispatch, destination bank account, expected amount and currency. Statement confirmation closes the external leg; residual differences remain visible and require controlled resolution.

Worked Mupfure scenario

A guardian sends USD 600 by ZIPIT. The bursar finds the pending attempt, compares the bank notification to the school's account and student invoice, checks for duplicate references, and confirms it. The attempt becomes succeeded and links to one Payment. The Payment is verified, allocated and receipted but remains unreconciled until the statement line arrives. Separately, a USD 2,000 cash deposit batch is derived from two accepted custody bags; it is not allocated to student invoices again because those student Payments already exist.

Control standard

Apply the following control standard to every collection channel:

1. Identify the payer, student, school, currency and obligation independently.
2. Authorise the operator through the exact route permission, not only menu visibility.
3. Capture the channel evidence required for that method, such as a bank reference, mobile number, card last four digits or cash-session identity.
4. Verify the resulting lifecycle state and immutable identifiers after the request completes.
5. Allocate only against valid invoices and prove that allocated plus unallocated value equals the payment amount.
6. Issue evidence only from the saved Payment and its allocation context.
7. Handover cash, provider and exception evidence to the correct downstream workspace without pretending that P5 posting or P6 reconciliation is complete.

Maker and reviewer should be different people for verification, refunds, cash-up approval, custody acceptance, deposit dispatch and any manual provider confirmation. When staffing makes this impossible, record the approved exception and obtain retrospective review under school policy. Never share credentials, edit gateway payloads, reuse another operator's session, or delete evidence merely to remove a discrepancy.

Failure modes

Failure or warning	Required response
Provider not configured	Stop real processing; warning or demo data is not evidence.
Reference duplicated	Hold all candidates and compare payer, amount, timestamp and provider identifiers before confirmation.
Attempt confirmed without Payment	Do not allocate or receipt. Investigate callback/materialisation failure.
Bank reference treated as reconciliation	Leave reconciliation status explicit until matched to external bank evidence.
Deposit batch rebuilt from spreadsheet	Recreate it from accepted custody lineage and preserve the rejected attempt.

Verification checklist

Before declaring this workflow complete, verify:

• the tenant, school, student and operator identities are correct;
• amount, currency, business/payment date and channel agree with source evidence;
• every attempt, Payment, allocation, receipt or control record has its own saved identifier;
• lifecycle states are read from the saved records after mutation;
• allocated and unallocated values conserve the Payment amount;
• duplicate and idempotency searches were completed where uncertainty existed;
• approval, verification and exception notes identify actors and timestamps;
• cash/provider/bank evidence was handed to the correct downstream workspace;
• no P5 posting or P6 reconciliation completion is claimed without those records.

Practice and knowledge check

1. State the evidence needed to manually confirm a bank transfer.
2. Explain why a cash deposit batch must not create another student Payment.
3. Trace one transfer from attempt to Payment to P6 handoff.

Record your answers with the Payment/attempt/receipt/control IDs used. A reviewer must be able to reproduce the result from Makronexus without relying on screenshots alone.