How Many Hands Touch One Payment?

Take ten payments you received last month and count the hands.

Not the money — the hands. Somebody worked out what that family owed. Somebody wrote to them. Somebody opened the bank statement, found the line, worked out whose it was and ticked something off a list. Somebody noticed one had not arrived and wrote again. Somebody produced a document.

Most activity businesses have never counted this, because no single step feels like work. Each one takes well under a minute. Multiply by three hundred families and a term that renews, though, and it becomes a job nobody applied for — usually done on a Monday, usually by the person who can least afford the morning.

It is worth knowing the size of the window this happens in. Xero publishes a quarterly read on how long small businesses wait to be paid, drawn from real invoices in real ledgers: in the June quarter of 2026, US small businesses waited an average of 29.3 days, with late invoices running 8.5 days past their terms. Late payment is usually discussed as a cash-flow problem, and it is one. It is also the window in which all of that touching happens. Every day an amount sits unpaid is another day it can be chased, questioned, mis-matched or forgotten.

This is about making the number of hands smaller. Not by working faster — by changing where the money arrives and what arrives with it.

What “least manual” actually means

Worth defining before promising it, because “automated payments” is a phrase that has been used to mean almost anything.

A touch is any moment a person has to decide something, type something, look something up, or chase someone. They come in three kinds, and they are not equally removable.

Deciding. What this family owes. Whether the late joiner pays pro rata. Whether to waive the sibling fee this once. This is mostly irreducible, and it is mostly the part you are actually paid for.

Moving. Carrying a number from one place to another. The amount from the booking into an email. The payment from the statement into a spreadsheet. The total from the spreadsheet into the accounts. This is almost entirely removable, and it is almost entirely where the time goes.

Checking. Did it arrive? Who was it from? Has this one been paid? Did we already chase them? Removable too — but only if something is watching on your behalf, which is the harder half.

So the least-manual process is not one with no humans in it. It is one where the deciding stays and the moving and the checking go. That is a useful target because you can tell whether you have hit it: pick a payment and ask what a person had to do that was not a decision.

Here is the shape that gets closest.

A booking takes a seat. The system holding that seat sends a payment instruction with a reference on it. The money arrives on whichever rail the family chose — a card or Direct Debit, where the gateway reports back, or a bank transfer, which is matched on the reference it carries. The booking is marked as paid. Only then is a document produced.

Nobody emails an invoice and waits to see whether it gets paid.

Five changes that remove most of the touches

None of these depend on any particular software. They are decisions about how money reaches you.

1. Put an identifier on the money before it moves. The largest single source of checking is money that arrives anonymous — a transfer carrying the payer’s name and an amount, and nothing else. Matching that is a judgement call every time, and judgement calls do not scale. A reference the payer cannot forget to include, carried on a QR code or a pay link rather than typed, turns matching from a judgement into a lookup. Almost everything else here depends on getting this one right.

2. Prefer rails that report back. Cards and Direct Debit confirm themselves — the gateway tells you what happened. Bank transfers confirm if you have a bank feed or a statement import. Cash never confirms; it exists only because somebody wrote it down. Every rail you offer that cannot report back is a permanent manual job you have agreed to do forever. That may still be worth it — just know you are choosing it.

3. Turn exceptions into rules before they happen. Part-payments, late joiners, families who go quiet, seats held for people who have not paid. Decided case by case, each is a touch and each is slightly different from the last. Decided once, written down as a rule with a grace period, they stop being decisions at all. This lever quietly removes the most work, because exceptions are a bigger share of the total than anyone expects.

4. Let documents come from the event, not the hand. If a person produces each invoice, every payment carries a document touch. If the document is produced by “payment received”, it carries none. This sounds like it inverts the natural order of things. It does not, and the next section is why.

5. Decide once where the truth lives. If two systems both believe they know who owes what, you have added a reconciliation job between your own tools — on top of the one you already have with the bank. Pick the system that knows about seats and terms, or pick the one that knows about ledgers. But pick.

Why the document can come last

In everyday speech an invoice is a request for payment. In tax law it is something narrower and later — a record that a supply took place, which is why it is normally issued after delivery rather than before it.

Three different documents do three different jobs:

Most arguments about “chasing invoices” are really arguments about asking one of these to do another one’s work.

That table is a simplification in one respect worth naming, because it is common in this sector. An invoice can legitimately come before delivery when money is taken up front: under the EU VAT Directive the chargeable event is normally the supply itself, but a payment on account makes VAT chargeable on receipt, and continuous supplies are tied to the end of each period they cover. A term billed up front, a year paid in one go, a monthly plan, an instalment schedule — each is properly invoiced on its own timing, and none of them is doing anything irregular. The point is narrower than “the invoice comes afterwards” — it is that issuing the document, whenever it is due, is not what makes the money arrive.

There is a second surprise underneath it. Under the EU VAT Directive, the invoicing obligation in Article 220 covers supplies made to another taxable person or to a non-taxable legal person — business to business, broadly speaking. For ordinary supplies to private individuals, Article 221 leaves it to each member state to impose an obligation or not. Whether a parent booking a term of swimming lessons is owed an invoice at all therefore depends on the country, and on what the bookkeeping needs.

