Odoo Holidays: Time Off, Balances, and Approvals for SMEs

What Is Odoo Holidays (the Time Off App)?

Odoo Holidays is the leave and absence module inside Odoo's HR suite. In the documentation it surfaces to users as the Time Off application, and internally it carries the hr.holidays lineage (now split into hr.leave for requests and hr.leave.allocation for grants).

The Time Off app is a centralized hub for all time-off-related information. It manages requests, balances, allocations, approvals, and reports. Employees request time off and see an overview of their requests and balances; managers allocate time off to individuals, teams, or the whole company, and approve requests.

On the operations side, the app gives managers and time off officers a color-coded quarterly Overview calendar — validated absences appear solid, requests awaiting approval appear striped — plus a Total bar graph showing how many people are projected out on any given day. Detailed reports break down how much and what kinds of time off are being used across the organization.

Because Odoo Holidays lives on the same Postgres database as Payroll, Attendances, Planning, and Calendar, approved time off automatically generates the Work Entries that Payroll consumes on the payslip — no re-keying, no separate spreadsheet.

Time Off Types: The Spine of the Module

Every absence in Odoo Holidays is categorized by a Time Off Type. The module ships with six preconfigured types — Paid Time Off, Sick Time Off, Unpaid, Compensatory Days, Extra Time Off, and Extra Hours — and you can add more under Time Off app > Configuration > Time Off Types.

Each type controls three things: how the request is made, how it is approved, and how it interacts with the rest of Odoo.

On duration, a type defines whether employees request a full Day, a Half Day, or Hours. On approval, four options are available: None Needed (auto-approved), By Time Off Officer (the default), By Employee's Approver, or By Employee's Approver and Time Off Officer. If a type requires no approval, the request is validated the moment the employee submits it.

On behavior, types carry a Count as setting (Worked Time vs Absence) that determines whether the absence counts toward accrual calculations, plus toggles like Require Supporting Document (common for sick leave or jury duty), Allow Negative Cap (letting employees go into a negative balance up to a set limit), Allow Request on Top, Deduct Extra Hours, and Ignore Public Holidays. A Payroll section maps the type to a Work Entry Type so that Payroll knows how to treat the absence on the payslip.

• →Six preconfigured types: Paid Time Off, Sick Time Off, Unpaid, Compensatory Days, Extra Time Off, Extra Hours.
• →Duration per type: Day, Half Day, or Hours.
• →Four approval options: None Needed, By Time Off Officer, By Employee's Approver, or By Employee's Approver and Time Off Officer.
• →Count as (Worked Time vs Absence) controls whether an absence reduces accrual.
• →Require Supporting Document, Allow Negative Cap, Ignore Public Holidays, Deduct Extra Hours, and a Payroll Work Entry Type mapping are all per-type settings.

Allocations and Accrual Plans

Allocations are amounts of time off given to employees. Odoo distinguishes two kinds: a Regular Allocation, granted immediately, and an Accrual Allocation, earned as the employee works. The latter requires an Accrual Plan.

Allocations are created at Time Off app > Management > Allocations and are visible only to Time Off Officer or Administrator access. To grant leave to many people at once, the Multiple Requests feature exposes a Mode field: By Employee, By Employee Tag (a saved group), By Department, By Company, or By All Employees. Employees who run out of balance can request additional allocations themselves.

Accrual Plans drive earned leave through Milestones. Each milestone determines when and how much time off an employee earns. A milestone can be reached either At allocation creation or After N days, months, or years from the start of the allocation — which is exactly how you encode seniority bands (for example, two weeks per year at hire, three weeks after three years, a full month after five).

Each milestone also carries a frequency — Hourly, Daily, Weekly, Twice a month, Monthly, Twice a year, Yearly, or Per Hour Worked — and you decide whether accrual is based on worked time (excluding time off taken) or whole calendar days, and whether the time is credited at the start or the end of the accrual period.

Carry-over and caps round out the plan. Carry-over can be Lost or Carried Over with a configurable cap (Unlimited, or Up to N days) and an optional carry-over expiry date. Two caps protect balances: a yearly cap that pauses accrual once a yearly maximum is hit until the next carry-over date, and a balance cap that puts the plan on hold once the running balance reaches a maximum.

Public Holidays and Mandatory Days

Odoo's Time Off app does not include any public holidays by default, because holidays vary by country, region, and even city. Public holidays are configured manually under Time Off app > Configuration > Public Holidays.

On a public holiday entry, a Work Entry Type field defines how work entries for that holiday appear when Payroll is in use, and the holiday can be scoped to specific working hours or employees or left to apply to all employees. Configuring public holidays is also reflected across other Odoo apps that use working schedules, including Calendar, Planning, and Manufacturing — so a correctly entered regional holiday propagates everywhere it matters.

The app also supports Mandatory Days (Time Off app > Configuration > Mandatory Days). A mandatory day is a date where the company or a specific department requires staff to be present, and on those days employees are simply unable to submit time off requests. It is the inverse of a public holiday: a public holiday says nobody works, a mandatory day says nobody is off. Mandatory days can be configured company-wide or department-specific.

