HR and payroll software RFP questions for partners

HR and payroll software RFP questions to settle before you shortlist partners

If you are an HR or payroll lead who must choose an implementation partner for a self-hosted HR rollout, you need answers you can compare side by side. Write one set of questions and send it to every bidder, covering payroll localization for each country you run payroll in, data migration from your current HRIS, the edition the bidder recommends and why, hosting and backups, access controls for payroll data, support during payroll runs, and the upgrade policy. Keep the set vendor-neutral so the same questions apply whether the shortlist includes Frappe HR, OrangeHRM or Odoo. Ask each bidder to name the platform and version they would deploy, because the answers differ sharply between them.

Require written answers and score them against a fixed rubric agreed before responses arrive. Weight payroll localization and payroll-run support heavily, since errors there reach employees directly. Then test the written claims. Ask each shortlisted bidder for a reference-style demo on sample data you supply, with a payroll calculation, a leave carry-over and an export to your accounting system. Confirm each claim during the demo, and ask the bidder to show where the answer lives in the product or configuration. Where a bidder cannot demonstrate a capability, treat the answer as unconfirmed. Check the current Frappe, Odoo and OrangeHRM support and release pages yourself, since version support windows change.

DeployOpen does not publish prices, and no quote exists until the scope is written. Ask every bidder to price against the same written scope, and make the scope explicit about which countries, pay cycles, employee counts and integrations are included. Ask each bidder to separate one-time work, such as localization setup and migration, from recurring items, such as hosting, support retainers and upgrades. Ask who holds each software license or subscription, because some Odoo features require an Enterprise subscription. Request a written statement of what the quote excludes, and confirm that the fixed-scope agreement sets deliverables and timelines before any work starts.

Which questions to ask by area, and what a good answer contains

How do you localize payroll rules for each country we pay employees in?

A good answer lists every country in scope and the payroll rules the partner will configure for each: tax tables, social contributions, payslip formats and statutory reports. Ask for a written localization matrix that shows which rules come from the platform's own localization and which are custom work. Confirm which payroll functions sit in the edition you license, because the supplied facts do not establish that for every platform. Ask who maintains each rule after go-live when tax tables and contribution rates change, and whether that maintenance is included in the quote or billed separately. Request a test payroll run on sample data, reviewed and signed off by your payroll provider or internal payroll lead before any live run.

How will you migrate employee records and payroll history from our current HRIS?

A good answer describes a field mapping from the source system to the target, a data cleansing step, a load method and a reconciliation plan. For ERPNext, the Data Import tool loads CSV or Excel files and supports child table rows, but its documentation advises importing only a few thousand records at a time, so ask how batches are sequenced and checked. Request reconciliation reports that compare headcount, gross pay totals, leave balances and bank details between the old and new systems. Ask whether historical payslips are loaded into the new platform or archived in a readable form, and how the old system stays available for records retention after cutover. Confirm who owns data quality decisions and how long the parallel run lasts.

Does Odoo Enterprise include the payroll features we need?

Confirm this in writing before you choose an edition. Odoo Community is the open source core under LGPL-3.0, and Odoo Enterprise is built on it and adds features such as mobile apps, Studio customization, version upgrades and hosting. Enterprise source code is not publicly available and requires a subscription. Odoo's pricing page says only the Custom plan can be hosted on Odoo.sh or on-premise, and that only Custom includes multi-company, Studio, external API access and custom modules. Ask the partner to map each payroll requirement to a named edition and plan, and to quote the per-user subscription cost. Note that Community has no access to the upgrade service, so the licensing choice affects the upgrade path too.

Where will payroll data be hosted, and how are backups tested?

A good answer names the hosting location, such as your cloud account, a data center or an air-gapped network, and explains who has administrative access to the servers. Ask how databases and file attachments are backed up, how backups are encrypted in transit and at rest, and how long backups are kept so they match your payroll retention rules. Request the most recent restore test report, including the date and the time the restore took. For ERPNext, the frappe_docker project provides production images with MariaDB, Redis, workers, the scheduler and Nginx, while its single-file demo setup is marked for short-lived evaluation only. Ask the partner to confirm that no demo setup is used in production.

How do access controls and audit logs protect salary and bank data?

