Reversals, refunds, and chargebacks

Correct recorded collections through approved return evidence rather than destructive edits or negative payments.

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

• Original Payment, allocations and receipts identified
• Approved refund/reversal authority and settlement account
• P5/P6 handoff understood

Key definitions and boundaries

A refund returns value to the payer and records amount, reason, reference and optional method/settlement/FX/approval evidence. A reversal neutralises an erroneous collection under the applicable contract. A chargeback is a provider- or bank-originated return/dispute and requires external evidence. A receipt cancellation is not a refund. A credit note reduces an invoice obligation and is not a cash return. Historical return-layer corrections are specialist compensating operations that preserve physical units and lifecycle while correcting functional carrying 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.

• financial_payment:refund
• financial_payment:read
• financial_payment:verify
• financial_payment:reconcile
• financial_receipt:create
• financial_receipt:cancel
• stripe_gateway:create_refund
• finance_control:approve

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. Diagnose before choosing the correction

Compare invoice obligation, Payment, allocation, receipt, cash/provider evidence and external settlement. If the invoice itself is wrong but no funds should return, use a credit note. If funds were received and must be returned, use refund controls. If the Payment was erroneous or duplicated, use the supported reversal/cancellation path. A chargeback starts from external provider/bank evidence and may arrive without school initiation.

2. Define the return amount and currency

Refund amount must be positive and cannot exceed captured value. For partial refunds, explain which allocation or student-credit component is being returned. Multi-currency returns require transaction and ledger amounts, refund rate, rate mode, override reason where applicable, settlement account and timestamps. Never use today's convenient rate without the governed contract.

3. Obtain independent approval

Record reason, supporting reference/document, requester, approver and idempotency key. High-risk returns should not be approved by the original cashier. Provider-specific submission, such as Stripe refund, needs the gateway permission but must still reconcile to the Financial Payment refund record and accounting effects.

4. Preserve related evidence

Verify Payment status (partially_refunded, refunded or reversed as applicable), refund amount/reference, allocation effects, student balance, refund receipt or cancellation treatment, provider result and settlement handoff. Do not delete the original Payment or overwrite its amount. Do not issue a negative Payment.

5. Use historical correction only for proven layer errors

Historical return-layer correction requires live atomic posting, approval, supporting reference and idempotency. It changes functional carrying evidence through a compensating journal while preserving original counterparty units and status. It is not a general refund editing tool and normally belongs to specialist accounting support.

Worked Mupfure scenario

A parent paid USD 400, fully allocated to tuition, and received an approved receipt. The school later approves a USD 100 cash refund because the student withdrew before service. The maker identifies the original Payment and allocation, enters USD 100, reason, settlement account and support, and obtains independent approval. The returned cash is recorded through the authorised channel, Payment becomes partially refunded, the student balance and receipt evidence are reviewed, and P5/P6 teams receive the return identifiers. The original Payment remains USD 400 in the audit trail.

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
Credit note used as refund	Correct the obligation and cash-return records separately.
Negative Payment entered	Reverse the invalid entry and use the governed refund/reversal process.
Refund exceeds captured amount	Reject and recompute from original and prior-return evidence.
Provider refund submitted without finance record	Hold closure until Payment, allocations and downstream evidence are updated.
Original Payment deleted	Restore/preserve audit evidence and escalate the control breach.

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. Classify five scenarios as credit note, refund, reversal or chargeback.
2. Prove a partial refund without changing the original Payment amount.
3. Explain why historical return-layer correction is not an ordinary cashier action.

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.