> ## Documentation Index
> Fetch the complete documentation index at: https://absentify.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Allowance rules for existing workspaces
> How absentify converted fixed yearly allowances to reusable allowance rules, which balances stayed untouched, and what HR admins should verify.
On 1 August 2026, absentify replaced fixed yearly allowance amounts with reusable **allowance rules**. If your workspace already existed before that date, absentify converted your data for you. This page explains what changed, what did not, and what is worth a quick look.
Workspaces created on or after 1 August 2026 start with allowance rules from day one and were never converted. If that is your workspace, you can skip this page and read [Allowances settings](/docs/en/roles/hr_admins/settings/allowances) instead.
***
## What happened
Until now, an allowance was a plain number. For every employee and every year, someone typed in how many days or hours that person was entitled to. Carry-over limits and expiry were configured once for the whole allowance type, and every exception had to be typed in by hand.
Allowances are now defined by **allowance rules**. A rule describes how much is granted, in which cycle, when the allowance year begins, and what happens to unused allowance. One rule can be assigned to many employees, and an employee is assigned exactly one rule per allowance type at any point in time.
absentify converted the existing data automatically. You did not have to do anything, no configuration was lost, and no one had to re-enter numbers.
***
## What did not change
This is the important part: **every balance stayed exactly as it was.**
The remaining balance of every employee is the same as before. Booked absences, approved leave requests, and the days already taken were not touched at all, and overtime balances were carried over. Your employees see the same numbers after the change as they did before.
Preserving the remaining balance is a guarantee rather than a side effect. absentify recalculated each allowance year from the new rule and compared the result against the balance stored before the change. Where the two differed, it wrote a dated correction for exactly the difference, so the remaining balance reproduces the previous value.
The conversion only added rules, rule assignments, and correction entries. It never wrote to leave requests or absences, and it stored a copy of the previous values before it started, so the original figures remain available.
Because the goal was to reproduce your previous balances, absentify did not apply any rule retroactively. If a balance was stored before a carry-over expiry deadline that has since passed, that balance is preserved as it stood rather than expired after the fact.
***
## What your data looks like now
Open **Settings** > **Users**, select an employee, and open the **Allowance** tab. Compared with before, you will notice the following.
* **Each allowance type shows the rule that applies.** The summary line names the **Current rule** with its **Valid from** date and either **Valid until** or **No end date**. Where an employee's entitlement changed over the years, absentify created several consecutive assignments instead of one, so each period keeps the amount it actually had.
* **The year table names the rule per year.** Each row is one allowance year, and the rule that applied is shown under the **Year** column. Hovering the allowance value breaks it down into the amount from the rule, manual adjustments, and any balance correction from the conversion.
* **Differences were preserved as dated corrections.** Where the previous yearly numbers could not be expressed by a single rule, absentify recorded the difference as an adjustment. You will find these under **History & adjustments** with reasons such as **Balance correction from migration (2026)** or **Prorated first year**, created by **Migration**.
* **Allowance types point at an organisation default rule.** In **Settings** > **Allowances**, the rule that new employees receive carries the **Organisation default** badge. absentify selected it automatically wherever one of your existing rules matched the allowance type's previous standard amount. Where no rule matched exactly, or where the current and next year had different standard amounts, the previous default keeps working until you pick a rule yourself.
* **Departments point at a rule where possible.** Under **Allowance rules for new employees**, a department's previous standard quota now selects the matching rule. Here too, a default that did not match an existing rule exactly keeps showing the previous number fields until you pick a rule.
Corrections in the history are expected. They are the mechanism that kept your balances identical, not a sign that something went wrong.
***
## What you should check
Ten minutes are enough for a meaningful review.
Open **Settings** > **Users** > **Edit** > **Allowance** for a few people whose entitlement you know by heart, ideally one long-standing employee, one who joined partway through a year, and one part-time employee. Compare **Remaining** with what you expected.
Check the **Current rule** and its **Valid from** date. If the rule does not match the employee's contract, assign a different one instead of correcting numbers by hand.
Confirm that the corrections you see are labeled as coming from **Migration**. If a balance looks wrong, the correction entry tells you exactly which amount was preserved and for which year.
Open **Settings** > **Departments** and review **Allowance rules for new employees**. This is what the next person joining will get, so it is the setting most worth correcting now. Anything still showing the previous number fields has no rule selected yet.
If you track overtime or any other allowance in hours, review those in the same way. They were converted with the same guarantee, but their amounts are easier to misread than day-based ones.
If an employee's entitlement genuinely changes from a certain date, assign a new rule with that date rather than editing past years. Past calculations stay intact and the new rule applies from the date you choose. For assigning, ending, or removing rules after the conversion, including what **Rule assigned** means in the history, see [Editing user allowances](/docs/en/roles/hr_admins/settings/users/edit/allowance).
***
## If you use the API or webhooks
This is a real behavior change, so read this section before your next integration run.
Internally, the allowance value now stores only the part granted by the rule, while manual corrections live as separate adjustment entries. The public API hides that split so your integrations keep working:
* The **`allowance`** field returned for a member is the **effective** allowance, meaning the amount granted by the rule plus all manual adjustments. It keeps the meaning it had before the change.
* The internal **`adjustments`** field is **not** part of the payload.
* `PUT /members/{id}/allowance/{allowance_type_id}/{year}` is **deprecated**, and in a converted workspace its `allowance` field is **ignored**. The request is accepted, but the value has no effect, so writing a value and reading it back returns the amount the rule grants, not what you sent. Before the conversion the calculation engine owned that value and overwrote it on the next recalculation, so a nightly sync that keeps sending it changes nothing, exactly as before. To change an entitlement, use `POST /members/{member_id}/adjustments` for a one-off correction or a rule for a recurring entitlement. `brought_forward`, `compensatory_time_off`, `set_as_default`, and `disabled` keep working. While a migration is running, or after a workspace was rolled back, the endpoint rejects the whole request with a conflict instead of applying part of it. If no rule assigns the member that allowance type for the requested year, or the year lies outside their employment period, it returns **404 Not Found**. That is a permanent condition, so do not retry it.
* **Webhook payloads follow the same semantics.** Where a payload carries a member's allowances, the reported `allowance` is the effective value and `adjustments` is stripped, exactly as in the REST API.
New endpoints cover the rule model directly. They all require an admin API key and are grouped under **Allowance Management**:
| Purpose | Endpoints |
| ---------------- | ------------------------------------------------------------------------------------------- |
| Rules | `GET`/`POST /allowance-types/{allowance_type_id}/rules`, `PATCH`/`DELETE /rules/{id}` |
| Rule assignments | `GET`/`POST /members/{member_id}/rule-assignments`, `PATCH`/`DELETE /rule-assignments/{id}` |
| Adjustments | `POST /members/{member_id}/adjustments`, `DELETE /adjustments/{id}` |
Amounts follow the allowance type's unit: days for day-based types and **minutes** for hour-based types. See the [API introduction](/docs/en/api-reference/introduction) for the full details.
The Excel export also gained information. The **Allowance** sheet now shows **Rule**, **Rule valid from**, and **Rule valid until**, and splits the entitlement into **Allowance (from rule)**, **Adjustments**, and **Effective allowance**. Two sheets were added: **Adjustments**, which lists every manual and migration correction with its reason, and **Rules**, which documents the rules configured in your workspace. Both are always present, even when they contain only a header row. See [Excel and calendar exports](/docs/en/roles/hr_admins/settings/export).
If a report of yours reads the allowance column expecting the old fixed number, check it against **Effective allowance** rather than **Allowance (from rule)**. Only the effective value matches what the employee sees and what the API reports.
***
## What you gain
The conversion was not only housekeeping. A few things are now possible that were not before.
Instead of typing a number per person per year, you define the entitlement once as a rule and assign it. Changing the rule updates everyone assigned to it.
Assign a new rule with the date it takes effect. absentify prorates the change automatically and leaves past calculations untouched, so a promotion or a contract change no longer means manual recalculation.
Under **Carry-over & expiry**, decide whether **Nothing**, **Everything**, or an amount **Up to a limit** carries over, and for how long carried-over allowance stays usable. absentify applies it at the end of each allowance year.
Besides **Yearly**, a rule can grant the allowance **Monthly** or **Bi-weekly**. You can also choose whether each period's amount is available **Immediately** or builds up **Gradually**.
Under **How is a partial year counted?**, pick **In monthly twelfths**, where whole months count 1/12 each and a started month counts by day, or **Day-exact**, where every calendar day counts. Some countries require the day-exact basis.
***
## Getting help
If a balance does not look right after the conversion, do not correct it by hand before you have looked at **History & adjustments**. The entries there usually explain the difference.
If anything is still unclear, contact our [support team](/docs/en/introduction#how-to-get-further-assistance) or write to [support@absentify.com](mailto:support@absentify.com). Mention the employee and the allowance year you are looking at, so we can check the same figures you see.