How Zooza Wires Up Payment Reconciliation

This is the companion piece to how many hands touch one payment, which covers the general principles — what counts as a manual touch, and the five changes that remove most of them. Those principles are not specific to any software.

This one is specific. It walks the same path as an operator actually runs it.

The shape of it

Everything below is one path, so here it is whole before the parts.

Underneath that path is one organising rule, which the next picture makes plainer.

The arrangement has one organising rule: the system that knows what the money is for holds the record, and everything around it is a specialist doing one job. Gateways move money. The accounting system produces compliant documents. The reporting layer reads. None of them decide what is true.

That matters because the operational facts — this seat, this term, this trial, this make-up credit, this grace period — exist in exactly one place, and no gateway or ledger has ever heard of them.

The instruction, and the reference on it

Payment starts from the booking rather than from a document. Zooza raises a payment request against the registration or order and generates the link the family actually uses, routed to whichever provider the operator has connected — Stripe, Global Payments, Besteron or a local bank gateway. For bank transfers the confirmation carries a pay-by-square QR code where that scheme applies, with the order number as the reference, so the parent scans instead of retyping an IBAN.

That reference is the whole trick. It is attached when the instruction is raised, which is the only moment at which the system reliably knows what this money will be for.

One practical note that accounts for most “the QR is missing” questions: it only renders when the billing profile holds a valid IBAN and a SWIFT code. Until the SWIFT is filled in, it stays hidden.

Watching the rails

Different rails report back differently, and Zooza listens to each in its own way.

Cards report through the provider — a redirect back after the payment, or a webhook when the charge succeeds. Because Zooza raised the request, it knows which booking the confirmation belongs to without anyone matching anything.

Direct Debit runs on mandates with their own lifecycle, through GoCardless for SEPA or FastPay for UK BACS. A collection is submitted days before it settles, so the record has to carry the difference between submitted and settled rather than treating them as one event.

Bank transfers arrive through one of three routes: a bank feed that syncs automatically, the transaction notification emails banks already send, or a CSV import of a statement where neither is available.

Cash is recorded by hand, because there is no alternative.

When it matches, and when it does not

An incoming transfer passes a sequence of checks before anything is marked paid: the receiving IBAN decides which company and billing profile the money belongs to, the transaction is checked against what has already been processed so a re-imported statement cannot double-post, the reference points at a booking, and that booking has to still be live and still be waiting for money. An amount that does not match an expected balance is held rather than guessed at, and a near-identical repeat within a day or two is treated as a suspected duplicate.

Everything that does not resolve cleanly lands in Sales & Payments → Payment reconciliation, with the transaction attached. That queue is the point of the design rather than a sign of failure: the goal is a short named list somebody clears in minutes, instead of a statement read line by line.

Alongside it, the Outstanding Payments report splits what is unpaid into three cohorts that answer different questions — awaiting payment (invoiced, not yet due — the cash-flow forecast), active debt (past due, still enrolled — the ones needing attention), and written off (already cancelled). The full matching sequence is documented in the payment pairing guide.

The document is triggered, not transcribed

This is the part that surprises people who expect the invoice to come first.

In the Xero integration, an invoice is created in Xero when a payment is recorded in Zooza, and Xero assigns the invoice number. Zooza decides when a document is raised and what is on it; Xero decides how it is numbered and stored. Each transaction — credit, bank transfer, Direct Debit, Stripe, refund — syncs back as its own line against the matching invoice. Nobody retypes anything, and the document follows the money instead of preceding it.

Transaction types carry their own accounting meaning on the way across. Course payments, registration fees, discounts and refunds map to different revenue accounts, configurable per billing profile or across the company. The categorisation happens once, at the moment the system actually knows what kind of money this is — rather than being inferred later by somebody looking at a bank line.

Several sets of books, one operation

A franchise network rarely has a single invoicing arrangement, and does not need one. Invoicing connects per billing profile, so territories can run different systems — Xero, SuperFaktura, Fakturoid, SmartBill, Szamlazz, Oblio, Abra Flexi — with spreadsheet and XML exports covering the accounting packages that have no live connector.

Each entity keeps its own books, its own receiving account, its own numbering. The operating picture across all of them stays in one place, because the ledger does.

Reporting then sits on top as a reader — inside Zooza, or pushed to Power BI where a finance team already works. It reads the ledger. It never becomes the ledger.

What it does not do

Worth stating plainly, because process design goes wrong on the gaps rather than the features.

The Xero integration does not sync contacts or clients, and it does not create bank accounts — you select an existing one. Credit notes have to be issued in Xero directly. Invoice PDFs live in Xero rather than being copied back into Zooza. And if you edit an invoice inside Xero, that change reaches Zooza only after a manual refresh, so Xero-side edits are not a two-way conversation.

Bank feeds are available for EU and UK banks; elsewhere, statement import is the route. Cash remains a manual entry, and no amount of design changes that.

The short version

The money is requested by the system that knows what it is for, it arrives carrying something that identifies it, it is matched on arrival rather than at month end, and the document is produced afterwards by whichever accounting system the business already uses.

The general version of this argument — including how to count the manual steps in your own process, whichever software you run — is in how many hands touch one payment. And for what an unpaid registration costs while it waits, your payment deadline is a capacity decision works that out from occupancy and trial numbers. For what is configurable, the class payments feature page covers methods and plans, and the integrations list shows what connects where.