Odoo Payroll, Explained: Localizations, Salary Rules, and Work Entries

What Odoo Payroll Actually Does

Odoo Payroll is the Enterprise HR application that turns contracts, worked time, and localization rules into payslips and accounting entries. It runs with Employees, Time Off, Attendances, Planning, and optionally Timesheets: those apps feed work entries; salary structures and rules decide gross-to-net; confirmed payslips post to the ledger when Payroll Entries is enabled.

The flow Odoo documents for 19.0 is linear and non-negotiable: hire with a signed contract (structure, working schedule, benefits) → configure salary attachments if needed → generate and clean work entries for the period → resolve every conflict → create payslips or a pay run → process, pay (wire/check; cash is possible but not recommended), and close the cycle.

Odoo Payroll is not a generic calculator. A country-specific localization module must be installed so tax, contribution, holiday, termination, and reporting logic match the jurisdiction. The core app supplies the framework—structure types, structures, rules, work entry types, pay runs, commissions, analysis—while the localization supplies the statutory substance. Wrong localization means wrong rules, even if the UI looks complete.

Payroll Is an Enterprise-Only Module

Payroll is listed as an Enterprise-only app on Odoo’s official editions comparison page. Full first-party payroll with country localizations is not available in Community Edition; Community deployments either integrate an external payroll product or use third-party Apps Store modules with no Odoo S.A. statutory guarantee.

For SMEs budgeting an implementation, that constraint shapes TCO early: native payroll assumes Odoo Enterprise licensing plus the Apps you use for time (Attendances, Planning, Time Off) and Accounting for journal posting and optional SEPA/NACHA-style payment files. We flag this before setup because teams that discover it mid-project often face a forced re-scope—either upgrade to Enterprise or bolt on a specialist payroll tool and integrate only journal entries.

Setup Runbook: From Localization to First Pay Run

Treat go-live as a ordered checklist, not a pile of configuration screens. Skipping order is the most common source of “rules returned zero” and “cannot generate payslips” tickets.

1) Install the correct payroll localization from Apps (search the country name; some countries need both a Payroll module and a Payroll with Accounting module—Egypt is the documented example). Confirm under Payroll → Configuration → Settings that a country Localization section appears.

2) Configure Payroll Settings: accounting (Payroll Entries, optional Payroll SEPA, optional Batch Account Move Lines for anonymized period-level moves), Deferred Time Off responsible person for time off taken after a payslip was already validated, Contract Expiration and Work Permit notice periods, Payslip PDF Display, and YTD Reset Date (default 1 January).

3) Configure company master data used on filings (legal name, address, tax IDs, currency). In multi-company databases, each company can carry a different localization because law differs by entity and country.

4) Define or accept Structure Types and Salary Structures from the localization; map debit/credit accounts on salary rules before the first live run. Install working schedules and work entry types the localization expects.

5) Create employee records and contracts: wage type (fixed vs hourly), contract type, pay category, work entry source (Working Schedule, Attendances, or Planning), bank details where payment files are required, and localization-specific tax/benefit fields (for the US: W-4, state filing, 401(k), health, etc.).

6) Generate work entries for a dry-run period, open the Work Entries dashboard with the Conflicting filter, approve or refuse time-off conflicts, fix source-app errors (Planning double-booking, unapproved attendance, etc.), then Regenerate Work Entries so Payroll re-pulls clean data.

7) Create a pay run by structure and pay schedule (or Generate Pay Run from the work-entry board), review Worked Days & Inputs (bonuses, tips, commissions, reimbursements), Compute Sheet, Validate, post draft journal entries, generate the payment report, Mark as paid, and only then treat the period as closed.

8) Parallel-run at least one full cycle against the previous system before cutover. Reversing confirmed payslips and reopening statutory totals is far more expensive than a controlled shadow payroll.

Salary Structures and Salary Rules

Each salary structure holds the ordered salary rules that produce payslip lines. A Structure Type groups structures and influences how work entries are generated; each Structure sequences rules for a role or pay category; each Rule has a unique Code referenced in Python expressions.

Rule code can use a fixed set of evaluation variables—payslip, employee, contract, rules, categories, and worked_days—so a later rule can take a percentage of an earlier gross, read a contract field, or apply a bracket. That is why Odoo Payroll is best described as configurable rather than endlessly custom: country behaviour is expressed as rules, codes, categories, and rule parameters (rates and caps) rather than one-off server code.

