A leave balance is not a number somebody types in. In Spyne it is the sum of an append-only ledger, so "why is it 6.25?" always has an answer — accrual by accrual, request by request, adjustment by adjustment.
30 days free · no card · your data exports whenever you want it

Stored balances drift. Somebody edits a request, somebody else adjusts a figure by hand, and six months later nobody can reconstruct how the number got there. The argument that follows is never about leave — it is about the spreadsheet.
Casual and sick leave accrue on a schedule you set. Each accrual is a ledger entry with a date, not an increment to a counter.
A request counts business days against your holiday calendar. Approving it writes the deduction to the ledger and marks the days on the attendance record.
Leave beyond the balance becomes loss of pay, and prorates the payslip automatically. Nobody calculates it twice.
Each request shows the balance it will draw against, the business days it actually consumes and the person's recent history — so the decision does not need a second screen.

Add your holidays once. Attendance stops counting them as absences, leave stops charging for them, and payroll stops treating them as unpaid.

The balance is derived from the ledger every time it is read. There is no stored counter to drift, and no way to change a balance without leaving an entry.
Leave accrues at 1.25 days a month, so fractions are unavoidable. Spyne stores days as integer hundredths — 1.25 is 125 — so nothing drifts the way a float does.
A request spanning a public holiday does not consume leave for it. The company calendar is one list that attendance, leave and payroll all read.
Requests reach whoever can approve them, and a request sitting unanswered for a few days is chased automatically rather than forgotten.

| Leave types | Casual, sick and unpaid (loss of pay) |
|---|---|
| Balance model | Derived from an append-only ledger, never stored |
| Precision | Integer hundredths of a day — 1.25 days is stored as 125 |
| Counting | Business days, against your own holiday calendar |
| Reports | By month and by employee, CSV export |
It is the sum of every entry in that person's ledger for that leave type and year: accruals, approved requests, adjustments and carry-over. Because it is summed on read rather than stored, it cannot disagree with its own history.
The balance goes negative and the excess becomes loss of pay in that month's payroll, prorating the payslip automatically. Nothing is blocked — the record simply stays honest.
Yes. Accrual runs on a schedule with the rate you set, and carry-over runs annually with your own cap. Both write ledger entries, so a change of policy is visible in the history rather than silently applied.
Yes, and it requires a note. The adjustment is a ledger entry like any other, attributed to the person who made it, so a balance can never change without a reason attached.
These are not separate products. What you record in one is what the next one reads.
Start a trial and generate a full sample company in one click — three months of attendance, payroll, invoices and projects, all joined up. Then delete it and start for real.