When an Odoo Accounting implementation starts and who should own it
A finance team usually reaches this point when the general ledger has to move into Odoo, often alongside a platform change, a new legal entity or a retirement of an older accounting tool. Odoo Accounting is the ledger that other apps post into, so its setup decisions are hard to reverse. Sales, purchasing, inventory, point of sale and payroll all generate journal entries, and once those entries carry a wrong account, tax mapping or journal structure, correcting them means reversing postings across several apps and periods. This page covers the work that turns a blank Odoo database into a working ledger: choosing and applying the fiscal localization package for your country, designing the chart of accounts, setting up journals, taxes and fiscal positions, configuring bank reconciliation and payment follow-up, and planning the first year-end closing. It also explains where Community Invoicing ends and full Accounting begins, because that boundary affects which of these steps are available to you at all. Each step depends on the one before it, so the order matters as much as the content.
On the client side, the finance function usually leads the project. The financial controller or accounting manager owns the chart of accounts, tax treatment and closing calendar, since those choices determine how the statutory and management reports will look. IT owns the hosting environment, identity integration, backups and access to the database, and it should be involved early because the hosting model decides which Odoo features and support windows apply. Someone with authority over both groups should sign off the design before build starts.
The decision to bring in an implementation partner is usually made before the chart of accounts is drafted, and for good reason. A chart of accounts drafted in a spreadsheet without knowledge of how Odoo's fiscal localization, default accounts and tax groups interact often needs rework once the first invoices post. A partner is most useful at the design stage, when the team needs to test how a proposed structure behaves in a non-production database, not after the first month-end has exposed the gaps.
Before the first design workshop, confirm which edition and hosting type you are licensing, since the pricing page ties hosting on Odoo.sh or on-premise to the Custom plan and the Enterprise source code is not public. Confirm with Odoo which accounting features your chosen plan includes, and confirm the Odoo version and its support window, because standard support covers a fixed period after each major release. Ask finance to list the entities, currencies, tax regimes and reporting obligations in scope. These answers set the boundaries for everything that follows and are the inputs a partner will need to scope the work in writing.
What Odoo Accounting does, according to the platform
Odoo is a suite of open source business applications, built on Python and PostgreSQL, and Accounting is one of those applications. The six capabilities below are the ones the platform documents for Accounting, so check each detail against the documentation for the version you run.
General ledger as the core
Odoo documents the general ledger as the core of Accounting, where accounting entries are posted and balances are kept. For an implementation, the chart of accounts and the fiscal localization package determine how every later journal, tax and report behaves, so both belong in the first design workshop. Confirm with the documentation for your version which accounts and account types the localization creates and which your finance team must define.
Journals that group entries
Journals group the entries that Accounting posts, such as sales, purchases, bank, cash and miscellaneous operations. Each journal carries settings such as default accounts and numbering, so the number of journals and the people allowed to post to each one are design decisions to settle before go-live. Check in the documentation for your version which journal types exist and how their sequences are configured.
Taxes and fiscal positions
Taxes define how Accounting calculates and reports tax on sales and purchases. Fiscal positions remap taxes and accounts for customers or suppliers in a different tax situation, such as an exempt buyer. The tax set and its mapping should be agreed with your tax adviser before configuration begins. Confirm which tax packages the localization for your country provides and which you must build yourself.
Bank reconciliation with statements
Bank reconciliation matches bank statement lines to the payments and invoices in Accounting, so the ledger agrees with the bank. Matching rules, bank journals and the method used to bring in statements determine how much manual work the team keeps after go-live. Confirm which statement import formats and synchronization options apply to your edition and country, because these depend on the version and the location of the bank.
Payment follow-up for overdue invoices
Payment follow-up identifies overdue customer invoices and sends reminders on a defined schedule. Reminder levels, message templates and the approval step before escalation to collection are business decisions that the implementation must record before configuration. Confirm in the documentation for your version whether follow-up is included in your edition or delivered through another application.
Financial reporting from the ledger
Accounting reports are generated from the posted entries in the ledger, including country-specific reports where the localization provides them. Report layouts, comparison periods and access rights should be tested against the figures your finance team already signs off at period close. Confirm which standard and country reports ship with the version you run, and how custom reports are built and maintained.
Invoicing in Community and full Accounting: what changes for finance
Finance leaders need to know early which Odoo edition their accounting will run on, because the answer decides what the ledger can do, who maintains it and how much of the project depends on a vendor. Odoo offers a Community edition under the LGPL-3.0 license, and a paid Enterprise edition that adds features and support. The Enterprise source code is not publicly available and requires a subscription or partner access. Community Invoicing covers customer and vendor invoices and payments, but the full Accounting app, with its reporting, closing and related controls, is a separate decision that the team should make on paper before the build starts.
Many teams start with Invoicing because it is quick to put in front of users, then find that they need full Accounting once they must produce financial statements, reconcile bank activity at scale, manage tax reporting or close a fiscal year. The switch is not only a matter of turning on an app. It changes which journals, reports and closing steps the finance team uses, how period locks are applied, and whether the reports they hand to auditors come from the general ledger or from a subset of documents. Plan a test of the reports and the year-end close in a non-production copy before anyone relies on the switched system.
Confirm three things for your version and plan. First, which accounting features are included in Community Invoicing and which require Enterprise, since Odoo's feature split changes between releases. Second, which subscription or plan you need for the apps and hosting you intend to use. Odoo's pricing page places multi-company, 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 entities, bank feeds or reporting tools depend on any of these, the plan choice is a finance decision as well as an IT one.
The edition also decides who can run the project. On Community, your team or a partner maintains the code, the upgrade path and the fixes, and Odoo's upgrade service is not available to you. On Enterprise, the upgrade service and standard support apply, but they run on Odoo's support windows, and security patches are provided only during standard support. Ask in writing who will apply upgrades to the accounting modules, how long each version receives standard support, and who owns the data migration if the edition changes.
Configuration decisions to settle before the chart of accounts is built
This table lists the decisions that shape the Odoo Accounting ledger, the question that settles each one, and the options that fit different organizations. Read each row before the chart of accounts work starts, because later changes to these settings usually mean reworking posted data. Settle the fiscal localization, company structure and tax model first, since the other rows depend on them.
| Decision | Options | Deciding question | When each option fits |
|---|---|---|---|
| Fiscal localization package and country | Install the country localization for the legal entity's country, or run a generic chart without one | Which country's tax reporting and statutory account rules apply to each legal entity? | A localization fits when returns, tax codes and mandated reports for that country must come from Odoo. A generic setup fits only where no local statutory reporting is needed, and the team should confirm this with its tax adviser. |
| Chart of accounts structure | Start from the localization template and extend it, or build a custom chart from scratch | How many account levels, reporting groups and analytic dimensions do finance and management reporting need? | Extending the template fits most organizations because statutory accounts are already present. A custom chart fits when the group reporting structure differs strongly from the local template and the team can maintain the mapping. |
| Single company or multi-company | One company record, or several companies in one database with separate ledgers | Does each legal entity need its own ledger, bank accounts, tax filings and intercompany postings? | A single company fits one legal entity. Multi-company fits groups where each entity files separately and intercompany flows must be recorded. Multi-company is a feature in the Custom plan per Odoo's pricing page, so confirm the plan before choosing it. |
| Tax model and fiscal positions | Taxes on products and accounts, with fiscal positions remapping taxes and accounts for specific customers or regions | Which sales and purchase taxes apply by product, customer type and destination, and where do exemptions or reverse charge apply? | Plain tax rates fit single-jurisdiction sellers. Fiscal positions fit cross-border sales, exempt customers or reverse-charge purchasing, where a remap rule is easier to maintain than duplicate products. |
| Journal design for bank and payments | One journal per bank account and payment method, or grouped journals by currency or entity | How many bank accounts, currencies, card or payment providers and cash points post to the ledger, and who reconciles each one? | One journal per bank account fits most teams and keeps reconciliation clear. Grouping fits high volumes of similar accounts where the reconciliation owner is the same. Payment providers usually need their own journals to separate clearing from bank balances. |
| Reconciliation rules | Manual matching, automatic matching by reference and amount, or a combination with approved write-off accounts | What share of bank lines carry references that match invoices, and who approves differences and write-offs? | Manual matching fits low volume or inconsistent references. Automatic rules fit repeatable payment patterns. Write-off accounts and approval rules should be set before go-live so differences do not accumulate in suspense accounts. |
| Year-end closing ownership | Finance controller owns the closing checklist in Odoo, or an external accountant performs it from exported data | Who locks periods, posts closing entries, approves the opening balances and signs off the statutory accounts? | Internal ownership fits organizations with an in-house close team that works in the database. External ownership fits small teams where the accountant needs controlled access. Either way, the owner and lock dates should be written down before the first closing. |
How an Odoo Accounting rollout runs, step by step
The sequence moves from edition and hosting decisions to a signed chart of accounts, a reconciled test period and a live ledger with a closing calendar. Each step closes with a named deliverable that the finance owner approves before the next step starts.
Confirm edition, hosting and fiscal localization
Your team and DeployOpen confirm which Odoo edition, hosting type and version the accounting work will run on, and which fiscal localization package matches the entity's country. Odoo Online, Odoo.sh and on-premise each carry different plan requirements, and Odoo's pricing page places Odoo.sh and on-premise hosting under the Custom plan, so this choice must be made before any configuration starts. The version sets the standard support window, which should be checked against the planned go-live date. The localization package is installed on a test database first. The deliverable is a written scope note that states edition, hosting, version, support end date and localization package, signed by the finance and IT owners.
Design the chart of accounts and taxes
Finance and DeployOpen review the localized chart of accounts against the entity's statutory reporting lines, management reporting needs and the tax rates it charges and reclaims. Accounts are grouped, account types and reconciliation flags are set, and tax groups and rates are defined with their default accounts. The mapping from the prior ledger is recorded account by account so that no balance is left without a destination. Decisions on account types and default tax accounts are made here because later changes affect posted history. The deliverable is a signed-off chart of accounts and tax matrix, with the controller's approval recorded before any journal is built.
Configure journals and fiscal positions
Journals are created for sales, purchases, bank, cash and miscellaneous entries, each with its sequence, default accounts and posting rules. Fiscal positions remap taxes and accounts for partners in other tax treatments, such as exempt or cross-border sales, and are linked to the partner records that need them. Sample customer invoices, vendor bills and payments are posted on the test database to confirm that each path produces the entries the controller expects. The step is complete when a scripted set of transactions produces the agreed journal entries and the journal and fiscal position map is documented.
Set up bank feeds and reconciliation
Each bank account is linked to its journal, and statement import or bank feed connection is set up using the method your bank and country support. Feed availability varies by provider and region, so confirm the supported connection for your bank and Odoo version before committing to a design. Reconciliation models are configured for recurring items such as bank fees and card settlements, and matching rules are tested against a sample of statement lines from your bank. The deliverable is a reconciled test period, with every unmatched line listed and its treatment explained by the finance team.
Configure payment follow-up levels
Credit control defines the follow-up levels, the number of days overdue that trigger each level, the email or letter templates used at each level and the customers excluded from automated follow-up, such as those on approved payment plans. Templates are tested on the test database, including how they render on invoices in each currency the entity uses. The team also records who sends each level and who approves exceptions. The deliverable is an approved follow-up policy and tested templates, and the step is complete when a test customer moves through every level as the policy describes.
Load opening balances and reconcile to the prior ledger
Opening balances are loaded as a dated entry or set of entries at the cut-over date, using the trial balance from the prior ledger as the source. Total debits and credits must agree, and open receivables and payables are loaded as individual items so that aging and reconciliation work from day one. Your controller compares the Odoo trial balance and open item listings to the source reports, account by account. Import file formats and tooling should be confirmed for the version in use. The deliverable is an opening balance reconciliation signed by the controller.
Run a parallel close on a test database
A test copy of the production candidate database is created and neutralized, as Odoo documents for test copies, so that it does not send live emails or connect to live bank and payment services. Confirm the exact neutralization actions for your version before relying on them. Your team then runs one full period close in parallel with the existing ledger, covering invoices, bills, bank reconciliation, accruals, currency revaluation where the entity needs it, and the trial balance. Differences are logged and resolved before go-live. The deliverable is a reconciled test period, a variance log and the report pack the controller accepts.
Go live with a closing calendar
Production cut-over happens on the agreed date, with opening balances loaded, users granted access through the sign-in method your organization has approved and the closing calendar published. The calendar lists each period-end task, its owner, its due point in the close and its approval step, and it is reviewed after the first live close. The support end date for the chosen version is recorded in the calendar so that an upgrade is planned before that window ends. Support after go-live, including any retainer, is agreed separately in writing. The deliverable is a live ledger, a closing calendar with named owners and a close checklist.
Loading opening balances and history without polluting the ledger
The first decision is what enters the Odoo Accounting database at all. There are three options. You can load opening balances only, which posts one summary position per account as of the cut-over date. You can load open items, meaning unpaid customer invoices and unpaid vendor bills, so that payments and reconciliation can continue after go-live. Or you can migrate historical transactions, which brings past posted entries into Odoo. Each step adds volume, dependencies and risk. Ask finance which reports must match the source system after go-live, and choose the lightest option that keeps those reports and day-to-day collections and payables working.
Each option carries specific risks. Duplicate entries appear when an imported invoice exists both as a historical record and as a document that users re-create or that a sales or purchase order regenerates. Tax mismatches appear when historical tax lines are mapped to current taxes, tax groups or fiscal positions that changed during the old system's life, so tax reports for past periods no longer agree with the filed returns. Reconciliation gaps appear when imported open items are not linked to the bank statement lines or payments that settle them, which leaves unexplained differences in bank reconciliation and payment follow-up. Open items carry the most daily risk because collections and payables depend on them.
Plan the cut-over date before any file is prepared. Choose a date on which the source system is closed for posting, and define how transactions entered after that date but before go-live will be handled. If the cut-over falls inside an open fiscal year, decide how year-to-date profit and loss is represented in the imported balances and confirm this with your auditors or external accountant. Align the date with your fiscal year-end closing process and the chart of accounts mapping, so that every source account has a documented target account in Odoo before the import runs.
Reconcile the imported balances to the source system before anyone relies on them. Produce a trial balance from the source system at the cut-over date and compare it account by account with the balances in Odoo. Compare open items in total and by partner against the aged receivables and payables reports, and compare bank balances with the statements at that date. Keep every difference on a written list with an owner and a resolution. Do not accept a difference because it is small. Each one either has a documented cause or it indicates a mapping or data error.
Test the whole import on a duplicated database before production. Odoo documents database duplication with neutralization for test copies, so run each import attempt on a fresh copy and confirm what neutralization disables in your version, such as outgoing mail and scheduled actions, before any integration is switched on. Repeat the import until the results are stable and the reconciliation checks pass without manual edits. Confirm which import tools your Odoo version provides for accounting data, including whether they handle journal entries, open items and taxes, because this determines how much of the work is scripted and how much is entered by hand.
What drives Odoo Accounting effort and how to keep it contained
This table compares the main drivers of effort in an Odoo Accounting project, how each one raises the work, and a practical way to keep it contained. Read it before scoping, because the drivers you can control early matter more than those you discover during testing. The main takeaway is that most cost comes from structure decisions made at the start, and that some work recurs after go-live.
| Driver | How it raises effort | How to keep it contained |
|---|---|---|
| Companies and currencies | Each legal entity needs its own fiscal localization settings, chart of accounts, journals and currency rules, and intercompany flows multiply testing. | Confirm the entity list and reporting currency with finance before scoping, and add entities only when a legal or reporting need exists. |
| Bank accounts and payment providers | Each bank feed, statement format and provider integration needs mapping, reconciliation rules and sample transactions to test. | Limit the first release to live accounts and providers, and document which feeds reconcile automatically and which stay manual. |
| Tax complexity across regions | Tax groups, fiscal positions, rounding rules and reverse charge cases multiply, and each needs test invoices and sign-off from a tax adviser. | Start from the fiscal localization package, list only the tax cases your transactions actually use, and get written tax rules from your adviser. |
| Open items to migrate | Open receivables, payables and bank items must be reconciled to the old ledger, and each exception needs a decision. | Agree a cut-off date, migrate balances and open items only, and set a tolerance for rounding differences before the trial load. |
| Users and approval rules | Roles, access rights, multi-level bill approvals and payment authorization each need design, configuration and negative tests. | Map approval thresholds to the existing delegation policy and keep the role model small, with separate roles for posting and payment release. |
| Reporting requirements | Management packs, statutory reports and consolidated views often need custom report work and reconciled test figures. | Ask for the list of required reports with their owners, use standard Odoo reports where they meet the requirement, and defer nonessential custom reports. |
| Integrations with other systems | Payment, banking, payroll, e-invoicing and data warehouse links each need field mapping, error handling and monitoring. | Prioritize the integrations needed at go-live, confirm which connectors are supported in your edition, and plan the rest as later phases. |
| Who is paid for what | A partner is typically paid for scoping, configuration, data migration, testing support and training, while your team pays for its own time in decisions, sign-off and data owners. | Ask the quote to split these components, name the deliverables for each, and state who holds the test evidence. |
| Recurring costs after go-live | Odoo subscription or hosting fees, support or maintenance retainers, upgrade work for new major versions, and changes to tax rules recur. | Ask for the recurring cost components in writing, the support window of your chosen version, and how upgrades will be tested before production. |
How Odoo Accounting connects to the rest of the platform
Accounting does not stand alone in Odoo. Sales, purchasing, Inventory, Point of Sale and Payroll post into the same ledger, while banks, payment providers and sign-in methods determine who can reach it and how cash is matched. Map each connection before the chart of accounts is final, because each one reads accounts, journals and taxes that must already exist.
Sales and purchasing invoices
Customer invoices from Sales and vendor bills from Purchase post journal entries to receivable, payable, revenue and expense accounts. The posting depends on product accounting settings, tax definitions and the fiscal position applied to each partner, so these must be designed before go-live. Check which journals each document type posts to, and test a sample of invoices, credit notes and refunds against the expected ledger lines.
Inventory valuation
Stock moves in Inventory create valuation entries that move value between stock and cost of goods accounts. The valuation method and costing approach chosen for each product category change what reaches the ledger and when it reaches it. Confirm the method with your controller, map stock accounts per product category, and reconcile the stock valuation report to the general ledger at each close.
Point of Sale sessions
Each Point of Sale session closes into accounting entries for sales, taxes and payment methods, and related inventory moves where stock is tracked. Cash differences, payment journals per terminal and the timing of session closing all shape how the day's sales appear in the ledger. Confirm which payment methods map to which journals, and agree the session closing routine before the first shop goes live.
Payroll entries
Pay runs can post accounting entries for gross pay, employer contributions, net pay and withholdings, with the salary rules and accounts defined through the country payroll localization. Payroll is an Enterprise app, so confirm the edition and the localization for your country before scoping. Agree with payroll and finance who reviews the generated entries and when they post to the ledger.
Bank and payment provider connectors
Bank statement imports and online payment providers feed the reconciliation queue, where transactions are matched to invoices and bills. Connector availability depends on your country, your edition and the specific bank or provider. Connectors for banks and payment providers are covered on the Odoo integrations pages, so confirm availability for your country and edition, and test matching rules against a representative sample of statements.
Sign-in and two-factor authentication
Odoo documents user sign-in through LDAP, with optional user creation on first login from a template, along with Google Sign-In, Microsoft Azure OAuth and two-factor authentication. Users who approve payments or post entries should sign in through the identity source your security team governs. Confirm which methods your edition and version support, and decide how leavers lose access to journals and payment approvals.
How support windows and upgrades set the deadlines for your ledger
Your ledger has a support deadline whether or not you plan for it. Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and security patches are only provided during that standard window. Once standard support ends, a version stops receiving security fixes on that path, so the accounting database you build now needs a planned route to a supported version. For the Accounting implementation, confirm the current status of each version you might run: Odoo 19.0 has standard support until September 2028, Odoo 18.0 until September 2027, and Odoo 17.0 standard support ended in September 2026. Odoo 20.0 was released in September 2026 with standard support planned until September 2029.
Major upgrades are mandatory every two years on Odoo Online and Odoo.sh, according to the Odoo upgrade documentation. That cadence means the fiscal localization, chart of accounts, tax configuration, custom reports and reconciliation rules you sign off at go-live will be moved to a newer release within the life of the system. On-premise deployments follow the support windows but are not subject to the same mandatory two-year cycle; confirm the exact upgrade obligations for your hosting type with Odoo before you commit to a timeline. SaaS versions are released every two to three months and cannot use extended support, so the version you start on is rarely the one you run at year three.
The upgrade service moves a database to a newer supported version by creating an upgraded test database. Treat that test database as a required stage, not an optional check. Run a full period close, bank reconciliation, payment follow-up and tax report on the upgraded copy, and compare totals against production before the cutover. On-premise use of the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. If you run Invoicing on Community, plan the upgrade path separately, because the Enterprise service is not available to you.
Put the upgrade into the close calendar. A cutover should not land in a month-end, quarter-end or year-end close, and the test cycle needs a clean period to validate against. Ask the partner how custom accounting reports, such as statutory packs, management reconciliations or localized tax returns built as custom modules or Studio views, will be tested on the upgraded database, who signs off the results, and what happens to any report that fails. Ask also whether the quote includes porting custom code and re-running the test scripts for each upgrade, or whether that work is billed separately each time.
Questions buyers ask before hiring help with Odoo Accounting
What drives the cost and duration of an Odoo Accounting implementation?
The scope of your books drives most of the cost and time: the number of legal entities, countries, bank accounts, tax regimes and journals, and how much historical data must move across. Odoo Accounting depends on a fiscal localization package for your country, so the chart of accounts, tax setup and fiscal positions must be mapped before configuration starts. Cost has two parts: one-time work for design, configuration, migration and testing, and recurring costs for hosting, licensing and support. Ask for a written scope that lists each item, the hosting environment (Odoo Online, Odoo.sh or on-premise), and the assumptions behind the estimate. Your quote should follow from that written scope.
Can our own team implement Odoo Accounting without an outside partner?
Yes, a capable internal team can do the work if it includes someone who knows Odoo configuration, your accounting rules and your data. The harder parts are usually migrating data, reconciling opening balances and rehearsing period-end runs before go-live, because these need repeated practice. Check three things first: your hosting choice, since Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise; whether you need features that sit in the Enterprise edition; and who will own the system after go-live. Ask your team to list comparable projects it has delivered, then decide which parts to keep in-house and which to scope out.
What does an Odoo Accounting project need from our finance staff?
Your finance staff make the decisions that configuration depends on. They need to confirm the chart of accounts, tax rules, journal structure, approval steps and how bank transactions are reconciled. They also supply historical data, sample documents for testing and sign-off on reports. Most of this effort falls early in design, then again during user acceptance testing and the first closing cycle. Name one decision owner and a backup, and state in the scope how many review rounds are included. When these decisions are delayed, configuration is often rebuilt late in the project, which increases both cost and risk to the go-live date.
Is Invoicing in the Odoo Community edition enough for our accounting?
Community Invoicing covers basic customer and vendor invoicing, but it is not the same as full Odoo Accounting. Make a list of the features you need, such as multi-currency handling, fiscal localization reports, bank reconciliation, payment follow-up and year-end closing, and check each one against the documented feature set for the edition you plan to run. Odoo's upgrade service is available only with an Enterprise subscription for on-premise use, and the Community edition has no access to it. If your list includes general ledger and statutory reporting, request a written comparison of the Community and Enterprise routes for your country before you decide.
How do we set up Odoo Accounting for multiple companies?
Multi-company support is a plan decision before it is a configuration task. According to Odoo's pricing page, only the Custom plan includes multi-company, so confirm that plan fits your hosting choice before design starts. Each legal entity needs its own chart of accounts, fiscal localization, tax settings and journals. You also need to decide which records are shared, such as customers, products and intercompany accounts. Plan intercompany invoicing, currency treatment and consolidated reporting early, because they change how data is structured. Before go-live, test a transaction between two companies and check the consolidated view, and ask for written documentation of the access rules for each entity.
How is year-end closing tested before we rely on Odoo Accounting?
Year-end closing is tested by running it on a copy of your data, then comparing the results with the figures your current system or your auditors produced. Odoo documents database duplication with neutralization for test copies, which lets a team rehearse the closing without touching live records. A useful test covers opening balances, accruals, depreciation, currency revaluation, tax returns, closing entries and the reports that follow. Ask for the test plan, the expected results written down before each run, and a list of differences with named owners. Your finance team should approve the outputs. A written scope should state which closing rehearsals are included and who signs off, because independent auditors decide which evidence they accept.
What happens to our accounting setup at the next Odoo upgrade?
Each upgrade is a planned project that moves your database to a supported version and retests the accounting setup. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so deferral has a limit. Odoo's standard support covers the first three years after a major release, including security updates and bug fixes, and Odoo 19.0 standard support runs until September 2028. Odoo's upgrade service creates an upgraded test database that should be tested before production, and on-premise use requires an Enterprise subscription. Ask for the upgrade steps, the porting of any custom modules and the test scope in the quote. Expect tax, fiscal localization and closing reports to be retested after each upgrade.
How DeployOpen scopes and delivers an Odoo Accounting implementation
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, including Odoo Accounting as the general ledger. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope lists the fiscal localization package, chart of accounts, journals, taxes and fiscal positions to be configured.
- Scope confirms whether you need Invoicing only in Community or full Accounting, since the two editions differ in what they cover.
- Confirm which hosting type and edition you will run, because the pricing page limits Odoo.sh and on-premise hosting to the Custom plan.
How we build
- We configure bank journals and reconciliation rules against your real bank feeds and test them with a sample month of statements.
- We set up payment follow-up levels, fiscal positions and tax mappings, then test invoices and credit notes against signed-off reference cases.
- We run a test migration of opening balances and open items, reconcile totals to your source ledger, and repeat until the results match.
How we hand over
- Handover includes configuration documentation for the chart of accounts, journals, taxes and fiscal positions, with the reasons behind each choice.
- We document the month-end and year-end closing sequence so your finance team can run the process without the implementation team present.
- Test databases are duplicated with neutralization, so your team can rehearse closing and upgrades without touching live financial data.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the implementation.
- Plan upgrades against Odoo's standard support windows, since security patches are only provided during standard support.
- Confirm with your team which Odoo version and support end date applies to your deployment before scheduling any upgrade work.
