Designing payroll in Odoo: structures and salary rules
Building payroll in Odoo is not data entry on a screen; it is structure design. The contract supplies the recurring amount, the structure groups the rules, and the rules compute in a defined order. Most defects in live systems trace back to structure and order rather than to arithmetic. This article separates the components and the decisions that must be settled before go-live, starting from the question that precedes everything else: where each amount in the payslip comes from, and in what order it is computed. Differences are always reviewed against real data in a test environment. For the wider components see Odoo Payroll.
The contract is the source of the recurring amount
The contract in Odoo Human Resources is the source of the basic salary and the fixed allowances. If the contract is incomplete or out of date, the gap carries into every later payslip and turns into repeated monthly adjustments. Contracts are therefore reviewed before the structure is built: basic salary, allowances and the nature of each allowance, effective date, branch, job position and contract type. Every amendment should have a dated effect, because a payslip must reflect what was in force during the pay period, not what is in force today. An element that is not documented in the contract or an annex should not appear in an ordinary payslip; otherwise the salary becomes the result of individual judgement rather than a contractual obligation.
Salary structures: why more than one
A single structure imposed on everyone pushes the team into manual exceptions every cycle. A Saudi entity usually needs several: a structure that differs by employee nationality or scheme where the components differ, a structure per company or branch inside a group, a structure for part-time staff or contractors, and a structure for employees whose allowances have a different nature. Naming structures clearly and linking them to employee categories prevents the repeating error of computing an employee on a structure that does not apply to them. Review the structure on every statutory or contractual change and keep the last approved version, because a structure is a working document rather than a passing setting.
Salary rules and computation order
Order matters more than the formula, because a correct formula produces a wrong figure if it runs before the rule that feeds it. Decisions to settle about order:
- Identify which rules build the base before the rules that depend on it.
- Set the computation order so no rule runs on a result that has not been computed yet.
- Separate rules that adjust the total from rules that adjust the base.
- Give each rule a clear name and a short code that identifies it during review.
- Test each rule on one known case before running a full cycle.
- Document the order in a single note that is reviewed whenever the structure changes.
A sound rule is explainable: the accountant can say where a figure came from and which rule produced it, and can reproduce it in the next cycle without a manual repair.
Earnings and deductions: a rule that computes and a rule that only displays
A structure holds three families of rules: a rule that posts an amount into the payslip, a rule that computes a value used as the base of another rule without appearing as its own line, and a rule that only displays information for review. Confusing them makes a payslip look correct while the base behind it is not computed. The design should therefore separate earnings that are added from deductions that are subtracted, and define for each rule its accounting account and its nature. The statutory treatment of end-of-service benefits and mandated deductions belongs to the competent authority and the applicable regulations, which change; it must be settled with the client's accountant and a licensed legal or HR specialist, and the current official texts must be checked before any treatment is applied. We do not issue legal or Sharia rulings in this area.
Attendance, leave and overtime
- Regular attendance and check-out records on the days the salary depends on.
- Leave requested and approved before the cycle closes, not after.
- Overtime approved by the designated manager under a clear policy.
- A published policy for absence and any related deduction.
- Review of exceptions before computation, not after.
If these records are not maintained, the payslip has no sound base, and the difference is either repaired by hand or ignored. A practical rule follows: any element computed from time must have a source that can be reviewed, otherwise payroll becomes an estimate.
Payslip batches, accounting entries, access and the parallel run
Payslips are usually generated as one batch and then reviewed individually before confirmation, and confirmation stops editing, so anything corrected afterwards is fixed by an entry or an adjustment rather than a silent change. After confirmation the payslip produces accounting entries that post to the accounts defined in the structure or on the employee category. The totals of the run must be reconciled with those accounts, and interim accounts and outstanding balances reviewed. In multi-company or multi-branch groups, lists and permissions are separated, while a consolidated run remains possible where needed. Before final approval, run one complete cycle in parallel with the previous method and compare the results line by line; that step is central to HR and payroll work because it exposes structure and order differences before they become a monthly obligation. Access is a separate decision: who approves the run, who may see salaries, and who may amend the structure, since salary access is not general administrative access. Any treatment of end-of-service benefits or statutory deductions must be confirmed with the client's accountant and a licensed legal or HR specialist, and the applicable regulations remain the reference and can change.
What we do not guarantee
- We do not give a legal or Sharia ruling, nor a binding interpretation of the regulations; the competent authority and licensed specialists remain the reference.
- We do not guarantee that any treatment applies to an individual case without specialist review.
- We do not commit to a price or a duration before a written scope analysis; any time estimate is a planning range only.
- We do not guarantee that any auditor or authority accepts a payroll structure; acceptance is their decision alone.
- We do not guarantee a commercial outcome or a search ranking.
- We do not issue a certificate or an accreditation, and we do not represent any regulatory body.
Related Articles
Odoo reporting and KPIs: from data to a measurable indicator
How Odoo data becomes an indicator that drives a decision: standard reports versus analysis views and pivots, defining numerator, denominator and period, the data-quality precondition, and reconciliation with the general ledger.
9 min
Access rights and approval flows in Odoo
A practical guide to the three security layers in Odoo, how to build a role-against-action decision matrix, where approval tiers are configured, and what must be tested with a real account before go-live.
9 min
E-invoicing data readiness in Odoo
Connecting Odoo to the e-invoicing platform is a well-defined technical step, but the real obstacle is usually the data Odoo sends. This article separates what must be correct in that data before connecting is worth doing.
9 min