A good answer starts with a permission matrix that separates employee self-service, managers, HR staff and payroll administrators, and restricts salary and bank fields to the roles that need them. Ask how user accounts are created and removed, and whether logins can use your corporate directory. ERPNext has documented LDAP integration, and Odoo documents LDAP authentication, so ask which method applies to your setup and what happens to accounts when people leave. For ERPNext from version 15, Server Scripts are disabled by default and must be enabled, so ask whether they are enabled, who approves each script, and how changes are logged. Request a sample audit log and the schedule for access reviews.

How is support handled during a live payroll run?

A good answer defines a payroll calendar with a change freeze window, named contacts for each run, severity levels and written response targets. Ask for these terms in the contract rather than accepting general statements about availability. For ERPNext, Frappe's supported versions policy says customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. For Odoo, 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. Ask which party handles each issue type, and whether a separate retainer covers on-call support during runs.

What upgrade policy will apply to our HR and payroll platform?

A good answer names the version you will start on, its end-of-support date and the upgrade cadence the partner will follow. Odoo 20.0 was released in September 2026 with standard support planned until September 2029, and Odoo 17.0 standard support ended in September 2026, so confirm the version you will use. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. For ERPNext, version 14 reached end of life on January 31, 2026, version 15 is planned for support until the end of 2027, and version 16 until the end of 2029. Ask how each upgrade is tested on a database copy before production, who pays for it, and how payroll runs are protected during the change window. Odoo's upgrade documentation is a useful reference for the test process.

How to test payroll localization and migration claims

Payroll rules are country-specific, and a partner's general statement that it supports your countries is not evidence. Ask the partner to show how each rule in scope (gross-to-net calculation, employer and employee contributions, withholding tables, statutory leave, payslip content and year-end filings) is confirmed, and who signs off on it. A credible answer names your payroll provider or tax advisor as the source of truth, describes the test cases the partner runs against their written rule set, and states which rules remain your responsibility after go-live. Ask for a sample set of calculations for employees who exercise the edge cases in your workforce, such as mid-period joiners, unpaid leave, overtime and cross-border assignments, and compare the output with your current payroll results before accepting the localization claim. Because payroll changes each year, also ask how the partner receives and applies legislative updates, and whether that work is inside the fixed scope or sits under a retainer.

Migration claims are testable in the same way. Ask how the partner maps employee master data, leave balances and contract history from the current HRIS into the target fields, and request the mapping document with the transformation rules for each field, including how historical contract changes are represented. For bulk loading, the ERPNext Data Import documentation advises importing only a few thousand records at a time, so ask how the partner batches the load, validates each batch against record counts and checksums, and handles child table rows such as leave allocations. Then ask how they run parallel payroll before cutover: which pay periods are run in both systems, how the variances are reconciled, who approves the differences, and what the rollback point is. Confirm the timing and effort of each step in the written scope rather than accepting a general estimate.

Which partner answers should stop the shortlist

Partner answers reveal how a bidder will run payroll, hosting and support once the system is live. The cards below flag answers that should pause a shortlist, each paired with what to request instead. Use them to score written responses before any demonstration.

Guaranteed payroll accuracy without a method

A bid that promises payroll will be accurate, with no named validation approach, offers a result nobody can check. Ask for the parallel-run plan, the test cases for each pay element and tax rule, and who signs off each payroll cycle before go-live. A credible partner describes how variances are found and resolved, and who is accountable for the sign-off. Ask for the validation evidence from a previous rollout, with identifying details removed.

Edition and license terms left vague

If a bidder will not name the edition, its license or the features it depends on, the total cost and legal position stay unknown. For Odoo, the Community edition is licensed under LGPL-3.0 while Enterprise is a paid subscription with a closed source code base, and only the Custom plan can run on Odoo.sh or on-premise. Request a written list of the modules, editions and license terms each requirement needs, and confirm which features are gated.

Vendor access to production data without controls

Hosting proposals that give the vendor standing access to production payroll and employee records, with no logging or approval step, create a privacy and audit problem. Ask who can reach production, how access is approved and time-limited, how sessions are recorded, and where data is stored. Require that access is granted through named accounts with multi-factor authentication, and that every administrative action is logged and reviewable by the client.

No written backup and restore test

A bidder that describes backups without a restore test has not proven that payroll data can be recovered. Ask for the backup schedule, retention period, encryption method, the location of copies and a written restore procedure with a timed test on a copy of production data. Request the date of the last full restore test and the results. Backup coverage should include attachments and the scheduler and worker services.

Support unavailable during payroll runs

