We generate every document from one engine so each inherits the school's branding, a verifiable QR code and access-controlled delivery automatically, which is what makes branded verifiable PDF generation hold at scale.
Documents carry real weight
It is tempting to treat document generation as a last-mile detail: pour some data into a template, produce a PDF, move on. But a school's documents carry real weight. A fee receipt is a financial record. A report card is shown to relatives and to the next school. A certificate may be produced years later to prove a claim.
These artefacts have to be correct, consistent, on-brand and, increasingly, verifiable. Scatter their generation across modules and you get five documents that look like they came from five different schools, and five separate places for a formatting bug to live.
One engine, every document
So receipts, report cards, examination and tabulation sheets, account statements and certificates all come out of a single document engine. Each module hands it the data and the kind of document to produce; the engine owns the layout, the school's branding, the numbering and the verification.
The benefit is cumulative. Add a new document type and it inherits branding and verification for free; fix a rendering issue once and every document across the platform benefits. Consistency stops being something people have to remember and becomes something the architecture provides.
Branded per tenant, on a neutral core
Every school presents its own identity on its documents, its logo, its colours, its name, and yet the codebase itself carries no school's branding at all. Branding is data, applied at render time through the templating layer. The very same engine produces a document that reads wholly as one school's, then wholly as another's, from one code path.
This is the same discipline that lets the whole platform be white-labelled: the core stays brand-neutral, and identity lives entirely in configuration. It is why a document looks bespoke to each school without a line of school-specific code behind it.
A document that can prove itself
A PDF is trivial to forge, unless it can be checked against its source. So every document the engine produces carries an embedded QR code that resolves back to the system of record. A receipt or a certificate can be confirmed as genuine rather than taken on faith by whoever is holding the printout.
Combined with per-type serial numbering, each document is both traceable within the school and verifiable from outside it. The paper stops being the source of truth and becomes a pointer to it. A printed document is a claim; a QR code that resolves to the system of record turns that claim into something anyone can check, whether a bank, an employer or the next school.
Delivered only to the right hands
Generating a document securely is only half the job; handing it over safely is the other half. These documents are not served from public links that anyone with the URL could open. They are delivered through authenticated proxy routes that check the requester's role and scope before a single byte is returned. A parent downloads their own child's report card; a staff member reaches only what their permissions allow. The same access model that governs the screens governs the documents behind them, so a report card is exactly as protected as the marks it is printed from.
Any one of these is easy for a single document. The engineering is in doing all of it for every document type, for every school, with each school's branding, verification and access rules applied automatically, and keeping it that way as the document types multiply. Solving it once, centrally, is what makes it hold. It is how a platform of fifteen-plus modules still speaks to families in one consistent, verifiable, on-brand voice, on every receipt, every report card and every certificate it issues.