Accounting software RFP questions

Ownership sits with whoever signs the support or maintenance agreement, and it must be named in the contract before build starts. For Odoo, the localization packages come from the Odoo release line, so Community and Enterprise deployments depend on the edition and subscription you hold. For ERPNext, localization is delivered through the country-specific apps and the Frappe release line, so the question is which apps your version depends on and who patches them. Ask the vendor and the implementation partner to write down who reviews vendor localization updates, who tests them against your entities, and who approves them for production. Without a named owner, tax changes tend to be applied late or not at all.

Update cadence follows the release line you run, so ask for the exact schedule for your version rather than assuming one. Odoo's standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and SaaS versions are released every two to three months. ERPNext v15 and v16 both receive frequent minor releases, and Frappe's supported versions page lists v15 until the end of 2027 and v16 until the end of 2029. Ask how localization fixes are shipped (patch, minor or major), how long a release is tested in staging, and what happens when a major version reaches end of support during your tax filing cycle.

Custom tax rules should live in a written register that records the jurisdiction, the rate or logic, the accounts posted, the effective date, the approver and the test cases that prove the result. Ask whether the rules are configured through standard tax templates or through code, because code-based rules need change management, version control and a regression test set that runs before each upgrade. Request sample test ledgers that cover standard rates, exempt sales, reverse charge and any withholding you apply. Confirm that test results are kept as evidence, not only shown in a demo.

Ask for a written list of the statutory reports the localization generates for your country, including VAT or sales tax returns, withholding returns, and any ledger exports your tax authority requires. For each report, ask which version it was tested on, which fields it reads, and whether the output has been compared against a filed return from your own books. Coverage often differs between standard reports and reports that need a partner module, so the list should state which is which. Note that DeployOpen prepares systems and evidence for compliance work but does not issue filings or attestations, so the tax determination stays with your advisors.

Yes, most implementations start from a standard template and then map it to your reporting needs, but the template should be a starting point, not the final chart. Ask the partner which template they propose, how it maps to your statutory chart (for example, a national chart used for tax filing), and who approves changes to account numbers after posting begins. Confirm that account structure changes are controlled, because renumbering accounts with existing balances breaks comparatives and audit trails. Request the mapping file as a deliverable so your finance team can review it before go-live.

Costs fall into three groups: the software license or subscription, the partner fees for initial localization and configuration, and the recurring work to keep tax rules current. The license depends on edition. Odoo's pricing lists per-user monthly prices by plan and says only the Custom plan can be hosted on Odoo.sh or on-premise, while ERPNext self-hosting is free under GPL-3.0 with hosting and implementation priced separately. The recurring cost is the people who test and approve each tax change, whether internal or contracted. Ask for the maintenance scope in writing, including how many update cycles per year are covered and what is billed as extra work.

Accept localization only after your finance and tax team has run the same month of transactions through staging and compared results to the current system. Check invoice tax calculation for each rate and exemption, the posting of tax to the right accounts, the output of each statutory report, and the reconciliation of tax balances to the ledger. Ask the partner to provide the test script, the test data set and the signed results as part of the acceptance record. Repeat the same test after every major upgrade, since localization changes often arrive with the platform version.

Ask the bidder to state support hours in your time zone, including the hours covering your month-end and quarter-end close, and to confirm holiday coverage in the countries where your entities operate. Support hours are a contract term, not a marketing line, so the answer should name the coverage window, the days covered and the channels available outside those hours. Ask whether after-hours coverage exists for critical incidents only, and whether it is included in the subscription or billed separately. A partner that works from another region should show how it covers your business day without gaps.

Require written severity definitions that describe impact on the ledger, not only technical symptoms. A typical scheme separates a full outage or a posting failure during close from a degraded feature, a cosmetic defect and a general question. For each level, the contract should state the response target, the update frequency and who decides the severity when the customer and the partner disagree. Ask whether response targets are commitments or best-effort goals, and what credits or remedies apply when they are missed. Confirm these terms with the bidder in writing before signing, because published targets and contract terms often differ.

Ask the bidder to describe each escalation step, the role that owns it and the time it may take to move between steps. A clear path usually runs from a first-line service desk to implementation or platform engineers, then to a named technical lead who can change code, configuration or infrastructure. Ask who can approve a hotfix to a customization, who records the root cause and whether you receive a post-incident report. For a self-hosted Odoo or ERPNext deployment, also confirm whether engineers can access your database or logs, and under what change control they do so.

Support can come from the software vendor, from an implementation partner, or from both, and the contract must say which. Odoo's standard support on the Enterprise edition is a vendor entitlement, and Frappe warranty coverage for ERPNext depends on running a listed version with a matching Frappe Cloud support plan. Partner support is usually a separate retainer covering configuration, customizations, hosting and upgrades. Ask which party is accountable for each layer, what the subscription does not cover, and how the two agreements end or renew. Vendor and partner terms should be read together, since a gap between them is where incidents stall.

