Salary and payroll

What you'll do

Record what each teacher is paid and on what basis, compute a month, check every line before any money moves, and post it — which creates the teacher payments and the matching expense entries in your cash book in one step.

Before you start

• Teachers on the system with the right Status — see Teachers and the teacher portal. Only active teachers are paid.
• For per-session teachers, sessions actually marked as held. See Taking attendance.
• Payments permissions throughout: read to see salary and payroll, create to post a run, delete to void one. Note the choice — salary is gated on Payments, not on Teacher Attendance, because somebody who marks the register is not automatically somebody who should see what colleagues earn.
• Money accounts and categories set up, so the expense entries land somewhere sensible. See Accounts and expenses.

Step 1 — Give each teacher a salary structure

Open a teacher and go to the Salary tab — A raise is a new structure, not an edit — the history is what lets a past month be paid at the rate that applied then.

That subtitle is the model. You do not edit a salary when somebody gets a raise; you close the old structure with an end date and start a new one. That way re-running March pays March's rate, not today's.

Press Add structure.

The Salary tab — a history of structures, with the current one tagged In forceScreenshot pending

An open-ended structure shows a green In force tag.

One structure at a time per teacher. Overlapping periods are refused with the fix spelled out: Each teacher can have only one salary structure in force at a time. Close the previous one with an end date, then start the new one the following day.

A structure that has been paid against cannot be deleted: This structure has already been paid against. Close it with an end date instead — payroll history must stay intact. Delete is only for a structure entered by mistake and never used.

Why teacher pay is pro-rated and student fees are not

An admin will notice this and it looks inconsistent, so here is the reasoning.

A monthly salary is split by the days each structure covers. If a teacher's pay rises on the 16th, the month pays fifteen days at the old rate and the rest at the new one. Without that split, a mid-month raise would pay two full months for one month of work.

A student's monthly fee is never prorated — a full month regardless of the join day (see Monthly fees and invoices).

They are different kinds of number. A fee is a price your centre sets, and a part-month first invoice invites an argument at the desk over the one bill a new family reads most closely. A salary is one month's pay split across whatever arrangements covered that month — there is only one month of work, and it must not be paid twice.

Step 2 — Preview the month

Go to Teachers → Payroll — Compute a month, review every line, then post. Posting creates teacher payments and matching expense entries.

1. Pick the Month.
2. Choose a Payment method.
3. Set a Payment date, or leave it — Leave empty for today. Sets the ledger date.
4. Add Notes if the run needs explaining.
5. Press Preview.

Preview — nothing has been posted yet: every line, with covered days, sessions and rateScreenshot pending

The block is headed Preview — nothing has been posted yet, which is exactly what it is. Columns are Teacher, Pay type, Covered period, Days, Sessions, Rate and Amount, with the days shown as of — which is where you see the proration in the open.

Read the warnings box before you go further. Headed thing(s) to check before posting, it names every teacher who was left out and why:

An excluded teacher is silent money. The warnings box is the only place it shows up, so read it every month. These sentences come from the server and are English in both languages.

If nothing computes at all: Nothing to pay this month — No teacher has a salary structure covering this month. Add one on the teacher's Salary tab.

Step 3 — Post it

Post payroll does the work. There is no confirmation dialog — the mandatory preview is the guard, along with the standing caption under the button: Posting creates real payments and expense entries. Correct by voiding, not editing.

Payroll runs — live and voided runs, with voided amounts struck throughScreenshot pending

You get Payroll posted — payment(s) created and posted to the ledger. Two things happened together: a teacher payment per line, and one expense entry per payment in your cash book. They cannot drift apart, and a retry cannot double-post.

A month can only have one live run. A second attempt is refused: This month has already been run — A live payroll run already covers this month. Void it below before posting again.

The Payroll runs table below shows Month, Teachers, Payments, Amount, Run at, Status and Actions, with a green Live or a red Voided tag.

Correcting a run: void, never edit

There is no edit and no delete on a posted payroll run. The only correction is Void.

The dialog says what that means: This is a reversal, not a deletion — The run and its payments stay on record, flagged as voided, and matching contra entries reverse them in the ledger. Once voided, the month can be run again.

• You get a summary: — payment(s) will be reversed.
• Reason is required — Why is this run being reversed? — under the note The reason is stored with your name and the time as part of the audit trail.
• Press Void run.

Afterwards: Run voided — The payments have been reversed. This month can be run again. The row stays, tagged Voided, its amount struck through, with your reason as the tooltip. The cash book gets contra entries; nothing is deleted there either.

So the whole correction workflow is: void the run, fix the salary structures, run the month again. Never hunt for an edit button.

Payout slips

Slips are printed from Teachers → Payments, not from the payroll page. Find the payment and use Print payout slip.

A voided payment has no slip. The button is disabled — A reversed payout has no slip to print. — and the row is muted with a Reversed tag and the line This payout was reversed: . It is excluded from all totals. This is deliberate: a slip is a document somebody may present, and a reversed payment must never produce one.

Reporting on it

Reports → Teacher Payroll — What each teacher was paid over a period, from payroll runs and ad-hoc payouts. Columns are Teacher, Payments, From runs, Ad-hoc, Sessions and Total paid, and the report is honest about what it left out: voided payment(s) are excluded from every figure above — their ledger entries were reversed.

See Reports.

Notes

• Ad-hoc payouts still exist. Payroll is for the monthly cycle; a one-off payment is still recorded on the teacher's payments screen and still posts to the cash book.
• A raise is a new structure, with the old one closed by an end date. That history is what lets a past month pay its own rate.
• Only active teachers are paid. Inactive, suspended and on-leave are excluded and named in the warnings.
• Monthly pay is pro-rated by covered days; student fees are not prorated at all. Deliberately opposite, for the reason above.
• Per-session pay counts sessions actually held, not sessions scheduled — see Teacher attendance.
• Posting has no confirmation dialog. The preview is the confirmation. Read it.
• Void, never edit or delete. Every correction records actor, timestamp and a mandatory reason, with contra entries in the ledger.
• Salary is gated on Payments permissions, not Teacher Attendance.
• Synthetic examples only. Any teacher name or amount here is invented.

Troubleshooting

A teacher is missing from the preview. Read the warnings box — it names every exclusion and why. The usual causes are no salary structure covering the month, or a status other than active.

A per-session teacher came out at zero. No sessions were marked held for them that month. Check attendance was actually taken before you conclude they did no work.

"This period overlaps an existing salary structure." One structure in force at a time. Close the previous one with an end date, then start the new one the following day.

I cannot delete a salary structure. It has been paid against. Close it with an end date instead; payroll history has to stay intact.

I need to re-run a month. Void the existing run with a reason, fix whatever was wrong, then preview and post again. There is no other way, and that is intentional.

I posted the wrong amount for one teacher. Void the whole run, fix that teacher's structure, and post again. There is no per-line edit.

The payout slip button is disabled. The payment was reversed. A voided payout has no slip by design.

My payroll expense is not in the cash book. It should be, posted with the run. Filter the cash book by Source = Teacher payout. If the run was voided you will find the contra entries beside the originals.

A voided run is still showing in the list. It always will. Voiding is a reversal, not a deletion — the row stays, struck through and tagged, with your reason on it.