Support that is only staffed outside payroll windows leaves the team exposed on the days that matter most. Ask for the support hours, the escalation path for a failed payroll run, and the response targets written into the contract. Confirm whether the partner covers the payroll calendar, including month-end and off-cycle runs, and how it handles weekend or holiday incidents. Ask for the named engineer on call during each run.

Upgrades without a test database

Promises to upgrade the platform in place, with no test step, risk payroll rules and integrations breaking in production. Odoo's upgrade service moves a database to a newer version through an upgraded test copy that should be tested before production. Ask for the upgrade method, the test copy process, the regression test scope, the rollback plan and the support window for the current version. Confirm that payroll rules are included in regression testing.

How edition and hosting answers differ by option

Frappe HR runs on the Frappe Framework and is typically deployed as part of ERPNext or as a standalone app on a Frappe bench. Frappe Cloud is the managed hosting option from Frappe, and the pricing page lists shared site hosting from 5 US dollars per month and shared servers from 20 US dollars per month. Warranty coverage depends on running a listed version with a matching Frappe Cloud support plan, so the hosting decision and the support decision are linked. Ask partners to explain what runs in the Frappe Cloud tier you propose and how that tier affects your payroll logic.

Version eligibility: Confirm that the proposed ERPNext and Frappe version is on Frappe's supported versions list and that the matching support plan is part of the quote.
Server Scripts: From version 15, Server Scripts are disabled by default and must be enabled with server_script_enabled. Frappe Cloud public shared benches do not allow them, so payroll calculations written as server code need a dedicated bench.
Shared versus dedicated: Ask which hosting tier holds the payroll data and whether the proposed tier supports the custom logic in your scope.
Hosting cost recurrence: Hosting fees recur monthly and rise with tier, so ask for the hosting line item separated from implementation and support.
Partner recommendation: Ask the partner to state whether they recommend Frappe Cloud and why.

Check that the partner names the exact hosting tier, the support plan and the list of scripts or custom code that depends on it.

Which access and logging questions matter for payroll data

Payroll and HR records need role-based access, logging of user activity, and multi-factor authentication for every administrator. Ask each partner to show how those three controls are configured in the specific edition you plan to run, not only how they are described in general. The FTC Safeguards Rule at 16 CFR 314.4 sets similar expectations for covered financial institutions: encryption, multi-factor authentication for anyone accessing information systems, change management, and logging of authorized user activity. Confirm with your counsel whether that rule applies to your organization at all. Many employers are not covered financial institutions, so treat the rule as a benchmark for your own risk decision rather than a legal requirement for every HR system.

For authentication, ask how the partner configures LDAP or social login. ERPNext documents an LDAP integration and Frappe documents Social Login Key settings, and Odoo documents LDAP authentication, but the partner should show the directory attributes, group-to-role mapping, and what happens to an account when a directory user is disabled. Ask how break-glass administrator accounts are protected and whether multi-factor authentication is enforced at the identity provider or inside the application. Ask how Server Scripts are governed. From version 15, Frappe disables Server Scripts by default and they must be enabled with server_script_enabled, and Frappe Cloud public shared benches do not allow them. Require a written list of who may enable them, how changes are reviewed, and where that decision is logged.

Finally, ask how the partner tests access reviews. A credible answer names the reports exported for each role, the frequency agreed with your HR and IT owners, and a sample exercise in which the partner removes a leaver's access and proves it is gone from every module. Ask for the audit log retention period and where logs are stored, since logs that sit on the same server as the payroll database are weaker evidence. Confirm these details in a test environment before the production cutover.

How to score and compare written answers

This sequence turns a set of written RFP answers into a comparable shortlist, with each claim checked against evidence before a partner is asked for a fixed-scope proposal. It keeps the decision traceable so the team can explain why one bidder was preferred.

