Leave is where attendance software usually breaks down for Indian teams, and it is rarely because the software cannot do it. It is because the rules in most offices live in somebody’s head, and the moment you have to write them into four fields you discover they were never quite agreed.
Here is what those fields do, and which conversations to have before you fill them in.
Holiday, leave type, leave request
Three different things, confused on day one in almost every setup.
A holiday is a date the whole company is off. Pongal, Diwali, Independence Day. Nobody requests it, nobody’s balance is reduced, and it should not consume anyone’s leave. Put your festival list in here at the start of the year and it stops being a question.
A leave type is a bucket with rules attached — Casual Leave, Sick Leave, Annual Leave. Each one has its own allowance and its own behaviour.
A leave request is one person asking for days out of one bucket, which someone approves or does not.
The common first mistake is creating a festival as a leave type, which means everyone has to request the day off and everyone’s balance drops. It is quickly obvious and annoying to unpick, so it is worth getting right before anyone starts using the system.
The four settings that matter
Allowance days
How many days the bucket holds in a year. Straightforward, and the only thing to decide is whether it differs by role or tenure. If it does, that is a reason for separate leave types rather than a mental note.
Accrual
Does someone get the whole allowance on the first of the year, or does it build up month by month?
Monthly accrual is more common and it is the one that prevents the awkward case: someone joins in October, takes twelve days in November, and leaves in December. With accrual they had earned two days by then, and the system knew it. Without it, the full allowance was sitting in their balance from the moment their account was created.
Accrual rate is the second half of it — one and a half days a month is a common pattern and gives eighteen a year. Decide the rate and the type together; one without the other does not mean anything.
Carry-over, monthly and yearly
These two are separate settings and they answer different questions.
Monthly carry-over decides what happens to an accrued day that was not taken this month. Usually it should roll forward, because the alternative means someone who accrued a day and did not use it has simply lost it, which nobody intends.
Yearly carry-over is the one that causes real arguments. On the last day of the leave year, does a remaining balance roll into the next year, lapse entirely, or roll over up to a cap? All three are legitimate policies. What is not legitimate is nobody having decided, which is the state most companies are in until the week somebody asks.
Decide it, set it, and tell people the number. “You can carry up to five days” is a policy. Silence is a dispute waiting for March.
Notice periods
A minimum notice setting stops casual leave being requested at nine in the morning for the same day. It is useful, and it is also the setting most likely to be wrong for your actual business.
Sick leave cannot have a notice period, by definition. If your tool applies one setting across all leave types, you will need separate types to handle it, and that is a better answer than training everyone to work around a rule.
Filing leave for someone else
Somebody will be in hospital, or on a train with no signal, and someone else will have to file the leave for them. An owner, administrator or manager should be able to do that, and when they do it should not be blocked by the notice period — the point of the exception is that the normal rules did not apply.
What matters is that it is recorded as what it is: filed by one person on behalf of another, visible in the audit log. A leave request that silently appears under someone’s name with no indication of who created it is the kind of thing that becomes a problem exactly once, at the worst time.
The mistake that costs you records
Deleting a leave type is more dangerous than it looks.
If leave requests are tied to the type by a plain foreign key and the type is deleted, the requests can go with it. Somebody tidies up an unused leave type in June and a year of approved annual leave disappears, including the record of days people actually took.
The protection is to archive rather than delete — the type stops appearing in the dropdown for new requests, but every existing request keeps pointing at something real. If your tool offers a delete with no warning, test it on a throwaway type before you ever use it on a live one.
This is not hypothetical. It is the kind of thing that is discovered after the records are already gone, and a database backup from before the deletion is the only way back.
What to set up, in order
- Load the year’s holidays before anything else, so nobody requests Diwali.
- Create the leave types you actually use. Three is usually enough.
- For each one: allowance, accrual type, accrual rate, monthly carry-over, yearly carry-over.
- Set notice periods per type, and leave sick leave without one.
- Write the yearly carry-over rule in one sentence and send it to everyone.
That last step is the one people skip, and it is the one that prevents the March conversation.
