Finance transaction lifecycle

There is no single universal Finance status. Each object has its own lifecycle, and one economic event can be at different stages in billing, collections, accounting and reconciliation.

Audience: all controlled Finance roles
Learning time: 30 minutes

Learning outcomes

You will be able to:

• separate object status from control status;
• identify allowed and prohibited transitions;
• distinguish cancellation, refund and reversal;
• explain the evidence created at each stage;
• stop safely when state is uncertain.

Lifecycle layers

This is a cross-domain teaching model. The exact available stages depend on the object.

Stage 1 — Prepare

Preparation establishes:

• tenant and school context;
• prerequisites and configuration;
• exact permission;
• amount and currency;
• source records;
• supporting references;
• expected reviewer or approver.

The safest time to correct data is before submission or posting.

Stage 2 — Validate

Validation rejects structurally or logically invalid data.

Verified examples:

Object	Rule
School fee	amount must be positive; percentage fields are bounded; required scope and dates must be valid
Invoice	at least one line; subtotal equals line totals; total equals subtotal plus tax minus discount
Credit note	positive amount; remaining amount cannot become negative
Payment	positive amount; method-specific fields; allocations cannot exceed payment
Receipt	non-empty line items and invoice allocations; allocations cannot exceed receipt amount
Journal	different active non-header debit/credit accounts; positive amount

A validation failure means the requested state was not accepted. Correct the data; do not create a second record unless evidence proves the first was not created.

Stage 3 — Save or submit

A record can enter a draft, pending or immediately completed state depending on the object.

Examples:

• invoice approval can begin in draft or pending;
• a payment currently defaults to completed, unverified and unreconciled at creation;
• a journal defaults to posted unless draft is supplied;
• receipt settings default to a pending approval state;
• receipt templates begin as draft before publication.

Defaults are product behaviour, not policy approval

A default completed payment does not mean an independent reviewer checked it or the bank reconciled it.

Stage 4 — Approve or reject

Approval answers: did an authorised decision-maker accept this object or request?

Invoice approval model

The diagram expresses verified labels and available actions, but the exact entry route from draft to pending can depend on UI and setup. Rejection requires a comment in the invoice API.

Credit note approval model

Only approved credit notes can be applied, and only draft credit notes can be updated.

Stage 5 — Complete the operational effect

Operational completion changes the domain record.

Examples:

• invoice amount outstanding changes after allocation or approved credit application;
• payment carries completed/failed/refunded state;
• receipt issuance creates document links and number;
• bank match updates reconciliation evidence.

Completion in one object does not complete every related object.

Payment state model

This diagram uses the current payment status vocabulary. Exact provider transitions are provider-dependent.

Independent payment controls

Never compress these into one “payment status.”

Stage 6 — Post accounting

Posting creates or updates accounting evidence in the internal GL.

A journal can be:

Current manual journal rules:

• debit and credit accounts differ;
• both accounts exist, are active and are posting accounts;
• amount is positive;
• status can be draft or posted;
• reversal creates a new offsetting entry and marks the original reversed.

Do not edit posted history to make it look as though the original never happened.

Stage 7 — Verify and reconcile

Verification

Payment verification records an internal review with verifier and time. It asks whether the payment record satisfies the school’s verification control.

Reconciliation

Reconciliation asks whether internal Finance activity agrees with:

• bank statement activity;
• provider settlement;
• reconciliation batch evidence;
• subledger-to-GL controls;
• other supported control sources.

A payment can be verified but unreconciled, or reconciled under a separate process after verification.

Stage 8 — Report and certify

Reports summarise the current evidence set for a date or period. Certification records independent acceptance of an exact control state.

A report can be generated even when exceptions exist; the report’s balanced or readiness indicators must be interpreted, not assumed.

Correction actions compared

Action	Primary object	Economic meaning	Evidence principle
Edit	draft/editable object	correct data before control boundary	update history and actor
Reject	approval request/object	authorised decision not to accept	reason/comment and reviewer
Cancel	invoice, receipt or pending object	stop object according to its lifecycle	cancellation reason, actor and time
Credit note	invoice obligation	reduce amount owed	approved adjustment record
Refund	payment	return some or all money	refund amount, reason and reference
Reverse	journal or supported transaction	offset prior effect	append-only reversing record
Unmatch/reconcile exception	bank/provider relationship	correct external/internal relationship	preserve match and exception history
Archive	configuration or draft/historical object	remove from active use without erasing history	soft-delete timestamp

Safe-stop decision tree

Mupfure example

A PayNow attempt is pending after the guardian closes the browser.

Wrong response: immediately ask the guardian to pay again.

Safe response:

1. locate the existing payment attempt;
2. inspect provider reference and callback state;
3. check whether a payment was created;
4. check amount, currency, student and invoice;
5. wait or escalate according to provider evidence;
6. retry only after the earlier attempt is conclusively failed or cancelled.

Audit evidence by stage

Stage	Evidence
Prepare	selected school, source record, user context
Validate	accepted request or explicit error
Submit	object ID/number, creator and timestamp
Approve	status history, approver, time and comment
Complete	updated balances, links and status
Post	journal entry, source type/ID and status
Verify	verifier and verification timestamp
Reconcile	reconciler, batch/bank line and time
Correct	reason, actor, original and correcting record
Certify	exact reviewed state, independent certifier and timestamp

Practice scenarios

Scenario A

An invoice is approved, unpaid and not sent.

Correct explanation: approval is complete; settlement and communication are not.

Scenario B

A payment is completed and receipted but unreconciled.

Correct explanation: Makronexus recorded money and issued proof; bank/provider matching is still open.

Scenario C

A posted journal is wrong.

Correct response: use an authorised reversal; do not edit the posted entry.

Scenario D

A receipt is cancelled.

Correct explanation: the proof document is cancelled and unlinked; inspect the payment separately to determine whether monetary correction is required.

Verification checklist

Before declaring any Finance task complete:

• object status is expected;
• amount and currency are correct;
• related balances reconcile;
• required approval exists;
• payment verification is complete where required;
• journal evidence exists where posting applies;
• reconciliation is complete where external evidence applies;
• actor, time, reason and references are visible;
• no unresolved duplicate or exception remains.

Continue

• Accounting model
• Roles, permissions and segregation