← Help centre / Handbook · chapter 5 of 19

Money, invoices and payments

The part of the product with the least room for improvisation. Most of what follows is a rule rather than a preference.

Accounts — the money side: invoices, payments and what is owed.
Accounts — the money side: invoices, payments and what is owed.

The shape of it

appointment  →  draft invoice  →  issued invoice  →  payment
                (editable)        (final, numbered)

Raising an invoice

From the appointment's Billing tab, or from Accounts.

It starts as a draft

A draft has no number, is not in the books, and can be edited freely — add lines, change quantities, apply a discount, fix the wording.

Take the time here. This is the only stage where changing your mind is free.

Issuing it

Issue allocates the next number in the sequence and makes the invoice final. From that moment:

  • The lines cannot change.
  • The total cannot change.
  • The tax cannot change.

If it is wrong, you do not edit it — you raise a credit note against it. The credit note carries the negative, references the original, and both stand.

It is what makes a refund explicable a year later: "we credited this and refunded that", rather than a bare negative payment nobody can account for.

Void is different from a credit note. Voiding cancels an invoice that should never have existed, and it needs a reason. Use a credit note when the invoice was right and something changed; void when the invoice itself was a mistake.

Taking a payment

Against the invoice, recording how it was paid — cash, UPI, bank transfer or account credit.

The method matters more than it looks. At five o'clock somebody has to count the drawer and match the UPI and bank credits, and those are different jobs. Money in today on the dashboard splits by method for exactly that reason.

Part payments

Perfectly normal. An invoice moves to part paid and keeps its balance.

Refunds

A refund is money going back out. It is recorded as its own thing, with a reason, and reported separately.

Discounts

Take them from the practice's discount catalogue rather than as free text wherever you can. A catalogued discount can be reported on; a typed one cannot, and "what did concessions cost us last year" becomes unanswerable.

A discount can sit on a whole invoice or on one line.

Discounts marked as needing approval are recorded, not blocked. Nothing stops the front desk mid-payment.

Packs

Prepaid blocks of visits. Redemption happens when the visit is invoiced.

A visit covered by a pack cannot be left as a draft invoice — drafting it would mean the pack balance and the invoice disagree about whether the session has been used. The software refuses and tells you.

What to check, and when

Daily

  • Money in today matches the drawer and the terminal.
  • Nothing sitting in Not yet invoiced that should have been billed.

Monthly

  • Revenue against last month and the same month last year.

The invariants

The practice's books are checked by nine invariants that must always hold — issued invoices balance to their lines, payments never exceed what is owed, a credit note never exceeds the invoice it credits, and so on.

If you are technical, npm run db:check-ledger runs them and is safe against production. If you are not, know only this: if somebody tells you the software "won't let them" fix a number, the reason is almost always one of these, and the fix is a credit note rather than an edit.