Send the question set in writing
Issue the same question set to every bidder at the same time, covering payroll localization for each country you run payroll in, data migration from the current HRIS, edition needs, hosting and backups, access controls, support during payroll runs and upgrade policy. Ask each bidder to answer in writing and to state which platform and version they would deploy. The output is a set of written answers that can be compared line by line, with the question set and the send date kept on file.
Require a named engineer for each area
Ask each bidder to name one engineer per area (payroll localization, data migration, hosting and backups, access controls, support and upgrades) who will answer follow-up questions and be accountable for that answer. Confirm that the named people are the ones who would do the work, not sales staff. Record names and roles next to each answer. The check is complete when every area has a named engineer and the bidder has confirmed that person will be on the delivery team.
Score answers against the good-answer criteria
Score each written answer against the criteria your team agreed before the responses arrived, such as whether the answer names the countries and pay rules covered, states how historical payroll data is mapped and reconciled, explains which edition features are needed and why, describes backup and restore tests, and states how payroll-run support is staffed. Use a simple scale, for example meets, partly meets or does not meet, and write one sentence of reasoning per score. The output is a scored matrix that a second reviewer can read and reproduce.
Record verified and asserted claims separately
Mark every claim in the answers as verified or asserted. A verified claim is one the team has confirmed with evidence, such as a reference the team has contacted, a test run in the demo, a published version or license, or a documented feature checked against the vendor's own documentation. An asserted claim is stated by the bidder without evidence yet. Keep the two lists apart so that a high score built only on asserted claims is visible to the decision makers. Confirm that the Odoo edition, licensing and support terms cited in answers match the vendor's published pages before scoring them as verified.
Run a scripted demo on anonymized data
Invite the shortlisted bidders to run the same short, scripted demo on anonymized employee and payroll data supplied by your team. The script should cover a new hire, a leave request with approval, a mid-cycle salary change, a leaver record, a payroll input export and an access review for an HR role and a manager role. Use anonymized data only, and check that the demo environment is separate from production. The output is a recorded pass or fail for each script step, with notes on anything done manually.
Compare demo results with the written scores
Compare each bidder's demo results with its written scores. Where a written answer said a capability exists and the demo could not show it, move that claim from the asserted list to the open list and ask the bidder for a written explanation. Where the demo showed a capability the written answer did not mention, note it as a strength to confirm. The output is an updated scorecard and a short list of open questions for each finalist.
Request a fixed-scope written proposal
Ask the remaining finalists for a fixed-scope written proposal. Most engagements are fixed-scope, so the proposal should set out the scope, deliverables and timelines in writing before any work starts, along with the named engineers, the assumptions behind the payroll localization and data migration work, and the cost components the bidder is charging for. Ask the bidder to state which costs are one-time and which recur, such as hosting, support and upgrades. The check is complete when the proposal can be compared against the scored matrix and the open questions have written answers.

How to score partner responses

This table sets out what each core area of an HR and payroll rollout should prove in a partner's answer, what evidence to expect, and which answers should end the evaluation. Weights are relative emphasis you set for your own organization, not fixed percentages, so rank the rows against your risks before you score. The main takeaway is that a vague answer on payroll localization, migration or support during payroll runs is more costly to fix later than a gap in the user interface.

Area	Weight guidance	Evidence required	Disqualifying answer
Payroll localization	Highest emphasis if you run payroll in several countries or states	Named statutory rules for each country, a test payslip set signed off by your payroll lead, and a list of payroll items that remain manual	Localization is described as included without a rule list, or the partner cannot name who maintains tax tables after go-live
Data migration	High emphasis if you are moving from an existing HRIS or payroll provider	Field mapping workbook, load method (for example, CSV or Excel imports with batch sizes), reconciliation totals and a parallel-run plan	No reconciliation step, or the partner assumes all history will be imported in one load
Edition and licensing	High emphasis if you need features that differ between community and paid editions	Written list of modules and features in each edition you will use, licensing terms, and the upgrade service entitlement for that edition	Edition needs are left open, or the partner proposes a paid edition without stating which features require it
Hosting and backups	High emphasis for employee data under data residency or sovereignty rules	Hosting location, backup frequency, tested restore results, encryption settings and who holds backup keys	Backups are described only as provider-managed, or restore has never been tested
Access controls	High emphasis where managers and HR roles see different records	Role matrix, MFA and identity integration design, audit logging of record access, and a plan for separating payroll administrators	Administrators have unrestricted payroll access with no logging, or no identity integration is proposed for a multi-user system
Payroll-run support	High emphasis if payroll runs on fixed calendar dates	Run calendar, named support hours around each run, a rollback procedure and a pre-run checklist with sign-off	Support is limited to ticket response times with no plan for run days or no rollback path
Upgrade policy	Medium to high emphasis for systems that will run for several years	Version support dates from the vendor, a test upgrade in a non-production copy, and a schedule that fits your payroll calendar	The partner plans upgrades without a test environment or says security patches are optional

What upgrade and support policy answers should show

