Accounting software requirements checklist: how to use it before you shortlist Odoo, ERPNext or LedgerSMB
Use the checklist to fix your requirements before you look at any product, then shortlist only the platforms that can meet them. A finance or IT leader choosing a self-hosted ledger needs a written answer to each requirement: which legal entities and currencies the books must cover, which tax and localization rules apply, how invoices will be issued and received, how bank feeds reconcile, who approves what, what the audit trail must show, which reports leadership needs, and which systems must connect. Each line needs two things before the shortlist is final: a verification step (a demo script, a test with a copy of your data, a written answer from the vendor or partner, or a check against your own regulator's guidance) and a named owner in finance, tax, IT or security who signs off on the result.
The list is platform-neutral by design. It applies equally to Odoo, ERPNext, LedgerSMB or any other candidate, and it does not assume that any one of them is the right fit. The license, the edition and the support terms often decide what is possible before features are compared. For example, the Odoo Community and Enterprise editions differ in what is open source and what requires a subscription, and the support windows for each Odoo major version are defined in the vendor's support documentation, so confirm them against the version you intend to run. For ERPNext, confirm which major versions are currently supported and what Frappe Cloud support is needed for warranty coverage. Record each candidate's license, edition, support dates and hosting responsibilities in the same table as your requirements, so that a gap found in week one does not surface in the last month of procurement.
Functional requirements to verify for the general ledger
This table lists the general ledger requirements to settle before choosing self-hosted accounting software, with why each matters and how to verify it. Use the verification column to decide between a demo with your own data, a reference configuration from a comparable entity, or written vendor confirmation. Treat any requirement that depends on a plan, edition or country as unconfirmed until the vendor or partner shows it in writing.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Entities and currencies | Each legal entity needs its own books, base currency and fiscal calendar, and some platforms split these only on higher tiers. | Demo with your entity list and currencies; for Odoo, confirm multi-company is included in the Custom plan per the pricing page. |
| Chart of accounts | Group reporting depends on consistent account structures across entities, and a mismatched chart forces manual mapping at close. | Load your real chart into a test database and run a trial balance with a sample period. |
| Localization and tax | Tax codes, filing reports and statutory charts differ by country, and a missing localization becomes manual work every period. | Ask for the localization list for each country you operate in; for ERPNext, confirm coverage per country before shortlisting. |
| E-invoicing | Mandated structured invoice formats and transmission networks vary by jurisdiction and may require connection to a network or access point. | Send a test invoice in each required format and confirm the platform can receive and validate responses; get written confirmation of supported formats. |
| Bank feeds and reconciliation | Matching bank statements to ledger entries is a daily control, and weak matching shifts effort to finance staff. | Import a month of your actual bank files and measure the share matched automatically versus manually. |
| Approval workflows | Segregation of duties and payment controls depend on who can post, approve and release entries, and on whether rules are enforced by the system. | Configure your approval matrix in a test environment and attempt a prohibited action with a restricted user. |
| Audit trail and posted entry controls | Assessors look for who changed what and when, and whether posted entries can be altered or deleted without a trace. | Edit and delete a posted entry as a test user, then confirm the change log captures the original values and the actor. |
| Reporting | Statutory, management and consolidated reports must reproduce from the ledger without manual reconciliation. | Produce your trial balance, aged receivables and one consolidated view from the test data and compare to a reference you already trust. |
| Customizations and Studio | Custom fields, reports and workflows often sit outside standard support, so they affect upgrades and change control. Odoo Studio is listed in the Custom plan. | Ask the vendor which customizations are supported across upgrades and request the upgrade test plan in writing. |
How entity count, tax and currency decide the platform shortlist
Before comparing features, count the legal entities, tax jurisdictions and functional currencies the ledger must serve. These three numbers narrow the candidates faster than any feature list. Odoo's pricing page places multi-company support, along with Odoo Studio, external API access and custom modules, only in the Custom plan, so a group that needs several companies in one database should confirm the edition before it shortlists Odoo at all. ERPNext and Odoo both need each entity to carry its own company record, default currency, chart of accounts and tax templates. Write the entity list down with the country, tax regime, reporting currency and fiscal year end for each one, then ask every candidate to show how those attributes are configured in a test database.
Intercompany needs decide whether one instance or several is the right design. If entities trade with each other and must eliminate balances at group close, the platform must post mirrored entries across companies, hold intercompany accounts and support consolidated reporting from the same data. If the entities are independent, separate instances reduce the blast radius of a change, a failed upgrade or a bad configuration, and they simplify access reviews. Separate instances also mean separate upgrade cycles and duplicate localization effort. Ask each vendor to demonstrate an intercompany invoice that posts on both sides, and confirm whether the consolidation output is produced natively or through an export. Treat the answer as a design input, not a marketing claim.
Tax and currency settings are where localization packs matter most. Each jurisdiction needs its own tax codes, rates, reporting forms and rounding rules, and some countries require specific invoice numbering or fiscal certification that a generic module does not cover. Localization coverage differs by vendor and by version, so confirm each country pack, its support status and which forms it generates with the vendor or implementation partner in writing. For currency, confirm how the platform stores transaction currency alongside the functional currency, how it revalues open items at period end, and which exchange rate source it uses. Record the answers in the requirements checklist so that a later edition or version change does not silently remove a country or currency you depend on.
Security requirements the platform and hosting must meet
Accounting systems that hold customer financial data or broker-dealer records are judged on controls, not features. The cards below cover the controls that regulators and auditors ask about most often, and each one names a decision to make before the platform is chosen. Confirm every item against the specific edition, version and hosting model you plan to deploy.
Encryption in transit and at rest
The FTC Safeguards Rule at 16 CFR 314.4 expects covered financial institutions to encrypt customer information moving over external networks and stored on disk. For a self-hosted ledger, that means TLS on every user and API path, encrypted database volumes, encrypted backups, and managed keys with a rotation owner. Ask the implementation partner who holds the keys and where they are stored. Confirm the database and backup encryption options for your chosen version, since these are set by your hosting design rather than by the application alone.
MFA for every system user
The same rule requires multi-factor authentication for any individual accessing any information system, which includes finance staff, administrators, support partners and service accounts with interactive access. Decide whether the application enforces MFA itself or whether it sits behind an identity provider. Odoo and ERPNext both document LDAP integration, and ERPNext documents social login keys, but whether either supports your MFA method and enforcement policy must be confirmed for the target setup. Document exceptions for break-glass accounts.
Logging of authorized user activity
The Safeguards Rule requires covered institutions to log the activity of authorized users, so that postings, approvals, user changes and exports can be traced to a person. Plan which events are captured by the application, which are captured at the database and operating system level, and where logs are shipped and retained. Confirm whether the chosen platform records field-level changes to posted entries, and whether log integrity can be protected from the administrators whose actions are being recorded.
Change management for customizations
The Safeguards Rule calls for change management procedures. In accounting systems, custom fields, server scripts, workflows and upgrades can change how balances are calculated, so each change needs a request, a test copy, an approver and a rollback path. ERPNext server scripts are disabled by default from version 15 and must be enabled explicitly, which makes that setting a governance decision. Ask the partner how customizations are version-controlled and how the production database is protected during upgrades.
Penetration testing and vulnerability cadence
16 CFR 314.4 requires annual penetration testing and vulnerability assessments at least every six months, unless the institution has effective continuous monitoring. Plan the testing scope to include the accounting application, its APIs, the hosting layer and the bank feed or payment connectors. Confirm that the platform version is still receiving security fixes, because unsupported versions cannot be patched through standard channels. Agree on who remediates findings and how retests are evidenced.
Records retention for broker-dealers
For broker-dealers, 17 CFR 240.17a-4 requires preserving records such as bills receivable or payable and bank statements for at least three years, with the first two in an easily accessible place. Accounting platforms that hold these records need retention rules, backup restore tests and read access that outlasts a version upgrade or a hosting change. Confirm with counsel whether your records fall under this rule, and ask the partner how archived databases stay readable after the application is upgraded.
Which license and edition terms change what you can build
License and edition terms decide what you can change, where you can run it and what you pay for after go-live, so settle them before you compare features. Odoo Community is published under the GNU LGPL version 3, which permits modification and use of the core, but the licensed Odoo Enterprise edition is built on top of it and its source code is not publicly available. Enterprise requires a subscription or partner access. The published pricing page places multi-company, Odoo Studio, external API access and custom modules in the Custom plan, and states that only Custom can be hosted on Odoo.sh or on-premise. If your design needs any of those features, your self-hosted build depends on a commercial edition whose terms you must read yourself, not on the open source license alone.
ERPNext is licensed under GPL-3.0, and the Frappe Framework it runs on is licensed under MIT. The two licenses carry different obligations. GPL-3.0 has copyleft conditions that may matter if you distribute modified ERPNext code outside your organization, while MIT is permissive. Confirm with counsel how custom apps you build on Frappe will be licensed and whether any of them will be distributed to subsidiaries, partners or vendors. Also confirm which Frappe support plan, if any, your version requires, because the supported versions policy ties warranty coverage to a listed version and a matching Frappe Cloud support plan.
Ask each candidate for its license and edition terms in writing, covering the features you need, hosting rights, upgrade and extended support eligibility, and who may access the source. Odoo's standard support covers a major release for three years, and Odoo describes Enterprise upgrades and on-premise use as tied to a subscription, so a upgrade plan belongs in the quote. Have counsel review the terms before you commit, especially the clauses on modification, redistribution, hosting by third parties and termination. Treat any verbal answer from a sales contact as unconfirmed until it appears in the contract or the vendor's published documentation.
Operational requirements: upgrades, support, backups and environments
This table compares what each self-hosted candidate commits to on upgrades, version support, test copies, backups and support contracts. Use it as a checklist: for each row, ask the vendor or partner for the written answer and the evidence that proves it before you shortlist a platform.
| Requirement | Odoo (Community and Enterprise) | ERPNext on Frappe |
|---|---|---|
| Version support window | Standard support covers three years after a major release on Online, Odoo.sh and on-premise. Odoo 20.0 standard support runs to September 2029; 19.0 to September 2028; 18.0 to September 2027 | Version 14 reached end of life on January 31, 2026. Version 15 is planned for support to the end of 2027, and version 16 to the end of 2029 |
| Mandatory major upgrades | Online and Odoo.sh require a major upgrade every two years. Confirm the schedule for on-premise, which is your responsibility to plan | No forced cadence in the supplied facts. Confirm which supported version you will run and the date it leaves support |
| Release cadence | Odoo SaaS versions ship every two to three months and cannot use extended support. Confirm how often on-premise patches are issued | Both supported major versions receive frequent minor releases, for example v16.51.1 on October 15, 2026 and v15.123.0 on October 14, 2026 |
| Upgrade path and tooling | Upgrade service migrates a database to a newer supported version via a test copy. On-premise use requires an Enterprise subscription; Community has no access | Upgrades run through the bench tooling or Docker images. Ask for the written migration steps, rollback plan and any custom app compatibility checks |
| Test environment with neutralized copy | Database duplication with neutralization creates test copies. Verify that outgoing emails, payment and bank connectors are disabled in the copy | Confirm a sandbox site with production data is refreshed under a documented process and that external integrations are disconnected |
| Backup and restore testing | Ask for backup frequency, retention, encryption and a restore test record with timed results for the database and filestore | Ask for database and file backup schedules, off-site copies and a restore test with a timestamp and reconciled ledger balances |
| Support hours and escalation | Standard support is tied to the version and hosting model. Confirm response windows, time zones and severity definitions in writing | Warranty coverage depends on a matching support plan. Confirm response windows, time zones and severity definitions in writing |
| Who holds the warranty or support contract | The Enterprise subscription and hosting choice set support rights. Confirm whether your partner or Odoo holds the contract | Frappe warranty requires a listed version and a matching Frappe Cloud support plan. Confirm which party is the contracted support entity for self-hosted sites |
How to run the requirements review in sequence
This sequence turns a loose list of accounting needs into a scored, evidenced decision that finance, audit and IT can all sign. Each step produces an artifact the next step depends on, so the choice of Odoo, ERPNext, LedgerSMB or another candidate rests on tested behavior rather than vendor claims.
Assemble finance, audit and IT owners
Name one accountable owner each for the general ledger, tax and localization, audit evidence, and IT operations, and add the controller who signs month-end close. Include the external auditor's contact if the audit firm has already been appointed. The step is done when each owner has a written scope of what they approve, and when the group agrees which entities, currencies and reporting calendars are in scope for the first release.
Write requirements with acceptance tests
Turn each requirement into a testable statement with a pass or fail condition, covering entities and currencies, localization and tax, e-invoicing, bank feeds and reconciliation, approval workflows, audit trail, reporting and integrations. For example, an illustrative test might state that a posted journal entry cannot be edited and that its reversal shows the original user and timestamp. The output is a requirements register where every line has an owner and an acceptance test.
Score candidates against a scripted demo
Give each candidate the same script and the same sample dataset, including multi-currency invoices, a bank statement with partial matches and an approval chain with a rejection. Score each requirement as met, met with configuration, met with customization or not met, and record what was actually run. The step is complete when every candidate has a scored sheet that a second reviewer has checked against the recorded demo.
Confirm license and support terms in writing
Ask each vendor or implementation partner to confirm in writing which features sit in the community or free edition and which require a paid edition, plan or subscription. Confirm the support window for the release you intend to run, upgrade and security patch coverage, and whether hosting, backups and database access are included or your responsibility. Check the license text itself for the candidate, such as LGPL-3.0 for Odoo Community or GPL-3.0 for ERPNext. The output is a terms summary that procurement and legal have reviewed.
Run a proof of concept on a test copy
Build the shortlisted configuration on a test copy of the environment, using anonymized or masked data rather than production records. Run the acceptance tests from the register, plus a restore of the database from backup and a sample upgrade or patch to confirm the upgrade path behaves as documented. The step closes when every critical requirement has a recorded pass, and any gaps are logged with a named owner and a decision on customization or process change.
Sign off with the auditor's evidence needs
Walk the proof of concept with the external auditor and the internal audit lead, and ask which system reports, access reviews, change records and audit trail extracts they will request in the first close. Map each request to a configured control and an evidence owner, and note where a retained report must be produced on demand. DeployOpen can prepare systems and evidence for compliance assessments, but the auditor issues the opinion. The sequence ends when the controller, CIO and auditor have signed the requirements register and the evidence map.
Questions buyers ask before choosing accounting software
How much effort does a requirements review take, and who does it?
The review is mostly finance and IT time, with an implementation partner usually leading the structure and the technical questions. Effort rises with the number of legal entities, currencies, tax jurisdictions, bank connections and integrations you need to cover. Your finance team owns the answers on chart of accounts, approvals and reporting, while IT owns hosting, identity, backups and integration constraints. Ask any partner for a written scope that lists the deliverables and the people each one needs from your side, and confirm whether the review is a fixed-scope piece of work or part of a larger engagement. Licenses for ERPNext are free to download and run, so the cost of the review is effort, not software.
How long does choosing accounting software take, and what drives the timeline?
Selection time is driven by how many candidates you test, how many stakeholders must sign off, and how settled your entity and tax structure is. A single-entity business with one currency and standard bank feeds can narrow the field quickly. A group with several entities, mixed tax regimes and e-invoicing duties needs more time for demonstrations, data samples and legal review. Odoo and ERPNext both release on fast cycles, so confirm the exact version you will evaluate and its support window before committing. Ask a partner to state the selection milestones and the decisions that gate each one in the written scope.
Can our internal team write the requirements checklist alone?
Yes, a capable internal team can write the checklist alone if it includes finance operations, tax, IT and the people who will approve and close the books. The checklist is a list of decisions, not a technical design, so internal staff often know the answers better than an outside party. An outside reviewer adds value by testing the list against each candidate's edition, licensing and localization, and by spotting gaps such as missing audit trail or upgrade requirements. If you do the work internally, have someone outside finance check the list against your regulator and auditor expectations before you send it to vendors.
What does the work need from finance and IT?
Finance supplies the chart of accounts, approval thresholds, close calendar, reporting packs, tax filings and the list of bank accounts and payment channels. IT supplies the hosting target, network and identity constraints, backup and retention rules, and the list of systems the ledger must talk to. Both teams should agree who signs off on the license terms, because the choice between Odoo Community, Odoo Enterprise and ERPNext changes who must be contacted for support and upgrades. Keep a short register of open questions with an owner and a due date, since most delays come from unanswered questions about entities or tax rather than from the software itself.
Is a SaaS accounting tool a better fit than self-hosting?
A SaaS accounting tool is often the better fit when you have one entity, a standard tax setup, no custom approval workflows and no requirement to keep data in a specific location. Self-hosting makes more sense when you need control over data residency, custom workflows, multi-company structures or integrations that a SaaS plan does not offer. Odoo states that only its Custom plan can be hosted on Odoo.sh or on-premise, and that multi-company and external API access sit in that plan, so check the plan that matches your requirements. Compare total ownership over the period you plan to run the system, including hosting, upgrades, support and internal time, not only the subscription line.
How do we compare Odoo, ERPNext and LedgerSMB fairly?
Score each candidate against the same requirement list, using the same sample data, and record the edition, license and support terms that apply to your intended use. Odoo Community is LGPL-3.0 licensed, Odoo Enterprise adds features and requires a subscription for on-premise use, and ERPNext is GPL-3.0 licensed with a free self-hosting option. Check the support window for each version, the upgrade path, and whether the features you need sit in the free or paid edition. Run the same bank feed, e-invoice and approval scenarios on each platform, and ask each vendor or partner to show the evidence rather than describe it. Avoid choosing on a single demonstration, because a sales demo rarely reveals localization gaps or upgrade effort.
What should we confirm about support and upgrades before signing?
Confirm how long the version you choose receives security updates, what extended support exists, and who carries the upgrade work. For Odoo, standard support covers three years after a major release on Odoo Online, Odoo.sh and on-premise, and extended support is limited to Odoo.sh for select versions and on-premise, so check which version your target sits in. For ERPNext, Frappe's supported versions page lists end-of-life dates, and warranty coverage requires a listed version and a matching Frappe Cloud support plan. Ask any partner for its own support hours, response commitments and which upgrades are included in the fixed scope, and put those terms in writing.
How DeployOpen scopes and delivers accounting platform selection and implementation
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For an accounting platform, that means the requirements in this checklist (entities, currencies, tax localization, e-invoicing, bank feeds, approval workflows, audit trail, reporting and integrations) become a written scope before any software is configured. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, so the decisions you settle on this checklist become the basis of the agreement rather than assumptions discovered later.
Quotes follow from that written scope. DeployOpen does not publish a price list, so the reader should expect a proposal that itemizes the platform work, localization and tax configuration, data migration, integrations, hardening, backup design and training as separate lines. When requesting a quote, ask which items are one-time and which recur, who holds the licenses and subscriptions (for Odoo Enterprise or ERPNext hosting, for example), and which upgrade, support and testing tasks are excluded. Ongoing support, upgrades and continuous testing are available as retainers, which suits the recurring work described in the sibling sections on upgrades, change control and evidence.
On compliance, DeployOpen prepares systems, controls and evidence for assessments such as internal audit, SOX IT general controls or a German GoBD review, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those roles. The practical step is to ask any implementation partner, DeployOpen included, to show which evidence will be produced, where it is stored, who owns it and how it is refreshed each quarter. DeployOpen also runs security testing of applications, APIs and infrastructure, which can be scoped alongside the accounting rollout if the ledger holds regulated financial records.