Expect exclusions for custom code, third-party integrations and data problems caused outside the platform, and ask the bidder to list them explicitly. Common exclusions include bugs in custom modules or Server Scripts, failures in bank feeds or payment connectors, problems caused by an unsupported version, and issues arising from changes made by your own staff. Ask whether the partner will still triage an excluded issue and bill it as time and materials, or refuse it. A clear exclusion list protects both sides and prevents disputes during a close.

Yes. Support commitments depend on the version you run, and both Odoo and Frappe publish support windows for each major release. Odoo standard support covers three years after a major release, and security patches are provided only during standard support. Frappe's supported versions page lists the end-of-life dates for each major version, and warranty coverage requires a listed version. Ask the bidder which version it will deploy, when standard support ends for that version, and what the upgrade plan and cost look like before that date.

Verify that the proposal names the support hours, severity definitions, escalation contacts, response targets and exclusions in one document that is part of the contract. Ask for a sample escalation record from a past incident, with the anonymized timeline, and confirm who on the bidder's team will hold each role. Check whether the commitments cover backups, restores and emergency patching, since these are often the incidents that matter most in a close. Ask what reports you will receive each month and who reviews them with you.

Many finance teams keep first-line questions in-house, such as user access, period settings and report formats, and send platform defects to the partner. This split works when the internal team has a named administrator, documented runbooks and access to the vendor's knowledge base. It fails when no one owns the database, the scheduler or the integrations. Ask the bidder to define which tasks the customer handles, which the partner handles, and what training it provides to the administrator. The division should appear in the contract so that responsibility is clear during an outage.

Custom code should live in version control, pass peer review and move through a test environment before production, using the same path as any other change. Ask each bidder to describe its branching model, who approves merges, how deployments are recorded and how a rollback works. For Odoo, custom modules are only available on the Custom plan per the pricing page, so confirm the edition before design starts. For ERPNext, custom apps are built on the Frappe framework and should be deployed through the same build and release steps as the core. Ask for the change log as an audit artifact, because auditors will sample it.

Confirm this before design, because server-side logic depends on it. Per the Frappe documentation, Server Scripts run Python on document events or as API endpoints, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them, so a shared-hosted plan may rule out this design entirely. Ask the bidder to state the setting value in each environment, who can change it, and whether scripts are reviewed in the same way as application code. Where logic is complex, ask whether it should instead be built as a versioned app.

Identity integration should be configured centrally, with access granted through directory groups rather than local accounts. Both Odoo and ERPNext document LDAP integration, and Frappe documents Social Login Key configuration. Ask the bidder which method it will use, how group-to-role mapping is maintained, how leavers are removed, and whether local administrator accounts remain available for break-glass use. Confirm that the directory and the accounting platform versions in your environment are supported together. Ask for the configuration as a documented, reviewed artifact that your access review can test.

Test them with representative data in a non-production copy, then verify that each transaction lands in the right account, currency and period. Ask the bidder to show a test plan that covers matching rules, duplicate detection, failed-connection handling and reconciliation totals against the bank statement. Use a sanitized database copy so no live credentials or customer data move into test. Ask who holds the connector credentials, where they are stored and how they rotate. Confirm which bank or processor connectors are supported in your region, because connector availability varies and is not something to assume.

The cost is mostly internal and partner time spent on specification, testing, review and documentation, plus any licensing needed for the extension model you choose. A partner quote should show these as separate line items, so you can see what is one-time build work and what recurs, such as regression testing after each platform upgrade. Costs rise with the number of custom objects, integrations and entities, and with the number of platform releases you must absorb. Ask for the testing and documentation effort explicitly, and for an estimate of effort for each upgrade cycle rather than only the initial build.

Every upgrade can change behavior that custom code depends on, so each customization needs a regression test before the upgraded copy goes live. Odoo's upgrade service produces an upgraded test database that should be tested before production, and on Odoo Online and Odoo.sh major upgrades are mandatory every two years according to its documentation. Frappe's supported versions page lists version 15 supported until the end of 2027 and version 16 until the end of 2029, so plan the upgrade window against those dates. Ask the bidder for its upgrade test list, who signs it off, and how it keeps a record of each test run.

Your organization should own the credentials and the change records, and the partner should work with access that is granted, logged and revoked on a defined schedule. Ask who holds administrator and API keys, where secrets are stored, how they are rotated and whether a named individual on your side approves each production change. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to adopt change management procedures and to log the activity of authorized users, so these records should be designed in from the start. Ask the bidder to show a sample change record and an access log export before signing.