Upgrade and support policy decides how much work the rollout creates after go-live, so a partner's answer should show the lifecycle of every version it proposes, not only the version it installs today. For Odoo, 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. Odoo 20.0 standard support runs to September 2029, and extended support afterwards is limited to Odoo.sh for select versions and on-premise, with security patches only during standard support. Odoo SaaS versions ship every two to three months and cannot use extended support. Ask the partner to state which Odoo edition and hosting model it assumes, whether that combination carries extended support, and what the plan is when standard support ends.

For ERPNext and the Frappe Framework, ask which major version is proposed and check it against the published support dates. Frappe lists version 15 as planned for support until the end of 2027 and version 16 until the end of 2029. Frappe's supported versions policy also ties warranty coverage to running a listed version with a matching Frappe Cloud support plan, so the partner should explain how that applies to a self-hosted deployment. Confirm the support model in writing rather than assuming the vendor covers it.

Ask partners how they schedule upgrades around payroll calendars, including which pay periods and statutory filing dates are protected and who approves a change window. Require a test on a copy of the production database before any upgrade, with the copy's data handling documented, and a written rollback plan that states how the database is restored and how long that takes. Ask for the names of the people who run and sign off each step, and what happens if a payroll run is due during a failed upgrade.

What buyers ask before hiring an HR implementation partner

Self-hosted HR software has fewer license lines than per-employee SaaS, but the costs move to other places. ERPNext and its HR modules are free under GPL-3.0, while Odoo Enterprise requires a subscription and Odoo's on-premise and Odoo.sh hosting is limited to its Custom plan. Hosting is a separate line. The ERPNext pricing page lists self-hosting as free and Frappe Cloud shared site hosting from 5 US dollars per month, so the infrastructure and operations cost depends on your cloud account, backups and staffing.

Licensing or subscription: Ask which parts recur, such as edition subscriptions, support plans and hosting, and which are one-time.
Hosting and backups: Ask who pays for servers, storage, backup tooling and the staff who restore them.
Localization and payroll setup: Country tax tables, statutory deductions and pay codes are usually the largest one-time block. Ask for them as a separate line.
Migration and integrations: Ask for the data mapping, import cycles and the identity and accounting connections as priced items.
Support and upgrades: Ask whether support is a retainer, what is included during a payroll run and what an upgrade costs each year.

For each line, ask the partner to state what drives it up or down and what it costs to change scope later.

The first payroll run depends less on installation than on settled pay rules, clean employee data and a parallel run against the current system. Each country or pay group needs its own rule set, and each rule needs test payslips that HR accepts. No duration is set in this page, so ask the partner for a dated plan rather than a generic estimate.

Data import limits: The ERPNext Data Import tool documentation advises importing only a few thousand records at a time, so large employee histories need batched loads and reconciliation checks.
Custom payroll logic: From version 15, Server Scripts are disabled by default and must be enabled with server_script_enabled, and Frappe Cloud public shared benches do not allow them. Confirm this early if your rules need custom code.
Test copies: Odoo documents database duplication with neutralization for test copies, which keeps personal data out of non-production systems. Confirm the same control for your chosen platform.
Parallel run: Ask how many pay cycles run in both systems and who signs off each variance.
Approval gates: Ask which milestones need written sign-off from HR, payroll and finance before go-live.

Ask the partner to show which items on the plan are on the critical path and which can run in parallel.

How DeployOpen scopes, delivers and supports HR platform evaluations

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source HR and payroll platforms inside your own infrastructure. We help evaluation teams turn RFP questions into a written scope with testable answers for payroll localization, migration, hosting, access control and upgrades before any platform is selected.

How we scope

Written scope lists the countries, pay rules, employee populations and integrations the platform must cover.
Each RFP question is turned into a testable requirement with an owner, evidence and an acceptance step.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Proof-of-concept builds test payroll calculations, leave rules and approvals against your sample data in your environment.
Migration trials load a representative extract from the current HRIS and reconcile record counts and balances.
Access model, encryption, backup and restore settings are configured and tested against the written requirements.

How we hand over

Handover covers architecture, configuration, runbooks, upgrade procedures and the evidence set for compliance reviews.
Documentation records which answers were verified in a test build and which must be confirmed with the vendor.
Your team receives walkthroughs for administrators, payroll operators and the people who will run the next upgrade.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
Support plans can be aligned to your payroll calendar so that changes avoid pay run windows.
Periodic testing and vendor release review keep the platform and its access controls current after handover.

HR and payroll software RFP questions