Rule parameters store percentages and wage caps that rules reference (for example, a Social Security wage base cap for a given tax year). Odoo ships calendar-year parameter updates with localizations; edit them only when law has changed and you have confirmed the new rate. Commissions in 19.0 can feed payroll via the Commissions app path (warrant payslips) or as salary inputs on a payslip; sales commission automation has improved, but many teams still add explicit inputs or rules that read commission models for edge cases.

Salary attachments (adjustments such as garnishments or recurring deductions) must be configured before you rely on a clean net. Inputs on the payslip cover one-off bonuses, tips, reimbursements, and similar amounts that are not derived from the contract alone.

Work Entries: Hours, Sources, and Conflict Resolution

A work entry is a dated unit of attendance, overtime, training, public holiday, or time off on the employee’s payroll timesheet. Payroll auto-creates work entries from the employee’s structure type and from Planning, Attendances, and Time Off (Timesheets are also cited on the main Payroll overview as a source path). Payslips compute worked time from those entries—not from a free-typed hour field on the slip.

The Work Entries dashboard (Payroll → Work Entries → Work Entries) shows a month view, ordered by employee, with the current day highlighted. The default Conflicting filter shows only rows that block processing. Conflicts appear with an orange indicator: typical causes are unapproved time off, duplicate regular-plus-leave entries for the same slot, missing clock-ins, or planning overlaps.

Time-off conflicts are the most common. If leave is requested after regular work entries already exist, Odoo surfaces the Time Off request on the conflict. You can Approve Time Off or Refuse Time Off on the work entry, or open the Time Off form for full context. Approved leave usually moves the conflicting regular entry toward Cancelled; refused leave returns the work entry toward Draft so regular work can stand. After source apps are fixed, use Regenerate Work Entries for the employee and date range so Payroll overwrites the bad set—do not only patch the conflict in Payroll if Planning or Attendances still holds the error, or regeneration will recreate it.

Deferred time off is a separate control path. When leave is taken after payslips were already validated, Settings → Deferred Time Off assigns a responsible user so the day is applied in the next period instead of voiding a closed run. Time Off to Report (Payroll → Work Entries → Time Off to Report) handles deferred or cross-period leave costing for accruals and true-ups. Missing either path is a classic year-end accrual variance.

Work entry types carry payroll codes, optional external codes for third-party export, rounding (none / half day / day), unpaid structure links, and Time Off type linkage. Localizations may add country-specific types; only create custom types when the localization does not already model the absence or attendance class you need.

Country Localizations Run the Show

Localizations adapt payroll to labor law, tax, social security, benefits, holidays, termination rules, and statutory reports for a country or region. Odoo states explicitly that installing the correct country-specific localization is critical because it configures local and national rules, regulations, and taxes.

Install via Apps (clear the default filter, search the country). Some jurisdictions ship multiple modules (payroll plus payroll-with-accounting). After install, a country Localization block appears in Payroll Settings; Odoo warns against changing those defaults unless law or an exemption forces it. Multi-company setups assign localization per company so headquarters and foreign branches do not share the wrong tax engine.

Odoo 19.0 documents payroll localization pages for Australia, Belgium, Egypt, Hong Kong, India, Jordan, Kenya, Mexico, Saudi Arabia, Türkiye, United Arab Emirates, and the United States, plus Employment Hero for markets where payslips are administered outside Odoo. The localizations index also lists additional countries as available (for example Bangladesh, Indonesia, Lithuania, Luxembourg, Malaysia, Morocco, Netherlands, Pakistan, Poland, Romania, Slovakia, Switzerland)—coverage expands over time, so re-check the live documentation before you commit a go-live country.

Never copy salary rules between localizations. Rules depend on that localization’s categories, codes, and parameters. A US rule that computes cleanly can produce zero or negative lines under another country’s structure. Verify coverage on the live payroll_localizations page for your Odoo major version; a country present in 17 is not automatically complete in 19.0, and the reverse can also be true as new packages land.

Localization Matrix and Coverage Reality Check

Use the matrix below as a planning aid for Odoo 19.0 documentation depth—not as a substitute for installing and testing the module on your database. “Documented deep” means Odoo publishes a dedicated localization guide; “Listed / expanding” means the country appears on the localizations list and may ship modules with thinner public docs. Always confirm Apps availability on your exact version and edition.

US Example Path: Modules, Taxes, Pay Run, Filings

US searchers are a large share of “odoo payroll” intent, so here is a concrete path grounded in the Odoo 19.0 United States localization guide—not a substitute for counsel or a CPA.

Install United States - Payroll (`l10n_us_hr_payroll`) and United States - Payroll with Accounting (`l10n_us_hr_payroll_account`). The payroll module provides US basics: employee tax details, Basic/Gross/Net structures, tax rules, and W-2/3PA-oriented reporting. The accounting module creates journal entries that record payroll on the company’s books.

