Odoo Accounting Implementation
Odoo Invoicing and accounting: ledger, AR/AP, tax, e-invoicing.
Full double-entry accounting with multi-currency, automated reconciliation, tax localization, e-invoicing, and IFRS/GAAP-ready reports.
Odoo ships two different products under one name. Community installs the app called Invoicing: a chart of accounts, journals, taxes, customer invoices, vendor bills, payments and a real double entry ledger behind all of it. Enterprise adds the Accounting app, and what it adds is the machinery of a monthly close. Bank feeds and the statement file importers. The reconciliation view with matching rules. The engine that renders every statutory report, including the aged receivable. Fixed assets, deferred entries, follow up letters, automatic currency rates and bank payment files. Most buyers meet that line halfway through a demo, usually when somebody asks to see the asset register.
The software is rarely what makes these projects hard. Three decisions taken in the first fortnight set the tone: which localisation package is installed, how documents are numbered, and how the opening balance crosses over. The first is close to irreversible, because Odoo will not swap the chart of accounts package once a single journal entry exists in that company. The other two surface months later as an ageing report nobody trusts.
The rest of the work belongs to the tax authority, and the shape of it varies more than people expect. Saudi Arabia, India, Egypt and Turkey run clearance or near real time reporting, so an invoice is not final until a government platform or a licensed integrator has accepted it. France and Germany run a network model instead, where structured documents in the EN 16931 formats move between registered platforms. Both models put master data on the critical path. Missing tax registration numbers, item classification codes and unit of measure codes stop being tidiness problems and start rejecting live invoices in week one.
Who Odoo Accounting is for
- → Groups running several legal entities, currencies or branches that need one ledger and a consolidated view rather than four spreadsheets merged by hand.
- → Companies inside a clearance e-invoicing regime, where the ERP has to hold a conversation with the tax authority for every invoice it raises.
- → Distributors and manufacturers who want stock valuation, landed cost and cost of goods sold posting from the same system that raises the invoice.
- → Services firms billing from timesheets that need a profit and loss per project or per contract, not only per company.
- → Not for a company raising twenty invoices a month and handing everything to an external accountant. Community Invoicing plus a periodic export is enough, and the licence saving is real.
- → Not for regulated banks or insurers, whose statutory sub ledgers and supervisory returns Odoo does not model and should not be forced to.
Key features
- ✓ Multi-company, multi-currency
- ✓ Automated bank reconciliation
- ✓ Tax localization (50+ countries)
- ✓ E-invoicing (ZATCA, PEPPOL, SDI)
- ✓ Fixed assets & depreciation
- ✓ IFRS/GAAP reports
What Odoo Accounting actually does
Ledger, journals and posting control
Every document lands as a journal entry, so sales, purchase, bank, cash and miscellaneous journals are the real structure of the system. Posting is not a single gate. A posted entry can still be reset to draft unless something stops it, and the things that stop it are lock dates and hashing. Odoo 18 and 19 carry five company lock dates: global, tax return, sales, purchase, and a hard lock date that is irreversible and admits no exception. The first four can be lifted for one named user for a limited period through a lock date exception, which is stored as a record rather than applied as a quiet override. The Secure Entries wizard hashes posted entries so they cannot be altered afterwards, and the audit trail setting, which is in Community as well, tracks changes to entries that have already been posted.
Receivables and collections
Payment terms carry several instalments, an early payment discount and a due date computed per line, so thirty percent up front with the balance at sixty days is one term rather than two invoices. Partial payments reconcile against the open item and the residual stays visible on the partner ledger. Follow up levels, which chase overdue customers on a schedule with escalating letters, a responsible person and a promised payment date, are Enterprise. So is the aged partner balance report itself. Community teams build the ageing from a journal items list filtered on due date, or add the OCA financial reports, then chase by hand. That is workable until the ledger passes a few hundred open items.
Vendor bills and payment runs
A bill can be checked against the purchase order and the goods receipt before posting, and the Control Policy on the product decides whether the bill is raised on ordered or on received quantities. That one setting causes more supplier disputes than any other. Selecting several bills for the same vendor, journal and currency and registering a single payment works in Community. Batch payments and the ISO 20022 credit transfer file the bank actually wants are Enterprise. Enterprise also adds invoice digitisation, which reads a supplier PDF into a draft bill and consumes IAP credits per document, so it is a running cost rather than a licence line.
Bank, cash and reconciliation
Enterprise connects to bank feeds through the supported aggregation providers and drops statement lines into the reconciliation view, where matching rules propose the invoice, the partner and any write off. The statement file importers for OFX, QIF, CSV and CAMT are Enterprise too, which catches people out, because Community has no standard module that reads a bank file. Community teams key the statement or push lines in with the generic import, then reconcile from journal items. In both editions the outstanding receipts and outstanding payments accounts have to clear at period end. A balance that keeps growing in those two accounts is the earliest sign reconciliation has quietly stopped.
Tax engine, fiscal positions and returns
Taxes are objects with their own accounts, tax grids and rounding behaviour, not a percentage typed on a line. Fiscal positions swap taxes and accounts automatically based on the customer, which is how reverse charge, export zero rating and free zone treatment get applied without asking a salesperson to remember. The return reads from the grids rather than from the rate, so a tax mapped to the wrong grid gives you books that balance and a return that is wrong. Worth knowing before you price the project: the report definitions ship with the localisation and exist in Community as records, but the engine that renders them, and the automated tax closing entry that moves the tax lock date, belong to the Enterprise reporting app.
Analytic distribution and cost centres
Since Odoo 16 the analytic model has been plans plus a distribution field on the journal item, replacing the old analytic account and tag pair, so one line can be split by percentage across a project, a department and a cost centre at once. Distribution models apply a default automatically from the partner, the product, the account prefix or the company, which is the only way this survives contact with a busy purchase ledger. Analytic entries sit alongside the general ledger rather than inside it, so a cost centre report can never break the trial balance. Design the plans before go live anyway. Distribution stays editable on posted lines, but correcting a year of them in a list view is nobody's idea of a close.
Multi-company, multi-currency and close
One database can hold several companies with their own charts, currencies and document numbering, and the inter company rules raise the mirror document on the other side when one entity sells to another. Foreign currency invoices keep the original amount and the rate at the invoice date, and the unrealised gain and loss adjustment is produced from an Enterprise report rather than from anything in Community. Fixed assets with depreciation boards, and deferred revenue and expense entries, are Enterprise only. Group reporting means selecting several companies and running the Enterprise reports across them, so agree what your auditor means by consolidation before promising one. An asset register is a common reason a Community plan turns into an Enterprise one halfway through a build.
How we configure Odoo Accounting
Install the localisation before anything else
The localisation package brings the chart of accounts, the tax codes, the tax report definitions and, in some countries, the e-invoicing module. It installs only while the company has no journal entries. Get it wrong and the fix is a new database, not a correction. Read what the package actually contains before committing to a date, because plenty of countries ship a chart of accounts and a tax set with no transmission module at all, and that gap is a build rather than a setting.
Design numbering before the first invoice
Odoo derives the next number from the last posted entry in the same journal, so the sequence follows the data rather than a field you edit later. Decide per legal entity, per branch and per document type whether the series resets annually or monthly, and whether the tax authority requires an unbroken run with no gaps. Changing the format mid year triggers a resequencing prompt that will renumber posted documents if somebody clicks through it without reading.
Map taxes to the actual return boxes
Configuring a fifteen percent tax takes a minute. Mapping it to the grid that feeds the right line of the local return, with separate treatment for imports, exempt supplies and reverse charge, is the actual work. Build the fiscal positions at the same time and attach them to customer and supplier records rather than leaving the choice to whoever raises the order. Then reconcile a full month of output against a manually prepared return before anyone files from Odoo.
Load open items, not a trial balance
Balance sheet accounts come across as one opening journal entry per company and per currency. Receivables and payables have to arrive as individual open invoices and bills carrying their original dates, currencies and rates, so ageing and reconciliation work from day one. A lump sum in the receivable account leaves the first customer payment with nothing to match against. Fixed assets load at cost with accumulated depreciation to date, never with a fresh useful life.
Settle inventory valuation with operations first
The costing method, standard, average or FIFO, and the choice between manual and automated valuation decide whether stock movements touch the ledger at all. Changing costing method after transactions exist generates revaluation entries somebody then has to explain to an auditor. The Anglo Saxon setting separately decides whether cost of goods sold posts at delivery through an interim account or at invoice, which moves gross margin between months in every report the board reads.
Agree how bank data will arrive
On Enterprise, connect the bank in a test company first and look at what actually turns up, because feed quality varies by institution far more than by country and some supply nothing beyond a date, an amount and a narrative. On Community, settle this early, since the standard file importers are not there and the options are manual entry, the generic import or a small integration. Then build matching rules for the lines that repeat every week: bank charges, card settlement batches, payroll transfers and standing collections from the largest customers.
Where Odoo Accounting projects go wrong
The chart of accounts nobody can change later
Teams copy the legacy chart account by account, then discover the localisation chart was the one carrying the tax grids and the statutory layouts. Because the package locks after the first journal entry, the correction is a rebuild. Start from the country chart, extend it with the analytic plans and the few extra codes the business genuinely needs, and resist the request to reproduce a numbering scheme somebody invented in a different system fifteen years ago.
Opening balances that cannot be reconciled
The most common migration shortcut is a single receivable balance and a single payable balance in the opening entry. It ties out to the trial balance, so it passes review, and then the first customer payment arrives with nothing to match. Ageing is blank, collections stall, and somebody rebuilds the sub ledger by hand during month one. Load open items individually, in original currency, and reconcile the total back to the opening entry before go live.
Rounding differences against the customer purchase order
Odoo rounds tax per line or globally on the document, and the choice is a company level setting. Pick the wrong one and invoices differ from the customer purchase order by a cent or two, which sounds harmless until a large buyer rejects them automatically. In clearance countries the same mismatch is refused by the tax platform. Fix it during configuration and test with real quantities and awkward decimals, not with round numbers.
Treating e-invoicing as a go live day switch
Clearance platforms validate content, not intent. Tax registration numbers, buyer identifiers, item classification codes, unit of measure codes and address fields all have to be correct on every partner and product before the first submission. That is a data cleanup exercise across the master files, usually the largest single task in the plan, and it cannot start in the week of go live. Rehearse against the authority test environment with real records rather than demo data.
Currency rates that stopped updating in testing
Multi-currency gets switched on, three rates are typed in during configuration, and nobody touches the table again. Every foreign invoice after that posts at a stale rate and the year end translation means nothing. The scheduled update that pulls rates from a provider is an Enterprise feature, so a Community deployment needs a named person entering rates on a named day, or a small integration. On Enterprise, pick a provider your auditor will accept, confirm the scheduled action is really running on the live database, and check the rate date convention matches how your accountants have always translated balances.
No owner for the lock date
Odoo accepts a back dated entry into a period the accountant considers closed unless a lock date says otherwise. On live systems this is how a filed return stops matching the ledger. Give the lock dates a named owner, move them as a step in the close checklist, and decide during testing who may post into a previous period and through what approval. Treat the hard lock date as a separate decision with its own sign off, because it cannot be rolled back once it is set.
What it works with
- + Sales, where the invoicing policy on the product decides whether you can bill on ordered quantities or only after delivery, and Subscriptions, an Enterprise app, for recurring billing
- + Purchase and Inventory, for matching the vendor bill against the purchase order and the goods receipt before it posts
- + Stock valuation, where the costing method and the automated valuation setting decide whether a goods receipt writes to the ledger at all
- + Expenses, turning employee claims into payable documents settled inside the same payment run
- + Payroll, an Enterprise app, which posts one salary journal entry per period rather than a stack of individual bills
- + Project and Timesheets, through analytic distribution, for a profit and loss per job instead of only per company
- + Payment providers such as Stripe, Adyen, Razorpay and Mollie, which register the payment against the invoice and then leave you the separate job of tying their payout batch back to the bank line
- + Peppol, through the standard access point module that ships in Community, for sending and receiving EN 16931 documents in the countries that use the network model
Odoo Accounting by country
Saudi Arabia (KSA)
ZATCA Phase 2 is clearance for standard tax invoices and reporting within twenty four hours for simplified ones. Odoo covers it in the Saudi e-invoicing module, which is part of Community, builds the XML, the QR code and the cryptographic stamp, and stores the ZATCA response on the invoice. Onboarding runs per solution unit: a compliance certificate first, then a production one, repeated for every branch or device registered. Waves are notified roughly six months ahead and the specification is versioned, so budget for retesting after each Odoo upgrade. The Saudi statutory reports are the Enterprise side of the localisation.
United Arab Emirates
The UAE package gives a chart of accounts at five percent VAT with zero rated, exempt, import and reverse charge treatments. The VAT report itself sits in the Enterprise reporting module, and there is no EmaraTax submission from Odoo either way, so filing stays a transcription job. The national e-invoicing programme uses a five corner model with accredited service providers, which standard Odoo does not ship, so treat that as a connector project with its own timeline. Corporate tax at nine percent above AED 375,000 needs its own account mapping, and free zone customers depend entirely on the fiscal position being right on the customer record.
Pakistan
FBR digital invoicing is a clearance model. Invoice data goes to the FBR system through PRAL or a licensed integrator as JSON, and the returned FBR invoice number with a seven by seven millimetre QR code has to print on the document. Odoo ships the Pakistani chart of accounts and sales tax setup in Community and a tax report in Enterprise, and nothing that talks to FBR in either edition, so the integration, the token handling and the retry queue for rejected submissions are all build work. Provincial sales tax on services adds a second set of tax codes the standard package does not carry.
India
India is the most complete localisation Odoo ships, and the edition split matters. IRN e-invoicing and e-way bills are Community modules and raise documents straight from sales orders and delivery orders. GSTR-1, GSTR-2B and GSTR-3B filing sits in the Enterprise reporting modules. Two things bite in planning. API credentials come from the government portals, or through a GST Suvidha Provider for larger groups, and obtaining and testing them is a task with its own lead time. And the reporting window that applies to larger taxpayers means Odoo will happily post a back dated invoice that the portal then refuses to register.
Turkey
This is the one to be blunt about. Odoo ships the Turkish chart of accounts and KDV taxes in Community and the Turkish financial reports in Enterprise, and nothing at all for the GIB: no e-Fatura, no e-Arsiv, no e-Defter, no e-Irsaliye, in either edition. Whether a customer receives an e-Fatura or an e-Arsiv depends on their registration in the GIB user list, so the system has to check rather than guess, and that check is custom. KDV tevkifat, where the buyer withholds part of the VAT, is the trap question in every Turkish demo and standard tax objects do not model it. Assume an integrator contract plus a build, not a configuration exercise.
United Kingdom
There is no B2B mandate. The live obligation is Making Tax Digital for VAT, filed from compatible software, and both the UK reporting module and the HMRC connector are Enterprise, so a Community deployment needs bridging software or a manual return. Making Tax Digital for Income Tax began phasing in during April 2026. Selling to the public sector is a separate matter, because contracting authorities have to be able to receive EN 16931 invoices and NHS suppliers are expected to exchange over Peppol, which is the one part of this that Community already covers.
Germany
German books run on the DATEV charts SKR03 or SKR04. Odoo ships both, you choose one at install, and the package cannot be swapped once an entry exists, so this is a week one conversation with the Steuerberater rather than a later refinement. Since January 2025 every German business has had to be able to receive a structured e-invoice, and Odoo reads and writes the EN 16931 formats, XRechnung and the Factur-X style hybrid, in Community. Issuing becomes mandatory in stages from 2027. The DATEV export your accountant will ask for, split into documents and journal entries, is part of the Enterprise German reports.
France
Reception applies to every French company from September 2026. Issuing is phased by size, from September 2026 for large and mid-sized companies and September 2027 for the rest. Exchange runs between registered partner platforms rather than through one government portal, so the platform choice sits beside the ERP and belongs in the project plan with its own contract. Factur-X, UBL and Chorus Pro for public sector customers are Community. Sending the VAT return itself is an Enterprise feature. What delays go lives is master data: a valid SIREN on every business partner, and delivery addresses recorded separately where they differ from the billing address.
Odoo Accounting FAQs
What actually changes if we move from Community to Enterprise?
The ledger does not change. The same journal entries, taxes, invoices and payments carry on, and the database upgrades in place rather than being reimplemented. What you are buying is the close, and the country modules that file rather than only calculate. In practice the move is forced by one of three things: an asset register, a close that has to be repeatable every month by somebody other than the person who built it, or a statutory report that only exists in the Enterprise side of your localisation. Decide before go live, because the expensive part is unwinding six months of workarounds built to avoid the licence.
Who needs a paid user in Odoo?
Enterprise is priced per internal user across the whole database rather than per application, so you cannot buy Accounting for the finance team and leave the rest of the company out. Portal users, meaning customers and suppliers viewing their own documents through the website, are free. That changes the arithmetic on approvals: an expense claim or a timesheet sign off from somebody who logs in twice a month still costs a full seat, which is worth modelling before you size the subscription.
Can we change the chart of accounts after go live?
You can add accounts, rename them, deactivate the ones nobody uses, and reorganise the account groups that give the reports their hierarchy. What you cannot do is change the installed localisation package once a journal entry exists in that company, because the package ties the tax grids and the statutory report definitions to specific accounts. The package also fixes the account code width at install and normalises existing codes to it, so settle the digit count with whoever owns group reporting at the same time. If the wrong package went in, the practical route is a new database.
Can we keep our existing invoice numbers?
Historic numbers come across as a reference on the migrated document, which is what you want for audit trails and customer queries. Live numbering is a separate question. Odoo builds the next number from the last posted entry in the journal, so you can start a new series at any value by setting the first entry manually and then leaving it alone. What does not work is running two overlapping series in one journal, or reusing a number the tax authority has already accepted.
How much history should we migrate?
Open items always: unpaid customer invoices, unpaid supplier bills, unreconciled bank lines, and the asset register with depreciation to date. Closed history usually not. Reloading three years of posted invoices as live documents creates numbering conflicts and tax report noise for data nobody will ever transact against. Keep the legacy system readable for the retention period and load prior year comparatives as summarised journal entries instead.
Does Odoo handle our country e-invoicing natively?
Ask three separate questions about the exact version you are deploying, because the answers differ. Is there a chart of accounts and a tax set. Is there a statutory report, and is it Community or Enterprise. Is there a module that actually transmits to the authority. Most countries have the first, most of the reports are Enterprise, and transmission exists for a short list. Saudi Arabia, India and Egypt have transmission modules in the standard localisations, and those happen to be Community. Turkey has none in either edition. Neither do the UAE, Oman, Qatar, Kuwait or Pakistan, so a mandate there means a connector with its own timeline and its own maintenance.
Should each legal entity be a separate database?
One database with several companies is the default answer when entities share customers, products or staff, because inter company documents, group reporting and shared master data all work out of the box. Separate databases make sense when the entities are unrelated, when data residency rules force it, or when one has to stay on a different Odoo version. Multi company brings record rule complexity, so plan access rights and default company behaviour early rather than after the first mispost.
Can we go live mid year rather than at year end?
Yes, and it is common. The opening balance is taken at the close of the last completed period rather than at a fiscal year boundary. Year to date comparatives load as summarised monthly journal entries so the profit and loss reads correctly for the full year. A mid year cutover also keeps the annual close and the migration out of the same fortnight, which matters more than the tidiness of a January start.
Should we run Odoo in parallel with the old system?
Run one month in parallel if the finance team can staff it, and no longer. Parallel running catches tax mapping and rounding errors that no test script finds, because it compares real transactions rather than invented ones. Beyond a month it costs more than it discovers, and the double keying makes both sets of books drift apart. Agree in advance which reports have to reconcile and what variance you will accept before signing off.