Appearance
Individual invoicing
Billing the parent, or the adult learner themselves, for tuition, group membership and hire.
This is the run for activities whose payer is a person. Where the payer is a school or organisation the activity is invoiced by the organisation run instead — even when the charge itself is a direct one. See Invoicing for why those are different questions.
Everything here is decided by the service type, the academic year, and the state of the activity on the night the run goes looking.
Opening the year, and the term
Open Individual Invoicing on the academic year, and on each of its terms, is the switch. Invoices may be raised from that date onwards.
| Billing | Which date is read |
|---|---|
| Yearly service type | The date on the academic year |
| Termly service type | The date on that term |
There are two opening dates, not one
Open Individual Invoicing governs the billing run and everything that follows from it. Open Individual Application Invoicing governs charging at the point of application — the quote a parent is given, and the invoice raised when an offer is accepted.
They are set separately and can open at different times, which is deliberate: a service can start taking money from new applicants in the spring without opening the whole year's billing. It does mean you can be invoicing applications while the billing run is still shut.
An empty date means never, not now
Leave it blank and nothing is invoiced — not by the nightly run, not by Create Invoice, not on acceptance. Xperios refuses with "isn't open for individual invoicing yet".
If a billing run has apparently done nothing, this is the first thing to look at, and it is almost always the answer.
A term is also only considered for about seven months after it starts, so re-opening a long-past term will not make the run revisit it.
The nightly run
The run goes out once a day and looks at the academic years either side of the current one as well as this one, which is what lets it catch the last term of last year and the first of next.
For each year it raises the yearly invoices, then works through the terms raising termly ones for every term that is open and recent enough.
One invoice, or two
Everything found is sorted by payer and gathered into one invoice each. A payer with a pupil in tuition and an instrument on hire gets one invoice with two lines, not two invoices.
The exception is instalments: items that are offered instalments and items that are not cannot share an invoice, so a payer with both gets two. That is expected, and it is the only reason it happens.
What gets picked up
An activity is invoiced when all of this is true:
- Its status is Active, Modification Requested or Requested Cancellation
- It has not already been invoiced for that year or term
- It starts on or after the service type's Invoice From date
- For tuition, its plan year is Confirmed — a draft or pending plan is held back
- For a termly charge, the term has sessions on the schedule
Asking to cancel does not stop the invoice
A pupil whose cancellation or change request is still waiting for a decision is still invoiced. The request is a request; until somebody actions it the activity is live, and the run treats it as live.
If that produces an invoice you did not want, the answer is to deal with the request before the run, not after.
Why nothing was raised for somebody
In order of how often it turns out to be the reason:
- The year or term is not open — no date, or the date has not arrived.
- It has already been invoiced for that period. An invoice line is recorded against the activity for each term, and the run will not raise a second.
- The plan year is not Confirmed (tuition only).
- The term has no sessions on that schedule, so there is nothing to charge for.
- It starts before the service type's Invoice From date.
- The status is something other than the three above — a waiting-list place, an offer not yet accepted, or an application already cancelled.
Archiving a rate does not stop it billing
Archiving an activity rate takes it out of the lists people pick from — the catalogue, an application, a new activity. It does not stop the pupils already on it being invoiced, and it is not meant to.
That is deliberate: retiring a rate would otherwise cut off the invoicing of everybody already on it part-way through a year. If you want somebody to stop being charged, finish or withdraw the activity rather than archiving the rate.
A pupil who transferred part-way through
This is the one that surprises people, and the answer depends on how the activity is charged.
When a pupil moves from one activity to another, the record they moved off is usually not invoiced again — the new one carries the charge. But where the charge is per session or per hour, the old record is still invoiced, because it bills for the lessons actually taken before the move.
| Charged | What happens to the record they left |
|---|---|
| Per session or per hour | Still invoiced — for the lessons up to the move |
| Per term, per year, monthly or provision | Not invoiced again; the new record carries it |
So a pupil charged by the session or by the hour is charged on the record they left up to the day of the move, and on the record they moved to from the move to the end of the term — or to the next move, if there is another one. The two together come to the term, and neither charges for the other's lessons.
For a termly charge there is one more case: if the record they left had already started before this term began, it is invoiced for this term as well.
Group membership does not follow the same rule
A group membership transferred away is not invoiced again, whatever the charge basis — there is no per-session or per-hour exception as there is for tuition. A hire does not consider transfers at all.
So the same transfer, on the same day, can bill differently depending on whether it was a lesson, a group place or an instrument. If a transfer has produced a charge you did not expect — or has not produced one you did — this is where to look.
A transfer credits and re-invoices
Moving a pupil from one activity to another does three things to the ledger, in order:
- The old charge for the transfer term is credited — not the whole invoice, just what was charged for the activity they have left.
- The new activity is invoiced, and it is put on the same payment schedule as the invoice that was just credited.
- That schedule is recalculated once, so the instalments reflect both movements together.
Keeping the new charge on the old schedule is deliberate: a payer part-way through their instalments carries on with the plan they have rather than being started on a second one.
Moving somebody to a different day or time
Where the pupil is moving between two slots of the same activity at the same venue on the same rate — a different day or time and nothing else — and the period has already been invoiced, none of this happens. The invoice is left exactly as it is: nothing credited, nothing re-raised.
The transfer itself is ordinary — the old activity finishes on the date and the new one starts, so the lessons already taught stay on the slot they happened on and the registers for both read correctly. What changes is the money: the new activity is marked as already paid for for that period, so the billing run passes over it, rather than the old charge being credited and an identical one raised.
That is deliberate. Crediting one record and invoicing another for the same money tells the payer a story about their account that did not really happen.
What decides it is the fee, not the kind of charge. Xperios prices the activity as if it were already on the new slot and compares that with what was invoiced:
- The same — the transfer happens and the invoice stands.
- Different — the old charge is credited and the new one invoiced, because the payer really does owe a different amount.
A per-term or per-year charge is the same wherever it is taught, so those always stand. A per-session or per-hour charge is the same only when the new slot runs the same lessons over the period — which is the usual case when a school shuffles a lesson between two of its own times, and the reason this works for them too.
How much credit is offered
| The old activity was charged | What the credit starts at |
|---|---|
| Per session or per hour (tuition) | The part not taken — what was invoiced, less what the lessons up to the transfer actually come to |
| Anything else | The whole line |
Either way it is only a starting figure. Type over it and your number is used.
Why only session and hour
Those are the two that charge for what was taken, so there is a real part-period figure to work out — Xperios reprices the activity as though it finished on the transfer date and offers the difference.
A per-term or per-year charge has no such figure: whether somebody who leaves part-way through forfeits the term is a decision for your service, not a sum, so the whole line is offered and you decide.
It never arises on a group membership or a hire: those are only ever charged per term or per year, so there is no part-period figure to work out in the first place.
When the new activity is invoiced, and when it is not
The replacement is invoiced if either invoicing is open for the period or the activity they left had already been invoiced for it.
That second case is the one worth knowing. An application invoiced at the point of application can be credited on transfer at a time when the billing run is still shut — and raising the credit without its replacement would leave the payer holding a credit and nothing else. So the invoice goes out with it.
The transfer is saved before the ledger is settled
If the credit or the new invoice fails, the transfer still stands — it has already been saved. Xperios reports what it could not do rather than undoing the move, and you will see a message like "The pupil was transferred, but the old invoice could not be credited — credit it by hand."
Read those messages when they appear. The pupil is in the right place either way, but the money is not, and nothing will come back to it on its own.
Where the new invoice has something to pay, the payer gets the fees applied email for it, exactly as they would from the nightly run.
Withdrawing credits instead
Finishing somebody part-way through does the opposite: what they have been charged for the part they will not now take is credited back. The amount that can be credited is worked out from the invoice line, so a line already partly credited only offers what is left.
See Finishing and withdrawing.
Raising one yourself
Create Invoice, on an activity, raises its invoice now rather than waiting for tonight. It offers the year for a yearly charge, or the terms still to be invoiced for a termly one.
It is held to exactly the same rules as the run — the same opening dates, the same already-invoiced check, the same calculation — so it can tell you why it will not raise one. If Create Invoice refuses, the nightly run would have refused too, and the message is the reason.
Instalments and schedules
Where the rate offers instalments and your service has a payment provider set up, the invoice is put on a payment schedule at the same time it is raised, and the instalments are worked out for the payer as a whole rather than per line.
An invoice for an organisation that settles outside Xperios is receipted as it is raised, so it does not sit on the debtors list looking unpaid.
See Payment schedules.
The "fees applied" email
If your service has it switched on, every payer who ends the run owing money is emailed to say fees have been applied. There are two versions of the message — one for payers on a recurring card payment, one for everybody else — and Xperios picks the right one.
Only invoices with something to pay are emailed, and only to people. A payer with no email address is skipped rather than failed.
Invoices raised while the email was switched off
Send Fees Applied Emails For a Date Range, in System Manager, sends the emails for invoices already raised between two dates, whatever the setting said at the time. It will tell you what it would do before it does it.
See also
- How a fee is calculated — where the amount comes from
- Invoicing — the two runs, and what decides which
- Transfers — moving somebody between activities
- Debtors — what happens once the invoice exists