odoo 19 · 21 countries · sublicensing for odoo partners
Perpetual inventory, done properly.
Statutory perpetual inventory accounting for Odoo 19, wired to 21 national charts of accounts: goods receipt through a received-not-invoiced clearing account, cost recognised at goods issue, and no cost-of-sales line on the customer invoice.
$ odoo -i l10n_*_stock_account_method_a ✓ ready
the problem
Odoo doesn't post inventory the way your clients' accountants expect.
Across continental Europe, clients keep stock accounts continuously and recognise cost when goods leave the warehouse. In Poland, Portugal and Romania the law says so explicitly; elsewhere it is simply what the accountant expects to see. Odoo out of the box does neither — so every partner rebuilds it, per client, per chart of accounts, and again after each upgrade.
01 / CLEARING
No clearing account
Goods receipt doesn't run through an account that clears back to zero when the vendor bill posts. The “delivered but not yet invoiced” reconciliation isn't there.
02 / COST
Cost recognised too late
By default the expense lands on the customer invoice instead of at goods issue, so stock and cost drift apart within the period.
03 / EFFORT × N
Rebuilt every time
Per client, per chart of accounts, and again after every upgrade. That is exactly the work this package removes.
coverage
21 countries, one engine
One shared engine, plus a thin localisation per country that wires the product categories to that country's chart. Pick a market to see its actual accounts and postings.
Germany Austria Switzerland Netherlands United Kingdom Ireland Denmark Sweden Norway Estonia Latvia Lithuania Poland Hungary Slovenia Croatia Romania Bulgaria Portugal Czechia Slovakia
Czechia and Slovakia are covered by the same engine — they are where it started — and are handled directly rather than through this page.
what you get
One module you need, and layers you add only if the client does
The base localisation is the whole of method A on its own. Everything else is optional — install a layer only where a client actually needs it, and leave it out everywhere else. Nothing degrades if you never install them.
Runs on Odoo Community and Odoo Enterprise — the modules depend only on Community standard modules (stock_account, mrp_account, l10n_*), so they work wherever your clients already are.
BASE — REQUIRED
Perpetual inventory
Goods and raw materials, clearing account, cost at issue, stocktake differences and the period-end reclassification. This is the module.
MRP — OPTIONAL
Own production
Only for clients that manufacture. Finished goods and work in progress with their own stock and income accounts.
WAREHOUSE — OPTIONAL
Per-warehouse valuation
Only for clients running several warehouses — and even then, cost and accounts are two separate opt-ins.
optional · per-warehouse valuation
Two separate opt-ins: whose cost, and whose stock account?
Neither is switched on by default and most clients never need either. Clients running several warehouses hit two distinct problems, so they install as two independent layers — you can take one without the other.
Optional: cost per warehouse. Each warehouse runs its own cost pool alongside Odoo's company-level engine — weighted average and standard price at (product, warehouse) granularity, plus per-warehouse FIFO layers. An issue is valued at the source warehouse's own cost, and a transfer carries that cost with the goods instead of re-averaging centrally.
Optional: stock account per warehouse. Separately, each warehouse can post to its own balance-sheet account instead of the category's single company account, preserving the statutory account class and adding only a sub-account dimension. This layer ships its own interactive cheat sheet, because the postings genuinely change once stock is split this way.
timing and cut-off
When cost is recognised
Method A recognises cost at goods issue. In Poland, Portugal and Romania that is what the law prescribes. Elsewhere, where no local rule prescribes a posting pattern, IAS 2 and its local transpositions recognise cost in the period in which the related revenue is recognised — and for merchandise sold ex works or FOB shipping point the two coincide, so the postings are identical.
Where they diverge — a despatch crossing a period end, FOB destination terms, bill-and-hold, consignment — it becomes a cut-off question rather than a posting-pattern question, and one your client's accountant should settle rather than the software. We would rather say that plainly than pretend it never comes up.
If that cut-off matters to your clients, the period-end close can be extended with a delivered-not-billed reclassification so both bases agree at every period end. That is not part of the package today — tell us it matters to you and we will scope it together.
tested
Every module ships with its own test suite
234 test methods across 75 test files — and not one module in the family without tests. The engine carries 31 on its own, the per-warehouse cost layer 10, the account split 20, and each country localisation adds its own on top.
They assert the postings, not just that the code imports: that the clearing account nets back to zero, that cost lands at goods issue and not on the invoice, that a transfer moves value between the right two accounts. When you deploy this at a client and own the support afterwards, you can run the suite after every upgrade and know within a minute whether anything shifted.
demo
Try it yourself
Sample companies on Odoo 19 Enterprise, one per country, each with its own national chart and a fully posted goods cycle: receipt, vendor bill, goods issue, stocktake difference. The same product, posting differently in each jurisdiction — inspect the journal entries directly in the general ledger.
The demo resets every two days — try anything you like.
Open the demoCheat sheets — pick a country
Would you rather have your own sandbox?
The shared demo is fine for a look around, but if you want to load your own data, try an upgrade, or show a client something concrete, we will set up a private instance for you — not shared with anyone, and not reset every two days.
url ...... https://demo.datadance.eu
login .... on your country page ↑
password . methoda2026
company .. one per country
✓ Resets every 2 days, 03:00 CET.
for odoo partners
Buy once. Deploy across your client base.
We offer this package as a sublicense for Odoo partners: you acquire it once and deploy it at your clients — instead of rebuilding it per project or licensing it per client.
Scope, country selection, support and version maintenance are all open to discussion. Every partner works differently — one needs only one market, another twelve countries and a maintenance agreement. Tell us what would work for you, and we will see whether we can meet it.
who is behind it
Data Dance s.r.o.
Odoo consulting and development from Slovakia, doing Odoo and nothing else. We are the only Odoo Community Association member, contributor and supporter in Slovakia and Czechia — the code we give back is the same code our clients run on.
Inventory valuation is one piece of a much larger integration practice. What we build and maintain in production:
EDI & E-INVOICING
A shared EDI engine with concrete connectors — EDITEL EDIFACT over eXite SOAP, GRiT over the Orion OAuth2/REST API — for sales and purchase order flows with retail chains, dispatched asynchronously through queue jobs. Plus Peppol BIS Billing 3.0 send and receive via the eXite access point, and ISDOC for Czechia including advance invoices.
SHIPPING & LOGISTICS
Eleven carrier integrations — Packeta, DPD, PPL, GLS (MyGLS), Balikobot, Slovak Post, SPS, SDS, TopTrans, Wolt Drive — with cash on delivery, backend label printing via PrintNode, and pickup-point selection built into the eCommerce checkout.
PAYMENTS
Online gateways — GoPay, Comgate, Pays.cz and Nexi XPay — alongside Comgate payment terminals in the point of sale (including the CloudPOS 2.0 API), fast-terminal flows and tipping. Payment QR codes for Pay by square (SK) and QR platba (CZ), on invoices and at the till.
BANKING & FISCAL
Statement import (GPC, MultiCash), ISO 20022 / SEPA payment orders with local payment symbols, and fiscalisation for EET (CZ) and VRP2 (SK) including POS.
DOCUMENTS & DATA
ONLYOFFICE for editing documents, reports and templates directly in Odoo. ARES (CZ) and Finstat (SK) partner lookups, VIES validation, payment-reliability checks, POHODA export for clients whose accountant stays on POHODA, and SMS gateways.
PAYROLL & STATUTORY
Full CZ and SK payroll with the statutory filings that go with it — and the CZ/SK accounting localisation this inventory package grew out of.
We build these modules because we need them ourselves. They stay maintained because our own projects run on them.
edi_editel (eXite) ....... ok
edi_grit (Orion) ......... ok
peppol_bis3 .............. ok
account_edi_isdoc ........ ok
delivery × 11 carriers ... ok
gopay/comgate/pays/nexi .. ok
pay_by_square / qr_platba ok
eet2 / vrp2 (fiscal) ..... ok
onlyoffice ............... ok
stock_account_method_a ... ok
✓ 19 countries. ready to dance.
$
sublicense
Tell us what you need.
A few lines are enough. Say which countries matter to you and roughly what scope you have in mind, and we will take it from there. A private sandbox is yours for the asking — just mention it in the message.
$ dd sublicense --market eu