That is general information rather than tax advice, and your accountant knows your jurisdiction. But it is worth asking, because plenty of class businesses run their entire cash collection through a document their customer never required.

The direction of travel points the same way. The EU’s VAT in the Digital Age package, adopted in March 2025, pushes invoicing towards structured electronic formats and digital reporting through 2030 and beyond. The invoice is being formalised as a reporting artefact — machine-readable, submitted, archived. It is not being turned into a better way to ask a parent for ninety euros.

What has to be true before a payment pairs

“Automatic matching” sounds like a single feature. It is closer to a sequence of refusals — a set of checks, each preventing a specific kind of wrong.

The receiving IBAN decides first — which company and billing profile this money belongs to, which matters the moment a network runs more than one legal entity. Then the transaction is checked against what has already been processed, so re-importing last month’s statement cannot post everything twice. Then the reference, the variable symbol across much of Europe, points at a booking — and that booking has to agree: it has to exist, be live rather than cancelled, and still be waiting for money. Finally the amount has to make sense, and a near-identical repeat within a day or two is better treated as a suspected duplicate than as a windfall.

Transfers reach a system through a bank feed, through the transaction emails banks already send, or through a statement import where neither is available. In Zooza the sequence above is documented in the payment pairing guide.

The part people underestimate is the queue at the end. Unresolved payments are not failures — they are the residue, and the goal of the whole chain is to make that residue small and named. Clearing eleven flagged transactions with the booking context attached is a different task from reading four hundred statement lines looking for the one that does not add up.

Where it actually breaks

Not at the first payment. At the second one, and at everything that is not a clean full-balance transfer.

Bank transfers break on the reference. A parent retypes the amount but not the reference, or pays from a different account, or pays two children’s fees in one lump. This is why a QR code on the confirmation earns its place — not as a convenience, but because a scanned code carries the reference a human retyping an IBAN will drop.

Cards break differently, and more quietly. The parent opens the pay link, reaches the 3-D Secure step, and abandons it. Nothing has failed — nothing has happened. The payment request sits open, the seat sits held, and no bank statement will ever show the absence. An off-session charge against a stored card declines for a reason the office never sees. A refund has to post as a counter-entry, or the term’s revenue quietly overstates itself.

Direct Debit breaks on time and on mandates. The collection is submitted days before it settles, so for most of a week the money is neither here nor there. Mandates expire, get cancelled by the payer, or were never completed — and a cancelled mandate is a payment that will never arrive, rather than one that is merely late. Each provider has its own retry behaviour, and the record has to reflect it.

Cash breaks on existence.

Four rails, four failure modes, one shared consequence: none of them are visible from inside an accounting package, because by the time anything reaches the accounts the interesting part has already resolved one way or the other.

What a paid invoice cannot do

This is the part that matters most, and it has nothing to do with accounting.

When a parent pays, five things should follow. The seat is confirmed. Any pending cancellation is called off. The reminder sequence stops. The debt report moves the family out of arrears. And a document is issued.

An accounting package can do the fifth. It has no way of knowing about the other four, because it has never heard of seats, terms, trials or make-ups. Mark an invoice paid there and the accounts are content — while in the business, nothing has moved.

The second one is where this gets expensive. A seat held for an unpaid registration is not an empty seat; it is a seat somebody else was turned away from. A rule that cancels unpaid registrations after a set number of days — with a grace window, and the cancellation revoked automatically if the family settles inside it — only works if the thing watching for the payment is also the thing holding the seat. Split those apart and the rule cannot exist, which is why the alternative is somebody cross-checking a registration list against a bank statement every Monday.

There is a sharper version of that point. The same held seat does not cost the same in week one of a term, when enquiries are arriving and somebody else would have taken it, as it does in week eight when nobody is asking — which makes a single company-wide payment deadline the wrong instrument in both directions. Your payment deadline is a capacity decision works that out, including how to get the numbers out of your own records.

Questions worth settling

Less a migration than a set of decisions. Most have been made implicitly already, which is usually why the Monday morning exists.

• What is the matching key? If the answer is “the parent’s surname in the payment note”, that is the first thing to fix.
• Who asks for the money? One system should own the instruction and the reminders. Two systems both sending payment requests is how families get chased for money they already paid.
• What happens on a part-payment? Decide it deliberately — leave the balance open and visible, rather than letting a partial amount quietly mark something settled.
• What happens to an unpaid seat, and when? A rule with a grace window is kinder than an inconsistent human one.
• Where do documents get issued, and by whose numbering? Pick one. Invoices generated in two places is a reconciliation problem of its own.
• Where does reporting live? Fine in either place. Just not in the place that also decides what is true.

Collecting money is not one job. It is a decision, a request, an arrival, a match, and a record — and only the first of those genuinely needs a person. The rest get cheaper the moment money arrives carrying something that identifies it, and lands somewhere that already knows what it was for.

Count your ten payments. The number you get is the one worth improving.

Going deeper: how Zooza wires this together walks the same path as an operator actually runs it — payment instructions, bank feeds, and invoices triggered by the payment rather than typed. If you are earlier in the decision, how to choose class management software is the broader version of the question, and the class payments feature page covers methods and plans.