If you’ve ever tried to build a payroll localization for Odoo or write a custom attendance integration, you know the drill: clone the enterprise repo, open the models, read every method docstring, trace the call chain through three modules, and hope the code you’re reading hasn’t been refactored since last week. The official documentation covered what users see in the interface, but the machinery underneath — the models, the lifecycle hooks, the computation sequence that turns work entries into payslip lines — was undocumented territory.
That just changed in a big way. Odoo has published a complete technical reference for its entire Human Resources and Payroll stack, spanning six new sections in the developer documentation. The scope is remarkable: nearly 8,000 lines of new documentation covering the HR core, Payroll, Time Off, Attendances, Salary Configurator, and Resource modules. This isn’t a light overview. It’s the kind of reference that tells you which method to override, what the evaluation context contains, and where the computation can be extended without breaking the chain.
HR Core: The Employee Version Model
The HR documentation starts with the fundamental architecture change in Odoo 20.0 that most developers haven’t internalized yet: there is no more hr.contract model. Contractual data now lives on hr.version, and understanding the delegation pattern between employees and their versions is essential for anyone writing HR-adjacent code.
The new reference documents the full employee model, including version creation, how the current version is resolved, the relationship between contract dates and version records, and the mechanism for adding time-dependent fields. It covers contract templates, multi-company behavior, the departure workflow, and the access rights model. There’s even a Graphviz model diagram showing the relationships between the core entities.
Payroll: From Work Entries to Payslip Lines
The payroll documentation is the largest section, weighing in at nearly 3,700 lines across eleven pages. It walks through the entire computation pipeline: how work entries are generated from attendances and time-off records, how they’re typed and validated, how payslips consume them through worked days and input lines, and how salary rules execute in sequence to produce the final pay lines.
The rule evaluation context section alone is worth the read. It documents every variable available inside a salary rule’s Python expression — the employee record, the contract (version) data, the worked days, the input lines, the payslip itself, and the helper functions for prorating, currency conversion, and date arithmetic. If you’ve ever wondered why your custom salary rule can access payslip.dict or whatcategories.GROSS actually returns at evaluation time, the answer is now written down.
There’s also a section explicitly dedicated to writing payroll localizations: the patterns for country-specific salary structures, how to extend the rule set, how to add new work entry types, and how to hook into the declaration framework for tax filings. This is the guide that localization developers have been reconstructing from source code for years.
Time Off: The Full Request Lifecycle
The time-off technical reference documents the request lifecycle from creation through approval, covering durations, the approval flow, resource leave creation, public holiday interactions, mandatory days, and how time-off requests are split when they span breaks in the work schedule. The section on allocations covers balances, accrual plans (including milestones and carry-over rules), and how the system resolves the remaining balance for a given leave type.
For developers building integrations with external leave management systems, the documented connection between time-off records and work entries is critical: it explains how an approved time-off request translates into work entry lines that the payroll engine then consumes, and what happens when a request is modified after work entries have already been generated.
Attendances, Resources, and the Salary Configurator
The attendance documentation covers the check-in/check-out model, overtime calculation rules, validation constraints, and the bridge module that connects attendances with the time-off system. It explains how attendance-based work entries are generated and how scheduled actions process attendance data on a daily cycle.
The resource module documentation is aimed at developers encounteringresource.calendar and resource.mixin for the first time. It covers the Intervals class, the conventions for interval methods (timezone handling, the resources_per_tzgrouping, the calendar-level False key for company schedules), working schedule types, and how the resource mixin injects scheduling capabilities into any model that needs them.
The salary configurator reference documents the entire offer lifecycle in hr_contract_salary: from initial simulation through benefit selection to final acceptance. It covers the employer budget calculation, yearly cost computation, the benefit configuration model, personal information collection, and the controller hooks that localization modules use to extend the configurator with country-specific benefits and tax calculations.
The Tooling That Made It Possible
Two supporting changes shipped alongside the documentation. First, the autodoc build system now supports enterprise module models. By adding enterprise source directories to the odoo.addonspath, the documentation can use autodoc directives to pull field definitions and method signatures directly from models likehr.payslip and hr.salary.rule. An environment variable lets the build system locate the enterprise sources wherever they live on the build server.
Second, a fix to the autodoc field extension prevents build crashes when documenting fields with environment-dependent defaults — the common default=lambda self: self.env.companypattern that appears throughout the HR modules. Previously, the build tried to evaluate that lambda on the model class, which predictably crashed. Now it skips the default display in that case, which is the correct behavior since a lambda default isn’t useful information in API documentation anyway.
What This Means for the Ecosystem
This documentation drop is arguably the single most developer-friendly change Odoo has made in 2026. Payroll localization is one of the highest-value customization areas in the ERP world — every country needs one, they’re complex, and they were being built by reverse-engineering source code. Having a canonical reference that explains the computation model, the extension points, and the conventions means fewer broken localizations, faster development cycles, and more reliable integrations.
For integration developers building attendance kiosks, leave management tools, or scheduling systems that need to interact with Odoo’s HR layer, the resource and attendance documentation closes the gap between “what the user sees” and “what the code expects.” That gap has been the source of countless bugs in third-party modules. Fewer of those bugs start here.