A leave request arrives. HR sees a date range and a name. That is not enough to press approve: who else on the team is already out that week, how did this person's previous requests go, do the dates fall across public holidays? A leave approval system is an information question rather than a technical one - what does the person making the decision need to see on one screen? This article sets out that list in practical terms. Legal entitlement calculations are deliberately out of scope.
The context needed before approval
Approval looks like a single click, but four questions sit behind it:
- Is the team covered? How many people are already on leave for those dates?
- Does the roster allow it? In a shift team, which shift does this absence leave short?
- What do the dates coincide with? Holidays, a reporting period, a seasonal peak?
- What does the history say? How many days have been used this year?
When the answers live in four different places, approval takes longer - and more often, the questions are simply not asked. The consequence appears a week later: three people out on the same day.
Type and date range
Not all absences are the same, and the difference feeds directly into the approval decision.
| Type | Plannable? | Key question at approval |
|---|---|---|
| Annual leave | Yes | Cover and roster |
| Unpaid leave | Usually yes | Duration and frequency |
| Sickness | No | Documentation and length |
| Short time off | Partly | Cover on that day |
If the type is not visible, everything lands in one list and planning becomes impossible. The type therefore belongs in the first field of the request, not in a comment added later.
Pending, approved, rejected - why status matters
The most overlooked detail is this: a pending request is data too.
The typical sequence: two people request the same week, one is approved, the second is left in a "we'll look at it later" state. When the schedule is drawn up, the second request is not considered, because it does not appear on any list.
Keeping the three statuses separately serves three different purposes:
- Pending - for planning: there is a risk on these dates.
- Approved - for roster and timesheet: these days are already committed.
- Rejected - for history: who declined what, when and why.
The last is the layer most often neglected and the one most needed the moment a disagreement arises.
Filtering by person and by date
Leave data is read from two directions, and both are necessary.
The per-person view answers the individual question: how much has this person used this year, when were they out, which types were involved. It is usually needed before a conversation.
The per-date view answers the organisational question: who is away in July, which department is left thin. That one is needed while building the schedule.
In a spreadsheet the first view is easy and the second is painful, because each request is its own row and the date ranges overlap. In a system both are simply two cuts of the same data. We explain the general logic on the what is an employee attendance system page.
Reporting and exports
Leave data leaves the system in three situations: to finance, to the archive, and to an auditor.
The practical rule matches the one used elsewhere - Excel if it will be worked on, PDF if it will be read. What matters is the source: an export should be a copy, never the original. Otherwise three different leave lists for the same month start circulating.
We describe how such a report is structured on the attendance report page.
A practical example
In a 70-person marketing agency, leave requests arrived by email. HR copied them into a spreadsheet, agreed them verbally with the department head, and sent approval as a reply.
The process worked - until July. That month three of five people in one team went on leave in the same week. Nobody had made a mistake: the requests had arrived at different times, and no one had ever seen them side by side.
Once requests were collected in one place with their statuses, the situation did not repeat. The more useful outcome was different, though: for the first time HR could see the leave picture for the next three months and start building the schedule in time. We wrote about running schedules and attendance together on the managing schedules and attendance together page.
How to test your process
Three questions: where do requests arrive; where can pending requests be seen; can you say today who will be on leave in July?
If the answer to the third is "I would have to check", leave is still being managed from behind - built on reaction rather than planning.
Who holds the authority to approve
The detail that delays approvals most is not technical: when it is unclear who decides, the request simply waits.
The model that works has two levels. The first is the line manager - closest to the coverage question. The second is HR, checking balances and rule compliance.
A single level works in a small company; as the team grows, HR becomes the bottleneck for every request.
How a rejection should be delivered
This is the most sensitive and least considered part of the process.
A rejection needs two things: a reason and an alternative. Without a reason it feels arbitrary even when the decision is entirely sound.
An alternative keeps the process moving: "not those dates, but the end of that week works" continues the conversation where a bare no ends it.
Rejections are also worth recording - both for the history and to stop the same request returning unchanged.
Next step
Count this month's leave requests: how many appear on a single list, and how many are still sitting in an inbox?
QRGate keeps leave and time-off requests, with their statuses, inside the attendance context. See what QRGate can do or calculate the price.
