---
title: HR settings
order: 7
updated: 2026-07-12
---

# HR settings

*HR Settings* is the firm-wide control panel that every other part of the HR module reads from — attendance, leaves, holidays, expenses, salary, and travel reimbursement all take their rules from here. The page header reads *HR Settings* with the subtitle *Firm-wide configuration for attendance, leaves, holidays, expenses, and reimbursement rates.*

Everything on this page is **firm-wide**: a change applies to every employee the moment you save it. Nothing is scoped to a single user (except salary, which is per-employee by nature). Because these settings drive salary and attendance maths, the backend re-checks your permission and re-validates every value on save — a forged or out-of-range payload is rejected, so the numbers stay trustworthy.

## Before you start

- Every tab is gated by its own permission. A tab you cannot use simply does not appear, and if you hold none of the HR-settings permissions the screen may be missing from your sidebar entirely.
- The first tab you can see is the one that opens by default — the app picks the first *visible* tab, so different roles land on different tabs.
- Discuss changes with the team before editing mid-month. Working days, petrol rate, and salary revisions all feed live salary and attendance calculations.

## Open the screen

1. Open *Human Resources* in the sidebar.
2. Click *HR Settings*. The page opens with tabs across the top.

## The tabs

Each tab appears only if you hold the matching permission (a firm administrator sees all of them):

| Tab | Purpose | Permission needed |
|---|---|---|
| *General* | Attendance mode, working days, comp-off expiry, expense edit window, archived users | *Manage Attendance Settings* (`attendence.manageAttendanceSettings`) |
| *Leave Types* | The leave categories employees can apply for | *Leave Type CRUD* (`attendence.leaveTypeCrud`) |
| *Holidays* | Firm-wide and user-specific holidays | *Manage Holidays* (`attendence.manageHolidays`) |
| *Expense Categories* | The categories users pick when raising a voucher | *Expense Category CRUD* (`expense.expenseCategoryCrud`) |
| *Petrol Rate* | The per-kilometre rate for travel reimbursement | *Manage Petrol Rate* (`expense.managePetrolRate`) |
| *Salary Timeline* | Each employee's salary revisions and leave allowances | *View Salary Report* or *Manage Salary* (`attendence.viewSalaryReport` / `attendence.manageSalary`) |
| *Travel Location* | Whether travel must start from a fixed firm location | *Change Beginning/Ending Location* (`expense.changeBeginningAndEndingLocation`) |

## General

The *General* tab holds firm-wide attendance defaults in a *General Attendance Settings* card, plus an *Archived Users* row at the bottom. Edit the fields, then press *Save Settings* — nothing is applied until you save. The backend requires *Manage Attendance Settings* (or admin) to save.

### Manual attendance mode

A single checkbox, **off by default**.

- **Off (automatic)** — past working days are auto-filled as *Present* for everyone unless someone has already marked that day otherwise. This is the low-effort default: staff only need to record exceptions (leave, absence, half-day).
- **On (manual)** — auto-present is disabled; somebody must mark each employee for each day. The card description flips to *"Someone must mark each employee daily — auto-present is disabled."*

This flag governs how [Marking attendance](/docs/human-resources/marking-attendance) behaves for the whole firm.

### Working days

Seven day buttons (*Sun*–*Sat*). Tap a day to toggle it on (highlighted) or off. The default working week is **Monday–Friday**.

- A day left **off** counts as a weekend: it does not affect salary and is not expected in attendance, so nobody is marked absent for it.
- You must keep **at least one** working day selected — the *Save* button surfaces the error *"Select at least one working day"* and the backend rejects an empty list.
- The backend also rejects duplicate days and any value outside `0`–`6` (Sunday = `0` … Saturday = `6`).

### Compensatory leave expiry (days)

How many days after an employee *earns* a comp-off before it expires. Comp-offs are earned automatically when someone is marked present on an applicable holiday.

- Type a whole number of days, or leave it **blank for no expiry** (the default, shown as the placeholder *No expiry*).
- The backend accepts a positive whole number or `null`. A zero or negative value is rejected — clear the field instead if you want no expiry.

