The Sunday evening back.

How the matching works

Every payment request the club issues carries a short reference code — five unambiguous characters behind a GYM- prefix, with no letters a parent could confuse for digits. It appears on the invoice, in the emailed payment instruction and in the family portal, and the family puts it in the transfer message.

Your bank's deposit notifications are forwarded to an address belonging to your club. Gympillar reads each one, pulls out the amount, the sender and the reference, and then decides what it is looking at.

The ladder, in order

1. Reference found, amount matches a payment awaiting funds. Confirmed. The payment settles, the invoice updates, and nobody is asked anything. This is the only rung that resolves without a person.
2. Reference found, amount differs. A person, with the expected and received figures side by side. Over- and underpayments are both ordinary and they need opposite responses — one owes a refund, the other a balance.
3. No reference, but the amount and the sender's name both point at exactly one payment awaiting funds. A suggestion, pre-filled, that a person confirms with one click. Never an automatic match.
4. Anything else. The review queue, with the reason it could not be resolved written out — no pending payment for that amount, or three that share it, or an amount that could not be read at all.

Why nothing matches on amount alone

This is the rule the whole design is built around, and it is a safety mechanism rather than a threshold someone tuned.

On registration day, several families pay the same fee. Two $320 transfers arriving an hour apart are indistinguishable by amount, and a system willing to match on amount alone will confidently credit one family's payment to the other's invoice. Both look settled. The books balance. Nothing is flagged.

The club finds out weeks later, when a child is turned away from a class their parent actually paid for — and by then the club is arguing with a parent about a payment its own software told it had arrived. A row in a review queue costs ten seconds. That conversation costs a family.

So rung three requires the sender's name to corroborate the amount, requires exactly one candidate, and still only produces a suggestion. The name comparison is deliberately loose — "Nguyen" should corroborate "Nguyen Family" — precisely because a human is going to look at it either way.

A notification that cannot be trusted is not evidence

The address deposit notifications arrive at is reachable by anyone who learns it, and an email claiming to be from a bank is trivial to forge. So a notification whose original sender failed SPF or DKIM authentication never confirms anything automatically, however perfectly it matches. It goes to a person, saying exactly that.

Without that check, "your club has been paid" becomes a sentence a stranger can cause your software to believe.

When a bank changes its email template

Every email parser eventually breaks, because the sender redesigns something and tells nobody. Two decisions limit what that costs here.

First, reference detection does not parse any particular bank's "Message:" field. It scans the whole message for the GYM- code, which is distinctive enough to find wherever a template moves it. The most important extraction is therefore the one least exposed to a redesign.

Second, every notification is stored with its original body. When a format changes, the pattern is corrected against the messages that actually failed rather than against a guess, and the club's own history is re-readable. A rising number of unmatched deposits is the signal that something changed upstream, and it is visible rather than silent.

Worth being plain about: these patterns are written from the documented shape of Interac and Canadian bank notifications. They improve against real mail as real mail arrives, which is why raw bodies are kept from the first day rather than added after the first surprise.

What this deliberately does not do

Recurring collection cannot run on e-Transfer. There is no way to pull an Interac transfer — the payer initiates every one — so a club billing monthly this way gets automatic invoicing, not automatic collection. The invoice raises itself, emails itself, and then waits like any other.

If you want money to arrive each month without anyone doing anything, that is monthly card billing, and it is a different feature. We would rather say so here than have you find out in month two.

Reconciliation is also bookkeeping, not custody. Transfers land in your club's own bank account exactly as they always did. Gympillar never touches the money, and there is nothing to route, hold or release.

What a club needs to set it up

• A bank account that sends deposit notification emails — effectively all of them do.
• An address for those notifications to be forwarded to. A club that does not configure one simply does not use this; nothing else changes.
• Payment instructions that carry the reference code, which the invoice email already does.

Autodeposit is worth turning on if your bank offers it, for the ordinary reason that it removes the security-question step for every parent.