Most billing tools were built around one customer per invoice. Martial arts schools bill families. The mismatch creates an entire genre of small, annoying problems that add up.
The shape of the mismatch
A typical family has one or two parents and one or three kids enrolled. The card on file belongs to the parent. The membership belongs to the kid. The classes are taught to the kid. The conversations about anything financial are with the parent. The school knows them as the Park family, not as four separate accounts.
Software built around one-customer-per-invoice handles all of this awkwardly. Two payment methods to update if a parent gets a new card (one per kid). Two invoices in the parent's inbox every month. Two cancellation conversations if the family leaves.
What family billing should do
1. One payment method per family
The parent has one card on file. It charges all the kids' tuition. If the card updates, it updates once. If the card fails, it fails for the family, not for each kid individually.
2. Sibling discounts automatic, not manual
Second kid 10% off, third kid 25% off, whatever your rule. Apply automatically when a second sibling enrolls. Remove automatically if one sibling cancels and the discount no longer applies. The discount math should not be a monthly spreadsheet check.
3. Family-level statements
The parent sees one statement per month, with line items per kid. Not three separate emails to read and reconcile.
4. Family-level conversation
When you call the Park family about anything (payment, schedule, belt test, retention), the system shows you context for all the kids. Not a single-record view that hides the other half of the family.
A school knows its families. The software should too.
The failure modes when you treat each kid separately
- Awkward upgrade conversations. "Your daughter's account is past due" hits differently than "your card didn't go through this month."
- Sibling discounts that get out of sync. One kid pays the discounted rate, the other accidentally doesn't.
- Two cancellation conversations. When a family leaves, you talk to them twice. Once is bad enough.
- At-risk signals split across accounts. Two kids who are both quietly losing interest don't add up to one obvious family-level retention risk.
Edge cases that matter
Separated parents
One household, two billing parents, sometimes alternating months. The system should support multiple payment methods per family with one designated as primary and a clear way to switch.
Grandparent payers
A third party pays for the grandkid's tuition. Different billing address than the family lives at. The system shouldn't require the grandparent to be the parent contact.
The adult learner in a kids-mostly school
One adult signed up themselves. They're their own family unit of one. The system should not insist on a separate guardian record.
If you're stuck on a per-account billing tool
Three workarounds in order of effort:
- Designate a "primary" student per family. All the billing goes to that record. Note the siblings in the comments. Awkward, but functional.
- Use the parent record as the billing entity if your tool supports it, even if it complicates the student-membership relationship.
- Build a parallel spreadsheet of families and the math. Reconcile monthly. Limited scaling, but immediate.
None of these is great. Family billing is one of the places where software shape actually matters, and it's worth checking when you evaluate any tool: does it know what a family is?