When a parent pays for a package of ten lessons by bank transfer, the money part of your business is done in under a minute. The record part is where tutors get into trouble three weeks later, when someone asks whether the second payment arrived, whether the package was ten lessons or eight, and why the balance says five lessons left when the family insists on six.
The short answer: keep one payment record per package that captures five things — the amount, the date it arrived, which package it belongs to, a plain status label, and the current balance in lessons. That record is not accounting. It is the operational note that lets you answer questions in seconds and hand the real accounting to whoever does your books. If payment terms, taxes, or contracts become complex, a qualified accountant is the right next call, not a bigger spreadsheet.
This pattern fits tutors who take payments manually — bank transfer, cash, or a payment link — and track lessons in Bookedly or a notebook. It assumes nothing about your tax situation and deliberately stays on the admin side of the line.
What One Payment Record Needs
A payment record earns its keep the first time a question comes up. Five fields cover almost every question a student or parent will ask. The amount and date answer “did you get it?” The package name answers “what was it for?” The status label answers “where do we stand?” And the lesson balance answers “how much is left?”
Keep the labels boring: unpaid, pending, and paid. Resist invented states like “sort of paid” or “paid-ish”. If a payment is disputed or partially refunded, note it in words in the record’s notes area rather than inventing a fourth status that you will forget the meaning of in a month.
The Payment Status Card
The card below is the whole pattern. Copy it per package and keep it where you keep the student’s lesson records — in Bookedly’s student record, or as a row in your tracking sheet if you are still on spreadsheets.
| Field | What goes in it | Example |
|---|---|---|
| Amount | The number that arrived, in your currency, no rounding | €240 |
| Date received | The day the money landed, not the day it was sent | 2026-09-28 |
| Package | Name or code matching your package offer | 10-lesson package |
| Status | unpaid, pending, or paid | paid |
| Lesson balance | Lessons remaining on this package, updated after each lesson | 7 of 10 left |
| Notes | Anything unusual: partial refund, sibling sharing, payment plan | Split payment agreed, second half due 15 Oct |
Two habits make the card reliable. First, update the lesson balance immediately after each lesson, while the detail is fresh — the five-second update prevents the five-minute archaeology project later. Second, whenever the status changes to paid, say so to the student or parent in the same message where you confirm the next lesson, so the record and the communication never drift apart.
How The Record Behaves Over A Package’s Life
A payment record is not finished when it is created; it behaves differently in each phase of the package. In the first weeks the status field is the active one — money is arriving, sometimes in instalments, and the record answers arrival questions. In the middle phase the lesson balance is the active field, moving down after each lesson while the status stays quietly at paid. In the final phase, the record’s job is memory: the family asks whether there really were ten lessons, and the history answers.
This phase view tells you when to worry. A package mid-life with a stuck balance means lessons happened without updates — fix the habit, not the record. A package at end-of-life with no notes means the paper trail for disputes is thin — export or archive the record before you mentally close the file. And a package whose status has sat at pending for more than a week or two needs a plain conversation with the payer, not a silent resentment in your admin.
One row per package, three active phases, and an archive step at the end. That lifecycle view is what separates a record that works from a row that merely exists.
Boundaries That Keep This Simple
Payment records touch money, so three boundaries matter. Do not give tax advice to students or parents — your record shows what happened, not what is deductible. Do not promise outcomes about payment processor rules, chargeback windows, or bank disputes; those belong to the provider’s current terms — for example, Stripe documents how its dispute process works — and you can point families to the provider without summarising the rules yourself. And keep student payment data as private as any other student record: share balances with the payer, not with other students’ families.
Chargebacks and disputes are the one place where your record proves its value. If a payment is reversed months after lessons happened, the amount, date, and lesson-by-lesson consumption history is exactly the evidence a platform or bank will ask for. Keep the history even after a package is finished — closed packages are the ones that get questioned.
Where This Connects To The Rest Of Your Admin
Payment status feeds three other routines. The lesson package balance checklist uses the same balance number to decide when a package is running low. The booking request tracker for solo tutors keeps unpaid package requests from sitting in limbo. And the weekly schedule review routine is the natural slot to scan every pending status label once a week.
None of this needs new software on day one. It needs one honest record per package, updated right after each lesson, and a weekly glance at anything marked pending. That is the entire operating pattern.
