Invoices

An invoice is the student-specific obligation created for a school, academic year, optional term, billing period and currency. It contains line items and totals, tracks approval and payment dimensions, and can carry communication, accounting and audit metadata.

Audience: bursars, billing clerks, credit controllers, approvers, accountants, auditors, and support analysts
Learning time: 45–55 minutes
Primary route: /finance/invoices

Learning outcomes

You will be able to:

• interpret invoice fields and totals;
• distinguish approval, payment, overdue, communication and cancellation evidence;
• perform controlled create, review, approve/reject and send workflows;
• explain bulk-operation controls;
• choose cancellation, archive or credit-note correction;
• verify downstream student balance effects.

Prerequisites

Requirement	Verification
Correct school/student/year	identifiers agree
At least one line item	description, quantity, unit and total are valid
Totals	subtotal = line totals; total = subtotal + tax − discount within tolerance
Currency	line and invoice currency are understood
Dates	billing period, invoice date and due date are valid
Open period/readiness	selected school permits billing
Guardian communication	recipients and channel are authorised
Access	exact abilities below
Approval separation	maker/reviewer policy is satisfied

Roles and exact permissions

• financial_invoice:create
• financial_invoice:list
• financial_invoice:read
• financial_invoice:update
• financial_invoice:delete
• financial_invoice:send
• financial_invoice:approve
• financial_invoice:reject
• financial_invoice:statistics
• financial_credit_note:list
• financial_credit_note:read
• financial_credit_note:apply
• financial_payment:create (collection handoff only; P4 owns procedure)

Key field reference

Field group	Exact meaning	Control
identity	student, school, year, term, invoice number	immutable/traceable after issue policy
period/dates	coverage, invoice date, due date	must match calendar and open period
line items	quantity × unit amount and classifications	at least one; full array on update
subtotal/tax/discount/total	economic obligation	arithmetic must reconcile
paid/outstanding/payment status	settlement summary	derived when omitted
approval status/history	authorisation	separate from payment
guardian/send fields	delivery evidence	channel/recipient policy
installment fields	invoice’s plan context	not a payment
cancellation/archive fields	lifecycle correction	preserves database/audit history
accounting fields	account/cost/revenue/funding references	posting remains configuration-dependent
tags/notes/metadata	operational context	do not store secrets or substitute for structured fields

State dimensions

Never collapse these into one “invoice status.”

Amount calculation

Guided procedure

1. Create or open invoice. Verify student, school, year, term and fee/billing-run references.
2. Review every line. Validate description, quantity, unit amount, total, currency, tax/discount, and accounting classifications.
3. Recalculate totals. The service checks subtotal and total within ±0.01. Do not “fix” a mismatch by entering an arbitrary total.
4. Review dates and guardian details.
5. Save draft/update. When changing line_items, submit the entire array.
6. Submit to authorised review under school policy.
7. Approve or reject. Rejection requires a comment; approval appends actor/time evidence.
8. Send. Choose method and recipients. Sending increments reminder count and stores sent date/method.
9. Monitor payment state and overdue fields. P4 controls collection.
10. Correct safely. Use credit note for reduction, cancellation for invalid obligation, archive for soft-retirement under policy.
11. Refresh student financial summary when aggregate evidence is stale.

Bulk operations

Bulk create/send/approve/reject can save time but amplify errors. Require a filtered selection, total/count review, common context, and post-operation exception list. Bulk rejection still requires a comment. Never bulk approve a mixed school, currency or period population without a review export.

Worked scenario

A billing run creates a USD 500 tuition invoice. Two line items—tuition USD 450 and technology USD 50—sum to the subtotal. No tax or discount applies, so total and outstanding are USD 500. The bursar approves and sends the invoice. A USD 200 payment later makes payment status partial and outstanding USD 300, while approval remains approved. A mistaken duplicate technology line is corrected with an authorised credit note; the original invoice remains traceable.

Accounting and balance effects

Invoice creation raises the operational obligation. Whether approval triggers posting depends on configured posting policy and mappings. The documentation does not assume one universal debit/credit mapping. Verify any journal through source type/ID, amount, currency and date.

Controls and audit evidence

Retain invoice ID/number, billing run ID, fee snapshot, full line set, total reconciliation, actor, approval history, send timeline, cancellation reason, credit references, and request IDs. Separate internal notes from guardian-facing content.

Failure modes

Symptom	Likely cause	Evidence	Safe action	Escalate when
422 subtotal mismatch	lines do not sum	line totals	correct lines and recompute	service and manual arithmetic disagree
Cannot edit	state/policy or permission	approval status and ability	use authorised correction	valid draft rejected
Reject blocked	missing comment	request body	provide meaningful reason	comment supplied but rejected
Send succeeds but guardian reports none	delivery/provider issue	sent fields and downstream log	verify recipient/channel; resend under policy	repeated delivery failure
Payment status wrong	paid/outstanding values stale	payments/allocations and invoice	refresh/recalculate	source and invoice disagree
Archive/cancel unexpected	wrong action selected	audit history	stop and review corrective path	irreversible downstream posting exists

Verification checklist

• Identity and calendar fields are correct.
• At least one valid line exists.
• Subtotal, tax, discount and total reconcile.
• Approval and payment state are reported separately.
• Rejection/cancellation reasons are meaningful.
• Send evidence includes recipient/channel/time.
• Bulk actions have count/total review.
• Corrections preserve original evidence.
• Student outstanding amount agrees after refresh.
• Posting, when expected, is independently verified.

Practice and knowledge check

Guided practice

Use a non-production test school and the Mupfure Learning Academy scenario. Record the selected school, academic year, term, currency, fee, operator, reviewer, and timestamps. Capture the before-state, action evidence, after-state, and any exception IDs. Do not mark the exercise complete from a success toast alone.

Knowledge check

1. What record proves the student obligation?
2. Which status dimension answers whether the invoice is authorised?
3. Which status dimension answers how much remains unpaid?
4. What evidence proves the selected student population was correct?
5. Which action requires a separate reviewer in your school policy?
6. What should be inspected before retrying a failed or partial operation?
7. Which later phase owns payment collection and receipt procedures?

Answer rubric: a complete answer names the exact Makronexus record, status, permission or evidence source. Role names alone are insufficient.

Next lesson

Continue to Credit notes and adjustments.