There’s a particular kind of HR problem that doesn’t announce itself. An employee joins the company, their profile gets created, their department and manager are assigned — and then nobody remembers to set up their leave allocation. Weeks pass. The employee tries to request time off. The system says no. A confused email lands in the HR inbox. Someone digs through settings, realizes the allocation was never created, backdates it, and moves on. It happens more often than anyone likes to admit.
Odoo 20 tackles this and two other quiet annoyances in its HR stack: employees without leave allocations now get a visible red warning on their profile, the birthday field finally shows the person’s actual age, and multi-company setups gain clearer handling for multiple identification numbers. None of these changes will make a keynote reel, but they’ll save real time in real HR departments.
A Red Badge That Says “This Employee Can’t Take Time Off”
The employee form in Odoo has always displayed a Time Off stat button — that clickable counter near the top of the profile that shows how many leave days someone has remaining. Click it, and you land on their time off dashboard. It’s useful, but it has a blind spot: if the employee has no allocation at all, the button simply shows zero. There’s no visual distinction between “this person used all their days” and “nobody ever set up their leave entitlement.”
Odoo 20 draws that distinction with a new red “Not Defined” badge. When an employee has no currently valid time off allocations — not a single active entitlement across any leave type — the standard Time Off button disappears and is replaced by a prominent red stat button labeled Not Defined. The color alone is enough to catch your eye when scanning through a list of employee profiles, and it tells the HR officer exactly what needs to happen: create an allocation for this person.
The badge is visible only to HR officers and time off managers, not to the employees themselves. This is a deliberate choice. An employee seeing a red warning on their own profile would likely generate a support request, when the fix is entirely on the HR side. By restricting visibility to the people who can actually resolve the issue, the feature avoids creating anxiety while still surfacing the problem where it matters.
There’s a subtle edge case worth noting: accrual allocations that haven’t accrued any days yet still count as valid allocations. If an employee was just onboarded with an accrual plan that starts accumulating leave next month, their profile won’t show the red badge. The system recognizes that an entitlement exists even if the balance is currently zero. This prevents false alarms during the normal ramp-up period of accrual-based leave policies.
The Allocation Dialog Gets Clearer Language for Officers
While reworking the allocation flow, Odoo 20 also cleans up the language in the New Allocation dialog — the form that appears when an HR officer or manager creates a leave entitlement for an employee.
Previously, the dialog showed a “Submit Request” button regardless of who was filling it out. That made sense for employees requesting additional leave from their manager, but it was misleading when an HR officer was granting leave directly. Officers don’t submit requests — their allocations are approved immediately. The button now reads Grant when the logged-in user has officer-level permissions, making the action match the outcome.
The number-of-days field has also been relabeled from “Ask for” to Duration. It’s a small wording change, but it removes the submissive framing that didn’t apply to officers granting entitlements top-down. When an HR director is assigning 25 vacation days to a new hire, “Duration: 25 days” reads better than “Ask for: 25 days.”
Employee Age, Right Where You Need It
This one sounds almost too simple to mention, but anyone who has administered payroll or benefits in Odoo will understand why it matters. Many HR processes depend on an employee’s age: pension contribution thresholds, insurance tier eligibility, legal retirement age calculations, youth employment restrictions, and age-based tax exemptions all require knowing exactly how old someone is. Until now, Odoo stored the birthday but didn’t compute the age. You had to do the math yourself.
Odoo 20 adds an Agedisplay directly on the employee’s Personal Information section, right next to the birthday field. It appears as a muted label — “(Age: 34)” for example — that updates automatically based on the stored date of birth. If no birthday is recorded, the age label simply doesn’t appear.
It’s the kind of feature that seems obvious in retrospect. Every HR professional who has ever opened an employee profile to check a benefit eligibility threshold has done the mental arithmetic: born in 1992, it’s 2026, so they’re 33 — wait, has their birthday passed this year? Let me check the month. The age field eliminates that entire thought process.
For payroll teams in particular, this is a workflow improvement that compounds. When processing benefits enrollment, reviewing pension contributions, or auditing age-dependent allowances across dozens or hundreds of employees, not having to calculate each person’s age manually saves meaningful time. It also reduces errors — the kind of off-by-one mistakes that happen when you’re doing birthday math at 4 PM on a Friday while processing the quarterly benefits review.
Multiple Identification Numbers for Multi-Company Setups
The third change in this batch addresses a documentation gap that has tripped up companies operating across multiple jurisdictions. Odoo’s company settings have always had a Tax ID field, but organizations subject to electronic invoicing requirements in certain countries need to register more than one identification number. A Belgian subsidiary might need a VAT number, a company registration number, and a DUNS number. A company invoicing in Saudi Arabia or Colombia might need additional fiscal identifiers that don’t fit neatly into a single Tax ID field.
Odoo 20 makes the path to adding these identifiers more discoverable. The Tax ID field is now also labeled as “VAT” in fiscal localizations where that terminology is standard, reducing the confusion that arose when European users looked for a “VAT number” field and found only “Tax ID.” More importantly, the plus icon next to the field — which has quietly existed for some time — is now explicitly documented as the entry point for adding DUNS numbers, secondary tax identifiers, and any other registration numbers a company needs to maintain.
For organizations running Odoo across multiple legal entities, this clarity matters. When setting up a new subsidiary, the accounting team needs to know where each identification number goes. Having the Tax ID field double as a VAT field with a clear mechanism for adding supplementary identifiers means fewer configuration errors during entity setup and fewer “where do I put this number?” questions landing in the admin channel.
The Pattern Behind the Details
None of these three changes — the allocation warning, the age display, the identification number clarity — would top anyone’s list of exciting ERP features. They don’t involve AI, they won’t generate marketing screenshots, and they don’t unlock new revenue streams.
But they share a common thread: each one removes a small, repeated friction from the daily work of HR professionals. The allocation badge catches a setup oversight before it becomes an employee complaint. The age field saves thirty seconds of mental math that happens hundreds of times a year across a large organization. The identification number improvements prevent configuration mistakes during subsidiary onboarding.
In mature ERP platforms, these are the changes that separate software people tolerate from software people trust. The difference isn’t usually a headline feature — it’s whether the system catches the things you forgot before they become problems.