Configure the company with a full US address (the company state becomes the default work address for tax calculation), EIN, state company ID, USD, and contact details—Odoo warns that this data feeds W-2 creation. On each employee: trusted bank account (required for NACHA payment file generation; missing trusted accounts block payroll with dashboard warnings), SSN, work address state (drives which state salary rules apply), wage type (fixed vs hourly), contract type (exempt/non-exempt language can appear on payslips where law requires it), pay category United States: Employee, and work entry source.

Complete W-2 box 13 flags, W-4 federal withholding fields, state filing status and allowances (note: as of 2025 Odoo documents that Alaska, Florida, Nevada, New Hampshire, South Dakota, Tennessee, Texas, Washington, and Wyoming do not collect state income tax—leave state tax status blank where no state options exist), plus common benefits: 401(k) employee and employer match with yearly cap, health and commuter pre-tax deductions, ROTH 401(k) post-tax.

The installed structure United States: Regular Pay sequences income (basic, commissions, tips, bonuses) → gross → pre-tax benefits → taxable income → federal then state withholdings → post-tax deductions → net, with a parallel employer-deductions section for the employer share of payroll taxes. Rule parameters hold rates and caps (for example FICA OASDI wage base); adjust only when statutes change.

Run cycle: validate work entries → draft payslips or pay runs (often split hourly vs salary or by department) → review Worked Days & Inputs → Compute Sheet → Validate. Journal drafts typically hit US CoA patterns Odoo documents: 611000 Salaries & Wages, 230100 Employee Payroll Taxes, 230200 Employer Payroll Taxes, 230000 Salary Payable (codes/names editable). Post entries, generate payments only for employees with trusted banks, then close. Statutory exports include W-2 CSV, Form 941, Form 940, and optional ADP export when the US ADP export module is installed—e-file via your third-party filing channel.

State coverage is not “all 50 on day one.” Odoo’s 19.0 US page lists a defined set of states in the localization (AL, AZ, CA, CO, FL, GA, ID, IL, IA, MS, NV, NJ, NY, NC, OR, TX, VT, VA, WA, DC) and notes that federal taxes are covered by default with additional states added over time. Partner commentary in 2026 has discussed expanding multi-state support in product updates; treat any state-count marketing claim as version-specific and re-verify on your build and the official state table before promising a multi-state rollout.

When Employment Hero (Not Native Payroll) Is the Right Path

Employment Hero Payroll (module `l10n_employment_hero`; KeyPay rebranded to Employment Hero in March 2023) is the documented path when payroll administration stays in Employment Hero and Odoo only needs the accounting impact. The integration synchronises payslip accounting entries—expenses, social charges, liabilities, taxes—into Odoo as draft journal entries, with the Employment Hero payslip entry ID in the reference for reconciliation.

Configure API key, payroll URL per localization docs, Business ID (from the Employment Hero URL), and the Odoo journal for posts under Accounting → Configuration → Settings after enabling Employment Hero Integration. Map taxes so Employment Hero tax codes match Odoo taxes. Default sync is weekly; you can Fetch Payruns Manually. Create matching chart-of-accounts codes and names on both sides or the API will mis-post.

Odoo documents Employment Hero availability paths for Malaysia, New Zealand, Singapore, and the United Kingdom. Choose this model when local statutory depth, filing, or employee self-service is stronger in Employment Hero for your country, or when you deliberately want a best-of-breed payroll product with ERP accounting only. Choose native Odoo Payroll when your country has a solid first-party localization and you want contracts, time, payslips, and ledger in one system.

Pay Runs, Commissions, and Closing the Period

Pay runs batch payslips so payroll can process a structure and period together instead of one slip at a time. Create them from Work Entries (Generate Pay Run after conflicts are clear), from Payslips (Pay Run wizard: salary structure, pay schedule, period, employee selection), or from Payslips → Pay Runs → New. Status moves Ready → Done (after Create Draft Entry) → Paid (after payment report and Mark as paid). Revert is available until slips are paid.

Typical SME practice is one pay run per structure per period, sometimes further split by department or wage type (for example “Aug 1–14 2025 - Hourly” vs “Salary”). Review employer cost, gross, and net totals on the run list before posting. Payment report export format depends on localization (CSV is universal; banks and SEPA/NACHA options appear when localization supports them).

