Odoo Payroll: Salary Rules, Payslips and the Localisation Question

What Odoo Payroll actually is

Odoo Payroll turns a contract and a time period into a payslip, and a batch of payslips into a journal entry. It is built as a rules engine: you describe how pay is calculated, and it calculates it.

That design is the reason it can model almost any scheme, and the reason it is not plug-and-play. A generic engine has to be told your rules. Where Odoo maintains a localisation for your country, most of that telling is already done. Where it does not, you are describing your national payroll system in salary rules, and that is a real project rather than a configuration afternoon.

Establish which situation you are in before anything else. It changes the cost of the module by an order of magnitude, and it is a question with a definite answer.

Contracts, which are the input

A contract holds the employee, the period, the wage, the salary structure that applies, the working schedule, and any scheme-specific values such as allowances or benefits.

Contracts are dated and versioned, so a raise is a new contract rather than an edit, and payslips run against whichever contract covered the period. This matters for retrospective corrections and for audit, and it means the discipline of creating a new contract rather than overwriting the old one has to be understood by whoever administers it.

A missing or expired contract is the single most common reason a payslip does not generate, and the message when it happens is less obvious than it should be.

Salary structures and rules, where the work lives

A salary rule produces one payslip line. It has a code, a category, a sequence, a condition determining whether it applies, and a computation that can be a fixed amount, a percentage of another rule, or a Python expression.

A salary structure is an ordered set of those rules. Order matters, because rules reference each other: net depends on gross minus deductions, and a deduction may be a percentage of a figure computed three rules earlier.

Building a structure from scratch is careful work. The failure mode is not that it breaks loudly, it is that it produces a plausible number that is wrong for one category of employee in one situation, and nobody notices for two quarters. Test every structure against known-correct payslips before it goes live, including the awkward cases: mid-month joiners, unpaid leave, overtime, someone who left.

Work entries, and deriving pay from what actually happened

Work entries are the bridge between the rest of Odoo and payroll. Attendance, timesheets, time off and public holidays generate entries for the period, classified by type, and the structure can pay them at different rates.

This is what allows hourly pay, overtime premiums and unpaid absence to be derived rather than typed in. It only works if the upstream modules are used consistently, which is worth saying plainly: payroll derived from attendance data that people forget to record produces confident wrong payslips.

Accounting, and the mapping that takes the time

Each salary rule can carry debit and credit accounts, so a confirmed batch produces the journal entry: wage expense, employer contributions, net payable, statutory liabilities.

In practice this mapping absorbs a large share of payroll implementation effort, and it should be agreed with whoever owns the ledger rather than guessed by whoever configures the module. A payroll that computes correctly and posts to the wrong accounts creates a reconciliation problem every single month.

Where Odoo Payroll will fight you

The localisation gap is the main risk. Everything else on this page is manageable. This one determines whether payroll is a fit at all.

Statutory change is ongoing. Rates, thresholds and filing formats change. In a maintained localisation that is Odoo's problem. In a custom structure it is yours, forever, and it needs an owner.

Errors are highly visible. Payroll mistakes reach people's bank accounts and their trust in the whole system. It deserves more testing than any other module and a genuine parallel run.

Payslip access needs locking down. This sits alongside the HR access-rights question and carries the same weight.

How it connects to everything else

Employees and contracts come from HR. Time off, attendance and timesheets generate work entries. Confirmed batches post journal entries into Accounting. Expenses reimbursed through payroll can flow from the Expenses app. Analytic accounts on payroll entries let labour cost reach project profitability, which closes the loop back to Project and Timesheets.

Where to start

Answer the localisation question first, in writing, before payroll influences any other decision. If a maintained localisation exists, install it and work from its structures rather than building your own. Agree the account mapping with finance up front. Then run at least two full periods in parallel with your existing payroll and reconcile them line by line. Only cut over when the parallel run matches, including the awkward cases.