### Expense edit window (days)

How many days back an employee may submit or edit a travel entry or voucher.

- Type a whole number, or leave it **blank for no limit** (the default, placeholder *No restriction*).
- The backend accepts `0` or any positive whole number, or `null`. This is the guard that stops staff back-dating expense claims indefinitely — see [Logging expenses](/docs/human-resources/log-expense).

### Archived users

Below the settings card, *View Archived Users* opens the *Archived Users* modal. Soft-deleted (terminated) employees still have HR history — attendance, salary, expenses — and this modal decides whether that history stays visible.

Each row shows the person's name, username, role, and termination date, with a *Show in HR* switch. Turn the switch **on** to keep the archived user visible across the attendance, salary, expense, and other HR sections; turn it **off** to hide them from those lists. This only controls visibility — it never restores or re-activates the account.

## Leave Types

The *Leave Types* tab lists every leave category employees can apply for. Each card shows the code, name, whether it is *Paid* or *Unpaid*, an *Attachments* marker, and an *Inactive* flag when applicable. Per-user monthly allowances are **not** set here — they live inside each salary revision (see [Salary Timeline](#salary-timeline)). The backend requires *Leave Type CRUD* (or admin).

### Add or edit a leave type

Use *New Leave Type* (or the pencil on a card) to open the *Add Leave Type* / *Edit Leave Type* modal.

- **Name** — required, up to `50` characters. Example: `Casual Leave`.
- **Code** — required, up to `32` characters, and **must be unique** across the firm. The backend rejects a duplicate code with *"Leave type with code '…' already exists"* (or, on edit, *"Another leave type already uses this code"*). Keep it short — `CL`, `ML`, `COMP`.
- **Leave Compensation** — a radio pair, defaulting to *Paid Leave*:
  - *Paid Leave* — within the user's monthly allowance these days do **not** deduct salary; days beyond the allowance do.
  - *Unpaid Leave* — **every** day taken is deducted from salary regardless of any allowance.
- **Allow Attachments** — a checkbox, **off by default**. When on, employees can attach a medical certificate or similar when applying. See [Applying for leave](/docs/human-resources/applying-leave).
- **Active** *(edit only)* — a checkbox. An inactive leave type cannot be picked in the *Apply for Leave* form, but its history is preserved. New types are created active.

The new or edited type is available the next time someone opens the leave form.

### Deleting a leave type

The trash icon asks *"Delete this leave type?"*. Deletion is **blocked** (HTTP 409) if the type is referenced by any historical leave application or by any salary revision that allocated it — the app shows a *where-used* breakdown listing the offending records. If you no longer want a type offered, open its edit modal and untick *Active* instead of deleting.

## Holidays

The *Holidays* tab manages firm holidays. A year selector (spanning the current year minus three to plus two) filters the list, which is split into *Upcoming* and *Past* groups. Each card shows the date, reason, and — for user-specific holidays — how many users it applies to. Employees marked present on an applicable holiday automatically earn a comp-off. The backend requires *Manage Holidays* (or admin).

### Add or edit a holiday

*Add Holiday* (or the pencil) opens the *Add Holiday* / *Edit Holiday* modal.

- **Date** — required. Pick from the calendar.
- **Occasion (optional)** — a short label, up to `100` characters. Example: `Festival`.
- **Reason** — required, up to `200` characters. This is the name shown on every calendar. Example: `Diwali`.
- **Applies to** — two cards:
  - *Everyone* — a firm-wide holiday for all employees. **Default.**
  - *Specific Users* — only the employees you tick. When chosen, an employee checklist appears and you must select **at least one** user (the *Save* button stays disabled otherwise, and the backend rejects an empty list). The backend also verifies every selected user actually exists in the firm.

The holiday appears on every applicable user's calendar immediately.

### Deleting a holiday

The trash icon warns *"Delete this holiday?"* and reminds you that available comp-offs earned on that day will also be removed. What actually happens depends on how those comp-offs were used:

- If any comp-off credit earned on that day has **already been redeemed** as leave, deletion is **hard-blocked** — unwinding it would orphan an approved leave.
- If there are only **unused** comp-off credits, the app asks you to confirm; on confirmation the holiday and those unused credits are deleted together in one atomic step.
- If no comp-offs were earned, the holiday is simply deleted.

## Expense Categories

The *Expense Categories* tab lists the categories employees choose from when raising a voucher (Food, Lodging, and so on). Each card states the receipt rule and an *Inactive* flag when applicable. The backend requires *Expense Category CRUD* (or admin).

### Add or edit a category

*New Category* (or the pencil) opens the *Add Expense Category* / *Edit Category* modal.

- **Name** — required, up to `50` characters, and **must be unique** across the firm. A duplicate is rejected with *"Expense category '…' already exists"*.
- **Require Receipt** — a checkbox, **off by default**. When off, this category never needs a receipt.
- **No receipt needed below (₹)** — appears only when *Require Receipt* is on. Vouchers **below** this amount skip the receipt; at or above it, a receipt is mandatory. The value must be `0` or greater. **Leave it blank to always require a receipt** regardless of amount.
- **Active** *(edit only)* — a checkbox. Inactive categories cannot be selected for new vouchers but stay attached to existing ones.

### Deleting a category

The trash icon asks *"Delete this category?"*. If existing vouchers reference the category, the app offers a **Deactivate instead** action (which simply unticks *Active*) rather than forcing a destructive delete. A category with no references is deleted outright.

## Petrol Rate

The *Petrol Rate* tab sets the per-kilometre rate used to reimburse *Own Vehicle* travel — reimbursement is `rate × kilometres`. The top card shows the *Current Petrol Rate* (the most recent revision whose effective date has arrived) and, once more than one revision exists, a *Rate History* card charting each change with its delta. The backend requires *Manage Petrol Rate* (or admin).

### Add a rate revision

*Add Revision* opens the *Add Petrol Rate Revision* modal. You never overwrite a rate — you add a dated revision, and the app always uses the latest one that is in effect.

- **Rate per kilometre (₹)** — required, and must be **greater than 0**. Example: `12.00`.
- **Effective From** — required. The date this rate starts applying. A future date lets you schedule a rate change in advance; it becomes the *current* rate only once that date arrives.
- **Reason (optional)** — free text, e.g. `Fuel price hike`. Shown in the history list next to who made the change.

Rates are **frozen onto each travel entry at submission time**. Editing or adding a rate here never changes reimbursements that were already calculated — a travel claim keeps whatever rate was current when it was filed. Travel logged on or after a new rate's effective date uses the new value. See [Logging expenses](/docs/human-resources/log-expense).

## Salary Timeline

The *Salary Timeline* tab holds each employee's pay history as a list of dated revisions. Unlike the other tabs this one is **per-employee**:

- With *Manage Salary* or *View Salary Report* **and** at least one subordinate, an *Employees* sidebar lets you search and pick whose timeline to view (your own row is marked *(me)*).
- Without those, you see only your own timeline.
- The *Add Revision* / edit controls appear only with *Manage Salary* (or admin). *View Salary Report* alone is read-only.

Each revision card shows the effective date, monthly salary (with the change vs. the previous revision), the reason, the disbursement day, who made the change, and the per-leave-type monthly allowances.

### Add or edit a revision

*Add Revision* opens the *Add Salary Revision* modal (editing opens *Edit Salary Revision*).

- **Monthly Salary (₹)** — required, `0` or greater. A live hint shows the approximate annual figure. On **edit** this field is **locked** behind a risk acknowledgement (see below).
- **Disbursement Day** — the day of the month salary is paid. Range `1`–`28` (28 is the ceiling so every month has that day); **defaults to `7`**.
- **Effective Month** / **Effective Year** — when this revision takes effect. The revision applies from the first of that month onward. The year picker spans the current year ±2, but the backend accepts `2000`–`3000`.
- **Reason** — one of `Joining` (default), `Annual Hike`, `Promotion`, `Correction`, `Termination`, `Other`.
- **Leave Allowances (per month)** — one row per leave type. Tick a **paid** leave type and set how many days per month the employee may take without a salary deduction (whole number, `0` or more). **Unpaid leave types are disabled here** — they always deduct salary, so a monthly quota is meaningless; the app tooltips this and the backend ignores non-paid allocations. If no leave types exist yet, add them under [Leave Types](#leave-types) first.
- **Note (optional)** — free-text context for the revision.

The backend re-checks that every allocated leave type exists in the firm and rejects duplicate leave-type rows.

### Editing is retroactive — handle with care

Salary figures feed downstream reports, ledgers, and paycheck maths. Editing an existing revision (or setting an effective month in the **past**) triggers a warning: *"Changing a revision rewrites every salary report, ledger row, and paycheck calculation derived from it — from its effective date onwards."* Every report from that month forward is recalculated automatically, and figures already shown to the employee may shift.

On the edit modal the **Monthly Salary field is locked** with a padlock. Clicking it opens a *Change the salary amount?* dialog that requires you to tick an explicit acknowledgement (*"I understand the risk and want to rewrite past calculations"*) before the field unlocks. Prefer adding a fresh corrective revision unless you are genuinely fixing a past mistake.

## Travel Location

The *Travel Start Location* tab decides where employees begin a travel claim. The backend requires *Change Beginning/Ending Location* (or admin) to save. Choose a mode, then press *Save*.

- **Manual** — **default.** Each employee types their own starting point on the travel log form.
- **Fixed Location** — every employee must begin from one firm-set location. Choosing this reveals a required *Fixed start location name* field (up to `200` characters, e.g. `Head Office`, `Factory`, `Warehouse`).

When *Fixed* is selected the location name is **required** — saving is blocked (client and server) if it is empty. That exact name is pre-filled and **locked** as the first stop on every employee's travel form, and the backend **rejects any travel submission whose first stop differs** — so this cannot be bypassed by a forged request. See how it appears to staff in [Logging expenses](/docs/human-resources/log-expense).

## Common questions

### Where do I assign leave or expense approvers?

Not here. Approval routing follows the reporting structure (who reports to whom) together with each user's leave/expense approval permissions. See [Approvals](/docs/human-resources/approvals).

### Do changes affect existing records?

Mostly no. A new **leave type**, **expense category**, or **holiday** only affects things created after it. A new **petrol rate** applies only to travel logged on or after its effective date — past claims keep their frozen rate. The one deliberate exception is a **salary revision**: editing one, or dating one in the past, recalculates every downstream salary report from its effective date onward.

### Why is a working day I removed still counted somewhere?

Removing a day marks it as a weekend going forward — it stops affecting salary and attendance from the moment you save. It does not retroactively rewrite attendance already recorded for past dates.

### An employee earned a comp-off — where does that come from?

Comp-offs are granted automatically when someone is marked *Present* on a holiday that applies to them (a firm-wide holiday, or a *Specific Users* holiday that includes them). How long the credit lasts is set by *Compensatory leave expiry (days)* on the [General](#general) tab. Deleting the holiday removes any **unused** credits earned on it.

### Why can't I delete this leave type / category / holiday?

The app blocks deletes that would orphan real records. A leave type used by past applications or salary revisions, a category attached to existing vouchers, or a holiday whose comp-offs have already been redeemed cannot be deleted — deactivate it instead (leave types and categories) or leave the holiday in place. This is the same safety net across the module: nothing that would break historical data is silently removed.

### Why is the Salary tab visible but empty for an employee?

Either no salary revision has been added for that person yet, or you only have *View Salary Report* (read-only) access. Add the first revision with *Add Revision* if you hold *Manage Salary*.

### A terminated employee vanished from the HR lists — can I bring them back?

Their HR history is hidden, not deleted. Open [General](#general) → *View Archived Users* and turn on *Show in HR* for that person to make them visible again across attendance, salary, and expenses. It does not reactivate the account.

### Which settings are desktop-only or web-only?

None. *HR Settings* behaves identically in the web app and the Tauri desktop app — every tab, modal, and control is available in both.