Commissions in 19.0 are first-class: Odoo documents commission payslips as warrant payslips and continues to tighten salesperson commission → payslip paths. Still validate commission timing against your revenue recognition and clawback policy; many finance teams keep commission as an explicit input until the rule pack is proven in parallel runs.

How Payroll Posts to Accounting

The accounting bridge is rule-driven. Debit and credit accounts are mapped on each salary rule so that when a payslip is confirmed and Payroll Entries is enabled, salary expense, liabilities, and net pay post as journal entries at the same granularity payroll computed. Optional Batch Account Move Lines collapses same-period lines for anonymized reporting and can disable individual payment creation—use deliberately.

For an SME, this is the main reason to run payroll inside the ERP rather than in a disconnected SaaS tool: one chart of accounts, one fiscal calendar, one audit trail from worked day to GL. The trade-off is design discipline: map rules to accounts in the design phase, because reopening confirmed payslips and reverse-engineering a messy COA mid-year is expensive. SEPA (when enabled) and localization payment files sit on top of the same posted reality.

The Dynamics 365 Equivalent — and When Each Fits

Microsoft takes the opposite architecture. There is no native Dynamics 365 Payroll engine for general use. Microsoft deprecated and removed legacy payroll from Dynamics 365 Finance paths; standalone Dynamics 365 Human Resources capabilities were folded into Finance and Operations infrastructure. The current Microsoft approach is integration: Dynamics 365 Human Resources exposes a Payroll Integration API and uses Dataverse so customers connect external benefits and payroll systems.

In practice, D365 HR integrates with specialist payroll providers for calculation, budgets, and tax filings rather than shipping a first-party engine. Customers who need payroll “inside Dynamics” typically buy third-party add-ons or iPaaS mappings.

When each fits an SME:

* Odoo Payroll fits when you want one system for HR, time, and payslips; your country has a maintained v19 localization (or Employment Hero for the documented markets); and you accept Enterprise licensing instead of a separate payroll vendor.

* Dynamics 365 plus a payroll partner fits when you are already invested in Microsoft finance, your jurisdiction is better served by a specialist (for example Ceridian Dayforce, UKG, or a regional bureau), and you want D365 as the system of record for HR master data with payroll executed elsewhere.

As a dual-platform partner, Flectic helps SMEs choose based on geography, existing licensing, statutory risk, and whether a first-party engine or a best-of-breed integration fits—not on a generic vendor preference.

An Implementation Checklist for SMEs

• →Confirm your country (and multi-company entities) have a v19 localization—or a deliberate Employment Hero / external plan—on the live odoo.com documentation before scoping build effort.
• →Budget Odoo Enterprise licensing; native Payroll with localizations is Enterprise-only on the official editions page.
• →Install localization packages completely (payroll + payroll-with-accounting when required), then freeze localization settings unless law forces a change.
• →Map salary rules to the chart of accounts during design; decide individual vs batch journal entries before the first live run.
• →Choose a single primary work-entry source per employee population (Working Schedule, Attendances, or Planning) and document overtime and public-holiday handling.
• →Staff the Deferred Time Off owner and a Time Off to Report routine every cycle for cross-period leave.
• →For US entities: trusted bank accounts, SSN, W-4/state fields, benefits, and a filing channel for W-2/941/940 CSVs before promising in-app e-file.
• →Parallel-run at least one full pay period; resolve work-entry conflicts to zero before cutover.
• →If you are on Dynamics 365, scope the Payroll Integration API and Dataverse entities against your payroll provider—do not assume a native engine exists.
• →Re-verify localization country lists, state coverage, and deprecation notes at go-live; they move between minor versions.

Common Pitfalls to Avoid

Assuming Community Edition can run first-party payroll. It cannot; Enterprise has owned this module path for years, and forum guidance for recent versions still points Community users to third-party apps or external payroll.

Installing the wrong country package—or none—and then “fixing” rules by hand. Localizations own statutory correctness; DIY rule packs without legal review are a compliance risk.

Copying salary rules across localizations. Codes and categories are not portable.

Generating payslips while the Work Entries dashboard still shows conflicts. Odoo requires conflicts resolved before processing continues for the period.

Fixing conflicts only in Payroll while Planning or Attendances still double-books time—regeneration will reintroduce the error.

Skipping trusted bank account setup on US databases and discovering NACHA generation fails on payday.

Promising all US states or every global country from marketing slides without checking the live localization table for your Odoo version.

Treating Employment Hero as native Odoo payslips. Administration stays in Employment Hero; Odoo receives accounting drafts.

The durable fix set: localization as source of truth, explicit rule-to-account design, zero open work-entry conflicts, and a parallel pay run before cutover.

Frequently asked questions