Payroll: paying staff from the hours they actually taught
A monthly wage run built on verified teaching hours, not on a figure typed in for the month.
Payroll turns teaching into money. For each month, Ekati adds up the hours that staff recorded in the execution logbooks and that were confirmed and verified, then pays against each person’s contract: an hourly rate for part-time teachers, a monthly salary for permanent staff, with verified hours counting as overtime on top when an hourly rate is set.
The screen has two halves that never touch each other by accident. Generate Payroll produces rows in Draft — a proposal you can still discuss. Mark as Paid turns one of them into Paid, and a paid row is final: it cannot be edited, only read. That separation is what makes the payroll record hold up in a dispute.
Run it once a month, and run it after the month’s logbooks have been verified — not before. Verified hours are the only hours that turn into pay.
Run a month of payroll in five steps
From verified hours to a marked-as-paid row.
-
Step 1
Check the month’s Execution Logbooks first
A teacher logs the session, the academic head confirms the teaching, HR verifies it. Only verified entries reach payroll, so an unverified week is an unpaid week.
-
Step 2
Open Finance > Payrolls and read the Period Summary
The cards at the top show Total Hours, Total Gross, Total Net, how many staff are Paid and how many are still Drafts for the month you have selected.
-
Step 3
Click Generate Payroll, choose Term and Month
In the dialog, pick the Term the month belongs to and the month in YYYY-MM form, then click Generate Payroll again to confirm.
-
Step 4
Read the new Draft rows
Each row shows Employee, Term, Month, Hours, Gross Pay, Net Pay and Status. Check the hours against the logbooks before anyone is paid — this is the moment to catch a missing verification.
-
Step 5
Mark as Paid as the money goes out
On each row, click Mark as Paid, type the payment Reference if you have one — the mobile money or bank transaction code — and confirm. The row becomes Paid and stays that way.
Only verified hours reach the payroll
The three-step journey every teaching hour makes before it becomes money.
Logged, confirmed, verified
A teacher records the session from their timetable — the date, the course, the hours. The academic head then confirms that the teaching happened as claimed, and HR verifies the entry. Payroll counts verified hours and nothing else, so an entry that is only logged never earns anybody anything. Confirmation is what separates teaching from a claim: the academic head knows whether the lesson happened, verification is what makes that statement countable, and a school that skips the middle step ends up paying for a timetable rather than for a classroom.
The contract decides who appears on the run
For staff paid by the hour, a payroll row only exists if there are verified hours in the period: no hours means no row, which is correct, because a vacataire who taught nothing is not owed a salary. Permanent staff are the opposite case — they appear for the period whether or not they taught, because their salary is contractual, and their verified hours still count on top of it as overtime whenever an hourly rate is defined on their record.
Generate, check, then mark as paid
The two-state rhythm that keeps the payroll honest.
Generating twice for the same month is safe
If you run the generation again for the same term and month, the existing rows are refreshed rather than duplicated — so a forgotten second click costs you nothing. Rows already marked Paid are never overwritten, which is the guarantee that a paid month stays paid.
Check the figures, then pay people individually
Read the Hours column first: it comes straight from the logbooks and is the one most likely to be wrong when a session was never logged. Then read Gross Pay and Net Pay together and compare the total with the period summary above the table. Once you are satisfied, mark rows paid one at a time, on the day each transfer leaves: that keeps the screen honest about where the month end really is, and an interruption never leaves you guessing which salaries have gone out.
A paid row is final. Once a row reads Paid it can be read and exported but not edited, and the payment reference you recorded stays on it. If a salary was paid twice by mistake outside the platform, the repair belongs to your own records — the payroll row is the evidence of what was approved, and it is left intact on purpose.
Reading the numbers on the payroll screen
Five figures, and what each one is telling you about the month.
Reading the five figures
Total Hours is the verified hours for the period you have selected, across all staff — the workload figure, where a sudden drop usually means missing logbook verifications rather than an unusually quiet month. Total Gross is the salary before anything is taken off and Total Net is what staff actually receive, so the school sees the cost of the month and each member sees their own figure on the same screen. Paid and Drafts are two counts, and the only ones that tell you where the month end is: a month with eighteen Drafts and two Paid is not finished, whatever the gross total says.
Filter the table by Month, Term or Status when a member of staff asks what they were paid, or when you are preparing one month’s paperwork for an audit. The same filters drive the summary cards, so a filtered view and its totals always agree.
The hours come from Execution Logbooks. Nothing on this screen is entered by hand except the mark that money has moved. If a figure looks wrong, the place to look is the execution logbook entry behind it — the staff member, the course, the term, the date and the hours — because that entry is the evidence the payroll was built from.
Payroll questions
Asked in the days around payday.
-
A teacher has no row in the payroll. Why?
Two reasons are normal. If they are paid by the hour, a row exists only when the period contains verified hours — check the execution logbooks for that month and verify what is still submitted or merely confirmed. If they are permanent staff, they should appear even with no hours: check that they are assigned to the term you generated.
-
Can I edit a payroll row after paying it?
No. A row marked Paid is final and is kept as the record of what was approved and paid, along with the reference you entered. That immutability is deliberate: a payroll that can be quietly rewritten is not evidence of anything. If an error is discovered afterwards, it is corrected in the following period and explained to the member of staff.
-
Do I have to run payroll for every month?
Run it for every month in which staff were paid, and pick the right term each time — the term matters, because it decides which verified hours are counted. Running it once for a whole term will not do: a term covers three months of teaching and each month has its own hours and its own salary.
-
I generated payroll before the logbooks were verified. What now?
Generate again for the same term and month. The rows are rebuilt from the verified hours that exist now, and nothing already marked Paid is touched. Because verification is the only source of hours, the refreshed rows are simply correct — and nobody has been paid twice.
-
What reference should I write when marking a row as paid?
The reference of the payment itself: the mobile money transaction code, the bank transfer reference, or the internal voucher number of your cash payment. It is optional on the screen but strongly worth filling in — it is what lets you prove, months later, that a specific transfer paid a specific salary.