The calendar is also the ledger

The situation

Every appointment at this practice carries money. There is the fee, sometimes a discount, a commission owed to the therapist who delivers the session, a commission owed to the location it happens at, and a line in the accounts.

Reception books all day, on behalf of therapists working across several locations, and the therapist is notified of each booking. Some patients pay per session and some are billed once a month for everything they attended. Every booking has to leave the operational record and the financial record saying the same thing.

The hard part: a booking is a financial event

Most booking systems can keep the calendar and the money apart. A hairdresser’s diary does not need to know what a cut costs, and the till does not need to know who was booked at ten. The two meet at the counter and go their separate ways.

This one cannot keep them apart. When reception creates an appointment, the system checks for a clash, prices the appointment and applies any discount, calculates the commission due to the location and to the therapist under the rules configured for each, writes the journal entries that financial reporting is built on, and sends the notifications. The receptionist makes one booking, and the calendar and the ledger both move. So the design question was never how to store an appointment. It was what has to be true of the books once an appointment exists, and again once it stops existing.

Five answers to that question shaped the system.

All of it, or none of it.

A booking that creates the appointment and then fails partway through the financial side leaves the books wrong in a way nobody notices until month end. The appointment is on the calendar, the therapist turns up, and a commission or a journal line is simply not there. So an appointment and its financial consequences are written together or not at all. A half-made booking is worse than a refused one, because a refusal is at least visible.

Rates change. History should not.

Commission rules are configuration, and the practice changes them. A commission has to reflect the rule that applied when the appointment happened, not the rule in force on the day it is settled. Commission here is calculated when the appointment is created, against the rules configured at that moment. It is the same class of problem as an invoice that has to keep the terms it was issued under after the price list moves.

Cancelling is not deleting.

Reversing an appointment has to undo the revenue, both commissions and the journal entries. Delete the appointment instead and the reason all of those existed goes with it. Totals change, last month’s report stops matching the one that was sent, and nobody can say why. So a cancellation is handled by credit note: a new document stating that the earlier charge no longer stands. The original and its correction both stay on the record, and the difference between them is the explanation.

Two billing rhythms over one set of appointments.

Patients billed per session are invoiced as they go. For patients billed monthly, a background worker gathers a month of appointments into a single invoice. The subtle part is that both rhythms read the same appointments. Each appointment has to be billed exactly once, whichever rhythm its patient is on, and a monthly invoice has to agree with the appointments, discounts and credit notes it summarises. Get that wrong and a session is billed twice, or not at all. The patient is usually the one who notices.

Commission is a payable, not a number on a report.

Commissions accrue appointment by appointment and are settled later. That gives each one a lifecycle of its own, and in between accruing and settling it is money the practice owes somebody. A figure on a report can only be recalculated. A payable can be settled, checked against what was actually paid, and asked about.

None of this is visible to the receptionist, and that is the point. They book an appointment, and the books move with it.

The second hard part: availability is more than one calendar

Money is half of a booking. The other half is whether it can happen at all. A session needs a therapist, a room and sometimes a piece of equipment, at one location, and all of them have to be free at once.

Checking the therapist’s diary is the obvious approach, and it is not enough. A free therapist in an occupied room is not a booking. Neither is a free room when the equipment the session needs is already in use. Each resource has its own diary, and a clash only shows when they are read together, for the same slot.

So the clash check covers every resource the booking names. Because a booking is written whole or not at all, a refused one leaves nothing behind: no charge, no commission, no journal entry to unwind.

A refusal should also say which resource said no. "Not available" sends the receptionist back to try slots one at a time with a patient waiting on the phone. "That room is taken at three" tells them what to change: the room, the time, or the location.

Our operations case study is the same family of problem in another shape: three modules competing for one workforce, rather than several resources lining up behind one booking. Read One workforce, three calendars.

What we built

One platform for reception, therapists and administrators, with the money underneath every screen.

Booking and calendars

Appointments for one or more patients, with a therapist, a service, a location and a room, and equipment managed as a resource of its own. Reception books on a therapist’s behalf and the therapist is notified. Each therapist sees their own calendar; administrators see every appointment at once.

Invoicing and payments

Per-session and monthly billing, discounts, a monthly background worker that consolidates and issues invoices, payments recorded by hand, and credit notes for cancellations.

Commissions and settlement

Commission rules configured for locations and for therapists, accrued per appointment and settled later, with journal entries for financial reporting.

Clinical records

Patient notes and prescriptions.

Access, reporting and support

Role-based access that hides whole sections of the interface from roles without permission. Financial and operational reporting. A help centre for raising issues, and documentation inside the system.

Running it, and handing it over

We built and deployed the platform in five months, and the infrastructure was part of the job. It went onto a bare EC2 instance that we set up from nothing, with delivery pipelines we wrote to take a change from a commit to production.

The practice later brought in a dedicated DevOps team, and we handed the platform over to them. We no longer run it.

We count that as a good result. Our service agreement writes the exit down as a term: the code and documentation for work you have paid for, your credentials returned, and our access revoked. This client took that exit, and we handed over cleanly. That is what no lock-in looks like when it is tested.

What this means if you are buying

If any of these describes your business, the problem on this page is probably yours too.

Your bookings and your money are the same event.

Every appointment, session or job carries a fee, a cost or a payout, and the books have to move when the calendar does.

You pay people for the work they deliver.

Commissions, revenue shares or per-session fees that accrue as the work happens and are settled later, under rules that change.

Cancellations and reschedules are daily events.

And each one has to leave the accounts correct as well as the calendar tidy.