Expense claims.

Before we open a screen, one thing to set straight, because YESS is deliberately modest here. An expense claim is not a multi-page expense report with a dozen line items and a mileage calculator. It is a single flat record: one title, one amount, one date, one receipt link, and a choice of how the staff member wants the money back. That is the whole shape of it — and for the most common reimbursement a school ever processes, that is all it needs to be.

The claims desk lives at /dashboard/expense-claims. It is separate from the school's outgoing expenses ledger (bills to suppliers, diesel, rent — covered in the finance handbook). Expenses are money the school decides to spend; claims are money a staff member already spent and wants back. The two meet at exactly one point — approving a claim on the finance route files an expense — and this book walks you right up to that seam and tells you honestly where the automation stops.

Money spent for the school, claimed back with a receipt and a signature — nothing more complicated than it has to be.

Any staff member can submit a claim — there is no special permission to file one; the platform simply needs to resolve who you are as a staff record. Open /dashboard/expense-claims, click New expense claim, and fill in a short form:

Submit, and the claim is created with status submitted — the queue every approver works from. YESS stamps the claimant from your own session (a trigger fills in the staff id and the creator, so a claim can never be filed in someone else's name), records the action in the finance audit log, and the claim appears at the top of your My claims tab.

A second tab, Approval inbox, appears only for staff who can approve — anyone holding finance_expenses.approve or finance_payroll.approve (a principal, an accountant, an HR manager, a school admin). Everyone else sees only their own claims. The inbox lists every submitted claim in the school, oldest first, each card showing the claimant's name and staff id alongside the title, amount, date, and chosen route.

Two buttons per claim: Approve and Reject. Both call a single database function, decide_expense_claim, which does the careful work server-side: it confirms the approver belongs to the claim's school, re-checks that they actually hold one of the two approve permissions (so the guard lives in the database, not just in the hidden UI), and refuses a claim that has already been decided. A reject stamps the claim rejected with the approver and a timestamp; an approve stamps it approved and, on the finance route, fires the ledger step in chapter three.

This is the chapter to read slowly, because the two routes behave very differently — and the difference is easy to over-promise.

The finance route

Approving a claim marked Finance reimbursement does real work. YESS ensures a "Staff Reimbursements" expense category exists for the school (creating it the first time), then files a row in the school's /dashboard/expenses ledger with the claim's amount, date, and description — and links that expense back to the claim. Critically, the expense is filed with status pending approval, not paid. It joins the ordinary expense queue, where the finance manager approves it like any other bill; only that approval posts the double-entry journal.

So the claim's own approval is the first of two gates. The finance manager still opens the expenses queue and approves the reimbursement expense before any cash movement or ledger entry happens. And one setup caveat: the auto-created "Staff Reimbursements" category ships without a chart-of-accounts code, so the very first time you use this route, link that category to a GL account at /dashboard/expenses/categories — otherwise the ledger posting is skipped even after the expense is approved. Do it once and every future reimbursement posts cleanly to /dashboard/accounting/journal.

The payroll route

Approving a claim marked Add to my next payslip records the decision and marks the claim approved — and, today, that is where it stops. The claim carries a payroll-run link in its schema, but no payroll code reads pending claims to fold them into a run yet. Treat the payroll route as an intent flag the approver honours by hand — add the amount to the staff member's next payslip in /dashboard/payroll yourself — not as an automatic payslip line. The full payroll integration is on the roadmap.

Visibility is enforced at the database row level, not by hiding a button. A claim is readable by three kinds of person and no one else:

• The claimant — a staff member always sees their own claims, and only their own, on the My claims tab.
• Finance and payroll viewers — anyone with finance_expenses.view or finance_payroll.view sees every claim in the school, which is what powers the approval inbox.
• Nobody across school lines — every policy is scoped to the school, so a claim never leaks to another tenant.

Editing follows the same discipline: a staff member can only touch their own claim while it is still a draft or submitted, and can only delete a draft. Once a claim is approved or rejected it is settled — the decision path runs through the secure function, which is the only way a claim's status ever changes.

The request-and-approve core is solid and wired. The edges — the payroll leg, the final "paid" state, richer claims — are honestly thin, and the tagline's promise of a reimbursement that "lands in the ledger" is a two-gate, one-time-setup story rather than a single click. Here is the straight picture.

Claims sit between the person who spent the money and the ledger that accounts for it. They lean on finance for the expense and the posting, and — on the roadmap — on payroll for the payslip line.