Numbering, templates, and communications

Numbering and templates control how Finance documents are identified and presented. Communication settings control how invoices and receipts are delivered or described. These settings create operational and audit consequences and must be tested before live collections.

Audience: bursars, administrators, implementers, document owners, communications owners, and auditors
Learning time: 40 minutes
Navigation: Finance → Finance Controls → Finance Setup → Receipt Templates (finance/receipt-templates) and receipt settings
Boundary: country-specific tax numbering, electronic fiscalisation, signatures, and retention requirements require localisation approval.

Learning outcomes

You will be able to:

• distinguish receipt settings from receipt templates and issued receipts;
• configure numbering without creating duplicate sequences;
• publish and set a default template;
• configure branding, banking text, tax fields, and delivery defaults;
• identify exact settings/template permissions;
• test rendering and delivery without issuing production documents;
• preserve the version and template evidence used for an issued receipt.

Object model

Object	Purpose
Receipt/invoice settings	school singleton for numbering, branding, communications, default currency, integration options
Receipt template	named versioned document design
Default template	selected design used when no explicit template overrides it
Issued receipt	numbered proof linked to payment and invoice allocations
Delivery evidence	sent flag, date, method, recipient context
Rendered PDF	output generated from template and binding data

A template is not an issued receipt. Publishing a template does not generate a document.

Numbering controls

Receipt settings can include:

• next receipt number;
• prefix;
• number format;
• padding;
• invoice prefix/format;
• footer/watermark;
• default template ID.

Receipt numbering is scoped per school and incremented atomically during issuance to reduce duplicate sequences.

A format can use supported placeholders such as prefix, number/sequence, and year. Test the actual renderer rather than relying on a visual example alone.

Template lifecycle

Template status values are draft, published, and archived.

A template can contain:

• name/code/description;
• HTML body;
• style configuration;
• page configuration;
• binding schema;
• default and active flags;
• version and usage count;
• published/archived timestamps;
• metadata.

Supported rendering includes variable bindings and conditional/collection constructs through the report-template engine. Only use binding keys returned by the product.

When an issued receipt uses a default template, its metadata can retain template ID, code, and version. Later template edits must not erase which version produced the historic document.

School branding and delivery settings

Settings can include:

• logo and contact details;
• school address, phone, email, and website;
• bank and mobile-money presentation information;
• tax registration/rate and statutory fields;
• online-payment messaging;
• default currency and payment terms;
• invoice/receipt email defaults;
• reminder settings;
• digital-signature options;
• finance export options.

Treat every statutory and signature field as configuration support, not proof of legal compliance.

Prerequisites

Requirement	Why it matters
Approved document design	receipts are official evidence
School legal/contact details	rendered identity must be correct
Bank/payment instructions	avoid directing families to wrong accounts
Numbering decision	protects uniqueness and audit trail
Default currency	settings must match school design
Delivery channels	email/SMS/WhatsApp/portal availability varies
Privacy review	recipient data and template bindings can be sensitive
Localisation review	tax/fiscalisation/signature rules vary
Separate test payment	render test without live money

Roles and exact permissions

Action	Ability
Read/update receipt settings	financial_receipt_settings:read, financial_receipt_settings:update
List/read/create/update/delete templates	corresponding financial_receipt_template:* abilities
Set default/publish template	verify active template action ability in the current API/UI; navigation requires at least financial_receipt_template:list
Issue receipt	financial_receipt:create
List/read receipt	financial_receipt:list, financial_receipt:read
Duplicate/resend/cancel	financial_receipt:duplicate, financial_receipt:resend, financial_receipt:cancel

P2 should not grant receipt cancellation to a user who only configures templates.

Guided procedure: settings

1. Select the school.
2. open receipt/invoice settings;
3. enter approved prefix, format, padding, and starting sequence;
4. add school branding and contact details;
5. add bank/mobile instructions from approved sources;
6. set default currency and payment terms;
7. configure delivery/reminder defaults;
8. configure tax/signature/export fields only with approved policy;
9. save and review audit evidence.

Control: if migrating an existing sequence, reconcile the next number to the last legacy document and retain migration evidence.

Guided procedure: template

1. Open Receipt Templates.
2. create a draft with unique name/code;
3. build the body using supported bindings;
4. configure styles and page layout;
5. render with test data;
6. inspect long names, multiple lines, zero/large amounts, currencies, cancellation/duplicate labels, and page breaks;
7. complete accessibility and print review;
8. publish;
9. set the intended school default;
10. verify settings point to the published active template.

Test cases

Render at least:

• short and long student names;
• missing optional contact fields;
• one and many line items;
• decimal amounts and multiple currencies;
• duplicate watermark/label;
• cancelled receipt representation;
• printed and email layout;
• school logo unavailable;
• long payment reference;
• multi-page receipt.

Do not expose real family data in test screenshots.

Worked scenario: Mupfure Learning Academy

The school uses receipt format MLA-{year}-{number} with six-digit padding. The next sequence is reconciled from the legacy system. A receipt template includes school identity, payer/student details, payment reference, invoice allocations, bank contact details, and a non-statutory instructional footer.

The implementer renders test receipts in USD and the configured local currency, publishes version 1, sets it as default, and issues one sandbox receipt. The verification record captures receipt number, template ID/version, rendered PDF, actor, and delivery status.

Failure modes

Symptom	Likely cause	Evidence to inspect	Safe action	Escalate when
Duplicate/incorrect number	migration sequence or format error	settings, last legacy number, issued records	stop issuance and reconcile	duplicates have been issued
Default template not used	template not published/active or settings reference wrong	template/status/default ID	publish/select correct default	valid default still ignored
Blank fields in PDF	unsupported/misspelled binding	binding catalogue and template	use supported key	renderer omits valid key
Email not sent	delivery disabled, recipient missing, channel failure	receipt sent fields and notification evidence	correct data/retry through supported action	repeated provider failure
Historic receipt layout changes	current template used instead of stamped version	receipt metadata and template version	render from stamped evidence	historic reproduction cannot be achieved
Tax/signature content is wrong	unreviewed localisation settings	policy and rendered document	disable/correct before live use	documents already issued

Verification checklist

• Number format and sequence are approved.
• Legacy sequence reconciliation is retained.
• Branding/contact/bank details are correct.
• Default currency and terms are intentional.
• Template uses supported bindings.
• Test cases render correctly.
• Template is published, active, and default.
• Issued test receipt retains template ID/version.
• Delivery evidence is visible.
• Secrets and personal data are absent from screenshots.
• Localisation owner approved statutory/signature fields.

Practice and knowledge check

Guided practice: create and render a draft receipt template using fictional data.

Independent scenario: a school migrates from paper receipts ending at number 004829. Design the evidence needed before setting Makronexus next sequence.

1. What is the difference between settings and a template?
2. Why is numbering school-scoped?
3. Why must sequence migration be reconciled?
4. What proves which template produced an historic receipt?
5. Why does a tax field not prove compliance?
6. Which permission should not be granted just to edit templates?
7. What test protects against accidental personal-data exposure?

Answer guide: settings store defaults/numbering while templates define layout; schools own distinct sequences; duplicates/gaps must be controlled; stamped ID/code/version proves source; legal rules require localisation; cancellation is unrelated; use fictional/redacted test data.

Next lesson

Continue to Approval and posting controls.