Extra hours & overtime.

Extra hours are where money quietly leaks. A school knows it paid its invigilators something at the end of exam week, but rarely who, for exactly how many hours, at what rate, approved by whom. The honorarium for a guest speaker gets paid from petty cash and never touches the books. The colleague who covered four periods is thanked verbally and forgotten by payroll.

YESS treats every extra hour as a first-class object with a paper trail: a slot describing the need, an assignment recording the person who filled it, a computed pay figure, an approval, and — for staff paid through payroll — a line on the payslip that traces back to the original slot. Nothing is paid that wasn't approved; nothing approved is forgotten at run time.

Every extra hour, priced by the school's own rules, carried straight into payroll.

It is the second Saturday of end-of-term exams at Greenwood International Academy. Follow this morning end to end and the rest of the book is detail.

Thursday, the day before. The exams officer needs three invigilators for Saturday's two sessions. She opens the extra-hours hub at /dashboard/extras-hours and clicks Post a slot: kind Invigilation, three seats required, Saturday 08:00–11:00, pay model Hourly at ₦1,500/hour, funding source Payroll, minor-facing toggle on. The slot is created with status Open. She invites two teachers and — because she is short one body — a vetted retired teacher already on the guest register.

Friday. The two teachers accept their invitations from their own portals; the guest accepts hers. The slot now shows 3 / 3 seats filled.

Saturday 07:55. Each invigilator checks in. The school's configured check-in method is Manual, so the officer taps Check-in on each row as they arrive. One teacher is ten minutes late but present; the third — the guest — does not appear. At 08:15 the officer marks her No-show. The guest's reliability score drops by the school's configured penalty.

Saturday 11:05. The two who worked check out. YESS computes each one's actual hours from the gap between check-in and check-out (≈3.0 hours) and the pay (3.0 × ₦1,500 = ₦4,500). The officer opens each row and clicks Approve. Approved hourly pay funded by payroll is now queued.

Month-end. The accountant runs payroll. On the run, one action attaches every queued extra-hours total to the right staff payslip — ₦4,500 appears on each invigilator's slip as an itemised extras line, added to gross and net. The two source assignments flip to paid, stamped with the run id, and can never be double-paid.

A slot is a posted need for extra cover. It lives in the extras_slots table and is created from /dashboard/extras-hours. Every slot carries a kind, a date and time window, a number of seats required, a pay model, a funding source, a location, and a minor-facing flag that drives the safeguarding rules later.

The hub lists slots grouped by date, each card showing the time window, kind badge, status pill, pay label and seats filled. Filter by kind, status, or date range. Creating a slot needs the extras_hours.create or extras_hours.manage permission; new slots are inserted directly as Open.

Pay models & funding

A slot's pay model is one of five: Hourly (rate × hours worked), Fixed honorarium (a flat amount regardless of hours), In-kind (a non-cash thank-you, described in text), Salary-inclusive (the person is already paid for this through their salary — recorded for the record, not for extra pay), and None. The system enforces a shape rule: an hourly slot must carry an hourly rate; a fixed slot must carry an honorarium amount.

The funding source says where the money comes from: Payroll, Petty cash, Event budget, Donor-funded, or School revenue. This is the single most important field for the payroll bridge — only slots funded by Payroll (and paid hourly or by honorarium) ever reach a payslip. The other funding sources are tracked here but settled through finance.

A slot is filled by an assignment — one row in extras_assignments per person invited. An assignment points at exactly one of three kinds of person: a member of staff, a registered guest (an outsider), or an alumnus. The slot detail page lists every invitee with their status, computed pay, check-in and check-out times, and pay status.

To invite, open a slot from the hub and use Invite — pick a staff member or a guest. Inviting needs the extras_hours.manage permission; inviting an outsider also needs extras_hours.invite_outsider. The invited person sees the invitation in their own portal and accepts or declines it themselves.

Every assignment moves through a fixed lifecycle, and every transition is a database function — not a free-text status field anyone can fudge. The states are: Invited → Accepted (or Declined) → Checked-in → Checked-out → Approved → Paid, with No-show and Disputed as side exits.

Accept / decline. The invited person responds from their portal; an admin can also record the response.

Check-in. When the person arrives they are checked in. The method is set per school — Manual (an admin taps the row), QR, Biometric, or Geofence. The check-in stamps a time and who verified it.

Check-out. At the end, check-out stamps the closing time. YESS computes actual hours as the gap between check-in and check-out, and computed pay from the slot's pay model — hours × hourly rate, or the fixed honorarium, or zero for in-kind and salary-inclusive slots.

Approve. Someone with extras_hours.approve_pay approves the checked-out assignment. Approval sets the pay status to Queued for cash-paying slots, or Waived for slots whose pay model is none, in-kind, or salary-inclusive. Queued is the moment the hour becomes payable.

