Odoo HR and Payroll implementation: when teams roll it out and what it covers
If you are replacing spreadsheets or a separate payroll tool, you are deciding whether to build Odoo HR and Payroll with your own team or with an implementation partner. According to Odoo's documentation, the HR module set covers Employees, Time Off, Attendances and Payroll, and the Payroll app is available only in the Enterprise edition. The work spans employee contracts, salary rules, work entries, country payroll localization and the accounting entries that pay runs post to the ledger.
This page is written for that decision and for the build that follows it. Odoo's edition rules, hosting options and support terms come from its pricing page and support documentation, and those sources change between releases, so confirm the current edition and hosting terms with Odoo before you commit to a licence model. Note that the Community edition is open source under LGPL-3.0, but Enterprise source code is not publicly available and requires a subscription or partner access, which affects who can build and maintain Payroll.
Most of the effort sits outside the screens. Before go-live you need agreed rules for contract types, pay structures, overtime and absence codes, and the mapping from each rule to a payslip line and a ledger account. Each country also brings its own statutory deductions, reporting and filing obligations, so confirm whether an Odoo localization exists for each payroll country and who will maintain it after release. Ask your finance team to sign off the journal and account mapping before the first test pay run.
Decide early who owns each part of the build: HR owns employee data and time-off policy, payroll owns salary rules and statutory checks, finance owns the accounting mapping, and IT owns hosting, access control and the upgrade calendar. Plan for the upgrade path as well, since Odoo's support windows and mandatory major upgrades on Odoo Online and Odoo.sh will affect payroll configuration over the life of the system. Test every upgrade against a copy of production data before changing live pay runs.
What the Employees, Time Off, Attendances and Payroll apps do
These four Odoo apps share one employee record, so a decision made in one usually affects the others. Employees holds the record, while Time Off, Attendances and Payroll each read from it and add their own data. Confirm the edition each app requires before scoping, since Payroll depends on Enterprise.
Employees: the HR hub
Employees is the employee record that the other apps link to for leave, attendance, contracts and payslips. It typically holds identity, work contact, department, manager and work location details, so decide which fields your HR process needs before any import. Check who may edit these fields, and how departing employees are archived, because archived records still affect historical reports and pay data. Confirm with Odoo's documentation which Employees features are available in Community and which require Enterprise.
Time Off: leave and allocations
Time Off handles leave requests, approvals and allocations, such as the balance an employee receives for a leave type in a year. Decide early which leave types you need, how allocations are granted or accrued, and who approves each request, because these rules drive most of the configuration work. Confirm which Time Off features fall under Community and which need Enterprise, and whether your leave policies can be modeled without custom code. Leave records also feed pay calculations, so agree the leave types with the people who own pay rules.
Attendances: check-in and check-out
Attendances stores employee check-in and check-out records, including any kiosk or self-service entry options your version provides. Decide who records attendance, how corrections are approved, and whether the attendance data will feed the work entries used in payroll. Confirm the current edition requirements for Attendances and its entry options in Odoo's documentation before scoping, because these vary by version. Attendance data is personal and time-related, so agree retention and access rules with your HR and legal owners before the first live records are created.
Payroll: contracts through payslips
Payroll covers contracts, salary structures, pay runs and payslips. Contracts hold each employee's pay terms, salary structures define how pay is calculated, pay runs batch employees for a period, and payslips record the result for each person. Payroll requires an Enterprise subscription, so make the licensing decision before design starts. Country localizations supply much of the tax and contribution logic, so confirm your country's package and its support status with Odoo before you commit to a timeline.
Why Payroll needs an Enterprise subscription and how to confirm it
Odoo ships in two editions. The Community edition is fully open source and licensed under LGPL-3.0, with its code published on GitHub. The Enterprise edition adds features and support, but its source code is not publicly available, so using it requires a subscription or partner access. For an on-premise installation, Enterprise databases are activated by entering a subscription code. Payroll sits in the Enterprise group of apps in this plan, so the budget for a Payroll project starts with the subscription, not with the free download. Confirm the current app list with Odoo before you assume which apps a given edition includes.
Odoo's pricing page lists three plans. One App Free covers one app with unlimited users and runs on Odoo Online only. Standard covers all apps and also runs on Odoo Online only. Custom is priced per user per month, with a yearly discount, and it is the only plan that can be hosted on Odoo.sh or on-premise. Only Custom includes multi-company, Odoo Studio, external API access and custom modules. If your payroll must run in your own cloud account or data center, Custom is the plan to scope. Multi-company matters when pay runs cover several legal entities, and custom modules matter when salary rules or payslip reports need changes that standard configuration does not cover.
Payroll requirements depend on your country and on where you host. Each country localization can bring its own salary rules, payslip layouts, statutory reports and bank file formats, and some of these may be delivered differently for on-premise and Odoo.sh. Before you budget, ask Odoo in writing which Payroll components your country and hosting choice require, and which of them are included in the subscription you plan to buy. Ask whether any country component is an add-on, whether per-user pricing counts every employee who appears in Payroll, and what the yearly discount applies to. Keep the answers with the written scope so the quote and the build plan match.
The subscription is also a recurring cost, and it sets your support and upgrade position. Odoo's standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Security patches are only provided during standard support, and paid extended support is limited to Odoo.sh for select versions and on-premise. On-premise upgrades through the upgrade service require an Enterprise subscription, and the Community edition has no access to that service. Plan the Payroll budget over the life of the system, and check the release dates for the version you deploy before you commit to a go-live date.
Which configuration decisions shape the HR and Payroll build
This table compares the configuration choices that set the shape of an Odoo HR and Payroll build, with the options for each and when each one fits. Read it before scoping, because hosting, subscription scope and sign-in choices constrain the later payroll design. Confirm plan and app availability for Payroll with Odoo before you commit to a hosting model.
| Decision | Options | When each option fits |
|---|---|---|
| Hosting | Odoo Online, Odoo.sh or on-premise. Odoo.sh and on-premise are tied to the Custom plan. | Odoo Online fits teams that accept Odoo-hosted SaaS. Odoo.sh or on-premise fits teams that need Custom plan features and control over the environment. |
| Enterprise subscription scope | Community with Payroll not available, or Enterprise with the HR and Payroll apps licensed | Payroll is an Enterprise-only app, so a payroll build needs an Enterprise subscription. Confirm the exact apps and plan with Odoo before scoping. |
| Employee and contract model | Employee records only, or employees linked to versioned contracts with salary terms | Contract-based setup fits organizations that pay by contract and need history of salary changes. Confirm how contract states drive pay runs in your Odoo version. |
| Salary rule structure | Standard rules from the country package, or custom rules and categories built for your pay components | Standard rules fit simple pay components. Custom rules fit allowances, deductions and bonuses that the default structure does not express. Custom rules add testing and upgrade effort. |
| Work entry types | Default work entry types, or custom types for leave, overtime, shifts and absences | Default types fit standard working time. Custom types fit shift patterns, overtime rules or absence codes that must map to pay rules and reports. |
| Country payroll localization | Official country localization for Payroll, or a custom build for an unsupported country | Use the localization where it exists for your country and confirm its legal coverage with your payroll advisor. Custom payroll for an unsupported country is a larger, separately scoped build. |
| Accounting journal and account mapping for pay runs | One payroll journal and account set, or separate journals by company, department or pay run type | A single journal fits one legal entity with simple reporting. Separate journals fit multi-company groups or teams that need cost center or entity-level posting. |
| Sign-in method | LDAP with optional user creation on first login, Google Sign-In, Microsoft Azure OAuth or two-factor authentication | LDAP fits organizations with an existing directory. Microsoft Azure OAuth fits Microsoft 365 estates. Two-factor authentication is a layer to add to any method for payroll access. |
How contracts, salary rules and work entries feed each pay run
The way contracts, salary rules and work entries interact decides every payslip, so this design has to be settled before anyone configures a pay run. An employee's contract holds the terms the payroll calculation reads: the agreed pay arrangement, the working schedule it assumes, and the dates that determine which terms apply in a given period. When a contract changes mid-period, such as a salary change or a move to part-time, the team must decide whether the change applies from the effective date or from the next period. Record these conventions with HR and the payroll provider in writing before build starts, because they are hard to unwind once payslips exist.
Salary rules compute each component of pay, such as base salary, allowances, overtime and deductions. Each rule reads inputs, applies a condition and produces a result that flows into payslip totals. The design decisions are which components are fixed and which vary with time or attendance, how rounding is applied, what order calculations run in, and which deductions are statutory and which are voluntary. Country localizations supply much of this logic, so confirm which rules come from the localization for your country and which need custom work. Finance should review the output categories early, because they drive the accounting entries produced later.
Work entries are the inputs that connect time to pay. Attendances and Time Off record what happened, and Odoo turns those records into work entries that the pay run consumes. The link between a recorded hour or day of leave and a paid component is a design choice, not a default to accept without review. Decide which attendance source is authoritative, how each absence or leave type is classified, how overtime is identified, and who approves entries before a pay run is generated. Ask the team to list every work entry type with its pay treatment, and name an owner for correcting entries after approval. Gaps here appear as missing or duplicated pay.
HR, finance and the payroll provider each own part of the design. HR owns contract terms and pay policy, finance owns the ledger mapping and cost allocation, and the payroll provider or country specialist owns statutory calculations and filings. Agreeing sign-off across these three groups before configuration prevents rework. A rule changed after go-live can alter historical comparisons, affect reported figures and require corrections, so the sign-off record should state who approved each rule, each work entry type and each accounting mapping, and on what date.
Check results on a neutralized database copy before any live use. Odoo documents duplicating a database with neutralization for test copies, which lets the team run a trial pay run without contacting employees, sending bank files or posting to live accounts. Compare each payslip total with an independent manual calculation for a sample that includes mid-period starts, leave, overtime and leavers. Repeat the trial until the differences are explained and accepted by HR and finance. Confirm how neutralization behaves in the Odoo version you run, including which outbound channels it disables, before relying on it for sign-off.
How an Odoo HR and Payroll implementation runs, step by step
The sequence moves from edition and process decisions to employee data, pay rules and accounting, then to validated test data, parallel pay cycles and handover. Each step closes with an output that the client signs off, so payroll goes live only after its rules, data and journal entries have been checked.
Confirm edition, hosting and target version
DeployOpen starts by checking which apps the client needs, whether Payroll and the country localization are available on the chosen edition, and where the database will run. Odoo's pricing page lists Custom as the only plan that can be hosted on Odoo.sh or on-premise, and on-premise Enterprise databases are activated with a subscription code. Confirm with Odoo which features are Enterprise-only in the target version. The output is a written edition and hosting decision that names the target version and its standard support end date, signed off by the client before configuration begins.
Map pay processes with HR and finance
HR and finance leads walk through the current pay cycle: who changes employee records, how overtime and absences reach payroll, how payslips are approved, and who posts the resulting entries. DeployOpen records each step as a process map with owners and hand-offs, and flags where spreadsheets or manual approvals remain in use. Finance confirms the accounting hand-off points at this stage, so later design decisions follow the way the business actually pays staff. The output is a process map signed by the HR and finance leads, which becomes the reference for every later configuration choice.
Define employee, contract and time data model
The team agrees the employee record fields, departments, work locations, contract types, and the start and end dates that drive each pay period. Time Off leave types and accrual rules, along with Attendances check-in settings, are then configured so that absence and worked time attach to the same employee and contract records that feed pay. The output is a data dictionary listing each field, its owner and its source system, plus a set of sample employees that covers the main contract types. The client signs off the dictionary before any data is loaded.
Design salary rules, work entry types and localization
Salary structures and rules are designed from the signed process map, using the country payroll localization that matches the employer's jurisdiction. Work entry types map worked time, leave and other pay-relevant time to the rules that compute pay. Any gap between the localization and the client's own pay practice is logged as a decision for the payroll owner. Before the rules are built into Odoo, expected pay for each sample employee is calculated by hand so the results can be checked. The output is a rule catalogue and a set of hand-calculated payslips, signed off by the payroll and legal owners.
Map pay run journal entries to the chart of accounts
Finance maps each salary rule category to the accounts that receive its amounts, such as wages, employer contributions, tax withholdings and net pay liabilities, and selects the journal used for pay run postings. The mapping is checked against the chart of accounts and the fiscal localization in use, so each pay run balances. DeployOpen posts sample runs and reconciles the resulting entries to the payslip totals. Any difference is traced to a mapping or rule before the design moves on. The output is an account mapping table and a set of reconciled sample journal entries, signed off by the finance lead.
Load and validate data on a neutralized test copy
Employee, contract and leave data are loaded into a duplicated test database, using the database duplication with neutralization that Odoo documents for test copies. Neutralization is meant to keep test copies from acting on live systems, but the team should confirm which actions are neutralized in the target version before relying on it. Loaded records are compared with the source files for counts and key fields, and each exception is logged with an owner. The output is a validation report in which every exception is resolved or accepted by HR, and the client signs off the data load before any parallel run.
Run parallel pay cycles and compare results
The team runs one or more pay cycles in parallel with the existing payroll, using the same inputs, and compares gross pay, deductions, net pay and journal entries line by line. Each difference is traced to a rule, a data point or a source process, and the fix is made in the design before the next cycle. The number of parallel cycles follows from the client's pay calendar and its own risk appetite, so it is agreed in the written scope. The output is a variance log that shows every difference and its resolution, plus a go-live decision signed by the payroll owner.
Hand over admin procedures and upgrade path
DeployOpen documents the procedures the client team will run: creating employees and contracts, changing salary rules, running a pay run, correcting or reversing entries, and applying Odoo updates. The handover covers access roles, backup and restore steps, and the upgrade path, including the standard support window for the chosen version and the two-year major upgrade cadence that applies on Odoo Online and Odoo.sh. Client staff run a supervised pay run themselves before handover closes. The output is a runbook and a handover record signed by the client's HR and finance leads.
What drives effort and cost, and how to keep it down
This table lists the main drivers of effort and cost in an Odoo HR and Payroll rollout, why each one changes the work, and how to keep it contained. Read it before scoping, because most drivers are set by early decisions on country scope, plan choice, hosting and data readiness. The main takeaway is that one-time build effort and recurring subscription and upgrade costs are both shaped by these choices.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Countries and payroll localizations | Each country adds its own payroll rules, statutory deductions, reports and accounting mapping that must be configured and tested. | Limit the first go-live to one country and confirm the localization available for each other country before scoping. |
| Pay structures and exceptions | Each pay structure, allowance family and recurring one-off exception adds rules to design, test and explain to payroll staff. | Standardize pay elements, document exceptions and retire unused structures before the build starts. |
| Quality of historical employee and contract data | Missing contracts, wrong start dates and inconsistent job records slow loading and force manual checks during parallel runs. | Clean records in the source system, name a data owner and load a sample before the full employee set. |
| Custom salary rules | Rules beyond standard localization logic need design, development, documentation and retesting after every upgrade. | Keep custom rules to a written list and confirm which rules the localization already covers. |
| Sign-in and accounting integration | LDAP, Microsoft Azure OAuth or Google Sign-In and journal postings each need mapping, access rules and reconciliation. | Choose one identity source, map journal and account codes early and test one full pay run end to end. |
| Number of companies | Each legal entity adds its own payroll setup, accounts and access rules, and multi-company is a Custom plan feature. | Confirm the plan first, phase the entities and reuse one tested design across them. |
| Hosting choice | One App Free and Standard run on Odoo Online only, while Odoo.sh and on-premise require Custom and add infrastructure work. | Decide hosting against data residency, Enterprise licensing and your team's operating capacity before design. |
| Upgrade cadence on Odoo Online and Odoo.sh | Major versions are mandatory every two years and SaaS releases arrive every two to three months, so payroll rules need regression tests. | Plan test time for each upgrade cycle, keep a current test database and check localization changes before go-live. |
| One-time versus recurring costs | One-time costs cover design, configuration, data loading, testing and training. Recurring costs cover subscriptions, support and upgrades. | Ask for quotes that split these lines and confirm which subscription plan and support terms apply. |
How Odoo HR and Payroll connects to sign-in and accounting
Odoo HR and Payroll connects to three kinds of system: the sign-in methods that control who can open employee and payroll records, the Accounting app that receives pay run entries, and outside services such as banks or payroll providers. Odoo documents the sign-in options and the accounting link, while outside connectors must be verified before the project plan depends on them.
LDAP sign-in with template user creation
Odoo documents LDAP authentication, so users can sign in with credentials held in your directory. The optional setting that creates a user on first login from a template determines the access a new employee receives without an administrator creating the account by hand. Agree the template with HR and security before go-live, and confirm with a test directory how deactivated directory accounts are handled in your Odoo version.
Google Sign-In for employee accounts
Odoo documents Google Sign-In as a sign-in option for users. For HR and Payroll, the checks are which Google accounts may sign in, how a user created through another method is linked to the same employee record, and whether payroll administrators must sign in through a stronger method. Confirm the setup steps for the Odoo version you run, since sign-in settings can change between releases.
Microsoft Azure OAuth sign-in
Odoo documents Microsoft Azure OAuth as a sign-in option. The work sits with your identity team: registering the Odoo application in your Azure tenant, setting the redirect addresses that match your Odoo URL, and deciding which users or groups must consent. Test sign-in with an employee account and a payroll administrator account, because the two often belong to different groups.
Two-factor authentication for payroll access
Odoo documents two-factor authentication for user accounts. Enforce it first for payroll administrators, since salary changes and payslip access carry the highest impact in the system. Decide how users recover access when a phone is lost or replaced, and document that process with the help desk, so a locked administrator does not stall a pay run.
Pay run entries and journal mapping
Pay run results post to the Accounting app through journal mapping, which links salary rule categories and payroll outputs to journals and ledger accounts. Mapping errors usually appear at posting, so agree the chart of accounts, journal codes and tax treatment with the accounting team first. Test a full pay run in a copy of the database, then review the resulting journal entries against the expected totals.
Banks and payroll provider connectors
Bank files and payroll provider exchanges depend on connectors, and each one must be verified before you rely on it. Confirm that the connector exists, that its Odoo Apps Store listing matches your Odoo version and edition, and who maintains it. Where a connector uses external API access, note that this feature is part of the Odoo Custom plan, which affects licensing and hosting decisions.
Planning the upgrade path before payroll goes live
Before payroll goes live, confirm which Odoo major version you will run on the day of go-live and how long that version will receive standard support. Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and it includes security updates and bug fixes. Security patches are only provided during standard support, so a payroll database running on a version past that window carries unpatched exposure for personal and salary data. Treat the support end date as a go-live constraint, not a footnote, and record it in the project plan next to the payroll cutover date.
The documented dates are as follows. Odoo 20.0 was released in September 2026, with standard support planned until September 2029. Odoo 19.0 was released in September 2025, with support until September 2028. Odoo 18.0 was released in October 2024, with support until September 2027. Odoo 17.0 standard support ended in September 2026. Check today's date against these windows before you choose a target version. A payroll project that starts on a version close to the end of its window may need an upgrade within months of launch, which affects testing time, budget for upgrade work and the staff who must sign off on pay runs.
Odoo Online and Odoo.sh require major upgrades every two years, so the upgrade is not optional on those hosting types. SaaS versions also cannot use extended support, which means a SaaS deployment must stay on a version that is still in standard support. Odoo on-premise has a paid extended support option for some versions, but that option is limited and does not extend security patches beyond standard support. Ask Odoo or your partner to confirm the current extended support terms for any version you are considering, and confirm whether your hosting type is eligible. Do not assume that the hosting choice made for Employees or Time Off also covers Payroll, because the Payroll app is only available on the Custom plan according to Odoo's pricing page.
Plan the upgrade as a test, not a switch. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, and that copy should be tested before anything touches production. For payroll, the test must cover contracts, salary structures, work entries, the pay run, the payslips and the accounting entries that post from a pay run, then compare the results with a known payroll from the previous version. Include the country payroll localization in the test, since a localization update can change calculations. Schedule the upgrade test so it finishes well before a scheduled pay date, and keep a rollback position with a verified backup taken before the upgrade starts.
Put the upgrade decision into the project governance. Name an owner for the version calendar, agree who approves the target version and who signs off the upgraded test results, and add a recurring review that compares the current version's standard support end date with the planned payroll lifecycle. Ask your implementation partner to show how custom modules, Studio customizations and integrations will be ported during each upgrade, because these items usually take more effort than the core application. Confirm these points in writing before the build starts, so that the first upgrade after go-live does not become an unplanned project.
How long, how much and what does an Odoo HR and Payroll implementation need from us?
How much does an Odoo HR and Payroll implementation cost?
The cost follows the written scope, and DeployOpen does not publish a price list. Four cost components usually apply: software licensing, implementation labor, data migration and integrations, and internal time from HR and finance. Licensing depends on the Odoo plan, the number of users and whether Payroll is included, since Payroll requires the Enterprise edition. Labor rises with the number of countries, custom salary rules and integrations with banks or accounting. Ask for a quote that separates one-time work (design, configuration, migration, training) from recurring items (subscriptions, hosting, support retainers and upgrades). Compare quotes on the same scope, not on the headline total.
How long does an Odoo Payroll rollout take?
Timing depends on scope, so no fixed duration applies to every project. The largest drivers are the number of countries and their payroll localizations, how many pay structures and salary rules must be built, the quality of employee and contract data, and how many sample pay runs your team needs to approve. Integrations with accounting and bank files add test cycles, and sign-off by process owners can set the pace. Ask for a timeline in the written scope that lists phases, the people who must approve each phase, and the number of test cycles included. A timeline that does not name these dependencies is not yet reliable.
Which Odoo costs are one-time and which recur after go-live?
One-time costs cover scoping, configuration, custom rules, data migration, testing and training. Recurring costs cover the Odoo subscription, which is billed per user on the plans Odoo lists, and hosting if you use Odoo.sh or on-premise, which the pricing page limits to the Custom plan. Support and upgrades also recur. Odoo's standard support covers the first three years after a major release, and on Odoo Online and Odoo.sh major version upgrades are mandatory every two years. Odoo 19.0 receives standard support until September 2028, and Odoo 20.0 until September 2029. Confirm these dates and plan terms with Odoo before you sign.
Can our HR team implement Odoo Payroll without a partner?
Yes, for a simple single-country setup with a standard pay structure and a team that has time to learn the configuration. Payroll requires the Enterprise edition, so a Community-only setup cannot run it. A partner is more useful when you have several countries, custom salary rules, integrations with payroll banks or accounting, or a need for documented test evidence for audit. Be honest about internal capacity: someone must own the configuration after go-live, handle upgrades and manage new hires and leavers. Ask any partner to show how they would scope your case in writing before you decide.
What do HR and finance teams need to provide during the project?
HR needs named process owners who can confirm contract types, pay elements, leave rules and approval paths. Finance needs to confirm how pay runs post to the general ledger, including journals, accounts and cost centers. Both teams need to provide sample pay runs from the current process so the new configuration can be compared against known results. Plan for sign-off at defined points: design, configuration, test runs and go-live. Without named owners and timely sign-off, the project tends to slip, and differences found late are more expensive to correct.
How does employee data quality affect an Odoo payroll project?
Data quality is one of the largest effort drivers. Missing contracts, inconsistent salary records, duplicate employees and unclear department structures increase reconciliation time during migration and testing. Before scoping, review a sample extract of employee, contract and bank data and count the exceptions. Decide which historical data moves into Odoo and which stays in the legacy system for reference. Clean data also shortens test cycles, because differences between sample pay runs and current results are easier to trace to a rule rather than to a record. Ask the implementation team to state the data cleanup they expect from your side.
How is an Odoo HR and Payroll project scoped in writing?
A written scope lists the apps in use, the countries and localizations, the number of employees and contract types, the salary rules and pay elements, the integrations, the data to migrate, the environments and the acceptance criteria. It also states the deliverables, the responsibilities of each party, the timeline dependencies and how changes are handled through change requests. DeployOpen plans and delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts. Ask for the written scope and quote together, and check that every item in the quote maps to a line in the scope.
How DeployOpen scopes, delivers and supports Odoo HR and Payroll
DeployOpen plans and builds Odoo HR and Payroll inside the client's own infrastructure, with the employee data, contract rules and pay logic agreed before configuration starts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first, and ongoing support is available as a retainer.
How we scope
- Written scope lists the Odoo apps in use, such as Employees, Time Off, Attendances and Payroll, and the edition each one requires.
- Scope names the countries, pay structures, contract types and salary rules that payroll must support at go-live.
- Scope records which accounting journals and accounts receive pay run entries, agreed with the finance team.
- Scope confirms the Odoo edition, hosting type and support window against Odoo's published documentation before work begins.
How we build
- Contracts, salary structures and salary rules are configured and tested against agreed sample employees and pay scenarios.
- Work entry types and attendance data flows are mapped so that payroll reads the time records the business actually keeps.
- Country payroll localization settings are checked against the scoped jurisdictions, with open points logged for the client to confirm.
- Pay runs are reconciled to accounting entries in a test database before any production payroll is processed.
How we hand over
- Handover includes a document of configured contracts, salary rules, work entry mappings and accounting postings.
- Test evidence records each pay scenario run, its expected result and the sign-off by the client's payroll owner.
- Administrators receive runbooks for adding employees, changing salary rules and closing a pay period.
- Access controls, sign-in methods and administrator roles are documented so the client can review them after handover.
How we support
- Retainers cover ongoing support, configuration changes and testing as tax tables and payroll rules change.
- Upgrade planning follows Odoo's published support windows, with a test database checked before any production upgrade.
- Ask whether post-go-live support covers payroll cut-off periods and how urgent pay issues are escalated.
- Confirm with DeployOpen how security updates and patches will be applied within the chosen Odoo support window.