How Time Off Connects to Payroll

Odoo's Payroll app calculates employees' worked time in conjunction with other Odoo apps — Employees, Time Off, Attendances, and Planning — and creates corresponding payslips. Work entries are generated from contracts based on information from Attendances, Planning, or Timesheets, and the time off types configured above feed those work entries in Payroll.

A subtle but important feature is Deferred Time Off. When time off is submitted after payslips have already been validated, Odoo defers that time off to the following pay period rather than cancelling and reprocessing the closed payslips. Those late submissions appear at Payroll app > Work Entries > Time Off to Report (default filter To Defer) and can be deferred individually or in bulk with Defer to Next Month or Report to Next Month.

For SMEs running both modules, this is the single biggest reason to keep time off inside Odoo rather than in a side tool: the data flows straight to the payslip with no manual reconciliation.

The Dynamics 365 Equivalent: Leave and Absence

The Microsoft Dynamics 365 equivalent of Odoo Holidays is the Leave and absence workspace in Dynamics 365 Human Resources. It provides a flexible framework for creating new leave plans, plus workflows for managing requests and an intuitive self-service page where employees request time off, with analytics to measure and monitor leave balances and usage.

Setup in D365 HR follows a heavier enterprise pattern: configure leave and absence parameters, create a working time calendar, create a leave request workflow, and configure the Absence manager role. Only then do you create leave and absence types, build leave plans, enroll workers, and run accruals.

Accrual processing in D365 can be run for multiple employees or an individual, as of today or a custom date, optionally for all companies or a single leave plan, with support for background processing, recurrence, and job alerts. Leave accrual rounding is prorated on enrollment and un-enrollment, and a Leave accrual transaction auditing feature records changes to a worker's leave type balance. D365 HR also supports buy and sell leave policies that can be configured to use workflow for approvals, with a dedicated Buy and sell leave request workflow type.

Conceptually the two platforms are parallel: D365 leave plans map to Odoo accrual plans, D365 leave and absence types map to Odoo time off types, and D365 request workflows map to Odoo's approval options. The difference is fit.

D365 HR leans enterprise — Dataverse-backed, workflow-heavy, tightly suited to large organizations with complex compliance and benefits programs. Odoo Holidays is leaner and favored by SMEs that want fast setup, native Payroll work entries, and a unified HR suite on one database. The right choice is situational and depends on organization size, existing stack, and localization needs — not on a universal verdict.

• →D365 HR Leave and absence = leave types + leave plans + accrual schedules + request workflows + self-service.
• →D365 setup order: parameters, working time calendar, request workflow, Absence manager role, then types, plans, enrollment, and accrual runs.
• →D365 accrual: batch-run, all-companies or single-plan, today or custom date, background + recurrence + alerts, prorated rounding, transaction auditing.
• →D365 has a native buy and sell leave policy with its own workflow type.
• →Odoo Holidays is typically faster to stand up for SMEs and integrates natively with Odoo Payroll work entries.

Implementation Considerations for SMEs

When you roll out Odoo Holidays, sequence the work the same way the module is documented. First, define your Time Off Types and their approval, duration, and Payroll-mapping settings — this is the spine everything else hangs off. Second, build Public Holidays for every country, region, or city you operate in, and decide on any Mandatory Days. Third, configure Accrual Plans with milestones that encode your seniority and carry-over policy. Fourth, create Allocations — Regular for granted-up-front entitlements, Accrual for earned leave — using Multiple Requests to push them out by department or company.

If you run Payroll, map each type to its Work Entry Type early and test the Deferred Time Off path so late-submitted leave does not break a closed pay period. If you operate across jurisdictions, remember that public holidays are per working schedule: a single global entry will quietly misfire for anyone on a regional calendar.

A clean configuration here pays compound interest: accurate balances, fewer manual corrections, defensible audit trails, and payslips that just work.

1. 01
   Lock down Time Off Types first

   Define every leave category with its approval policy, duration, Count as, supporting-document rules, and Payroll Work Entry Type. Everything downstream depends on these.

2. 02
   Configure Public Holidays per working schedule

   Enter regional holidays under Configuration > Public Holidays, scoped to the right working hours. These propagate to Calendar, Planning, and Manufacturing automatically.

3. 03
   Build Accrual Plans with seniority milestones

   Use milestone triggers (At allocation creation, or After N days/months/years) to encode tenure bands, then set frequency, worked-time basis, carry-over, yearly cap, and balance cap.

4. 04
   Push Allocations to the right scope

   Use Multiple Requests (By Employee, Tag, Department, Company, or All) to grant Regular or Accrual allocations so nobody starts with a zero balance.

5. 05
   Validate the Payroll loop

   Confirm work entries flow to payslips, and exercise the Time Off to Report > Defer path so a late request never forces a payslip reissue.