No-show. If the person never arrives, an admin marks them No-show. For a registered guest this also dents their reliability score by the school's configured penalty — self-managed, not editable by hand.

Outsiders need two things the school controls: a rate, and a background-check status. Both live in their own surfaces.

Rate cards

Open /dashboard/extras-hours/rate-cards. A rate card is a reusable template — a named hourly rate and/or a fixed honorarium, in a currency, optionally scoped to certain slot kinds. Build "Guest lecturer — ₦25,000 honorarium" once and apply it to every guest lecture rather than typing the figure each time. Managing rate cards needs extras_hours.manage_rate_cards.

The guest register

Open /dashboard/extras-hours/guest-users. This is the register of non-staff people the school can call on — retired teachers, consultants, vendor individuals, parent volunteers, unverified alumni. Each guest carries a type, contact details, an optional default rate card, a national ID, and a background-check status: not required, pending, passed, failed, or expired.

The register also keeps a reliability score from 0 to 100, alongside counts of completed assignments and no-shows. These are auto-managed by the approve and no-show functions — a completion nudges the score up by the school's configured bonus, a no-show knocks it down by the penalty, capped at 0–100. The score is read-only by design: it is a record of behaviour, not a setting.

Open /dashboard/extras-hours/settings. One settings row per school governs how the whole module behaves — this is a tools-not-policy module, so almost every behaviour is a school decision. Four cards:

The extra-hours module above prices ad-hoc hours. There is a second, quieter half of this module that prices the school's ordinary teaching hours: the period hour-type catalogue at /dashboard/hour-types.

An hour-type is a category of teaching time with a payroll multiplier. YESS seeds seven on setup — theory ×1.00, tutorial ×0.90, preparation ×0.50, online ×1.00, practical ×1.25, lab ×1.40, fieldwork ×2.00. A teacher's base hourly rate is the "theory ×1.00" benchmark; a lab period priced at ×1.40 pays 40% more for that hour, for every teacher, automatically.

Each type carries a code (a stable lookup key the timetable solver and payroll engine read — locked after creation), a name, the multiplier, a default room type, a colour, and a display order. Seeded types cannot be deleted; schools add their own. The KPI strip shows total, active, and seeded counts. Managing types needs the period_hour_types permissions.

Two distinct pay feeds run from this module into payroll, and it is worth knowing which is which.

Feed A — extra-hours slots

When the accountant runs payroll, a preview lists every staff member with queued extras and the total owed; one action then attaches those totals to the matching payslips. Each affected payslip gains an extras total and an itemised breakdown — slot title, kind, date, hours, pay — added to gross and net salary. The source assignments flip from queued to paid, stamped with the payroll run id, so a second run can never pay them again.

Only assignments that are approved, queued, tied to a staff member, funded by payroll, and priced hourly or by honorarium make this crossing. Guest and alumni honoraria, petty-cash slots, and event-budget slots are deliberately excluded — they settle through finance.

Feed B — payable teaching hours

The ordinary timetable pays through a separate engine. The school chooses an hourly pay basis: logbook (pay the hours the teacher recorded teaching) or multi-factor presence (pay only the periods that were independently verified — an officer scan, a roll-call, a logbook entry, per the school's configured factors). Each payable period is priced through the hour-type multiplier from Chapter seven against the teacher's per-type rate. This is where a covered period or a substitution earns the substitute their hour — through the normal teaching-hours engine, not the extras slots.

The one place slots are created for you is exams. From an exam schedule, YESS can generate an invigilation slot per session in one call — kind Invigilation, seats and rate as specified, linked back to the originating session. Run it twice and it won't duplicate; the generator is idempotent. The exams officer then only has to invite people, not build the slots by hand.

This is the bridge between the examinations module and this one: the exam timetable becomes a set of staffed, priced, payable slots without re-typing a single date.

The features below are planned and not yet built. They appear here honestly so you can plan around them.

Term start. The school sets its rules once at /dashboard/extras-hours/settings — check-in method, reliability penalties, safeguarding gate — and reviews the hour-type multipliers at /dashboard/hour-types. The guest register is topped up with this term's vetted outsiders.

Through the term. Slots are posted as needs arise — a covered period here, a club session there, an open day. Staff accept invitations or self-opt-in; admins check people in and out; approvers clear the queue weekly.

Exam weeks. Invigilation slots are generated from the exam schedule, staffed, worked, and approved. The reliability register quietly records who showed up and who didn't.

Month-end / payroll. The accountant attaches queued extras to the run; staff see itemised extras lines on their payslips; assignments are stamped paid. Guest honoraria are settled through finance.

Term close. Filter the slot board by date range to read the term's whole extra-hours bill — by kind, by funding source, by person — for the next budget conversation.

Extra hours sit between the people who work them, the exams that create them, and the payroll that settles them.