Odoo 18 Community is a capable ERP right up to the moment your accountant asks for a balance sheet in the statutory layout. Accounting reports, asset management and payroll are Enterprise-only modules. For a Czech company that is not a small gap - it is the difference between a system you can file taxes from and a system you cannot.
So we built the Czech parts ourselves, as modules for Community edition, and we run Cybermindnet's own books on them. Not a demo, not a proof of concept: our VAT returns, our payslips, our annual close.
What Odoo 18 CE does not give you
Three standard modules are Enterprise-only in version 18: account_reports, account_asset and hr_payroll. Everything below replaces those functions, depending only on stock Community modules plus the community Czech localisation l10n_cz, which supplies the chart of accounts.
VAT: from ledger to the tax portal
The core module handles the whole Czech VAT agenda and produces the two XML files the tax office expects:
- DPHDP3 - the VAT return, lines R1 to R65.
- DPHKH1 - the control statement, sections A.2, A.4, A.5, B.1, B.2, B.3 and C, with checksums.
Both are generated for upload to the MOJE daně portal, and both support regular, corrective and supplementary filings. Records are selected by the date of taxable supply, with a fallback to the document date, and consolidated across the parent company and all its branches - one tax ID, one filing.
Closing a VAT period is a bookkeeping operation, not just a file download. The wizard posts the closing entry that clears the 343 accounts and nets the balance to a receivable from, or a liability to, the tax office. The generated XML is attached to the closed period as evidence, and every period carries a state - draft, posted, submitted - so an auditor can see what was filed and when.
Statutory statements and the rest of the ledger
- Financial statements - balance sheet and profit and loss in the structure required by Vyhláška č. 500/2002 Sb., plus a trial balance, exportable to PDF or XLSX, optionally consolidated across branches.
- Fiscal years, period locking and the annual close, including profit distribution.
- Bank transactions and payment matching, with Czech payment symbols on invoices and a Fio Bank synchronisation for automatic statement import.
- Tax depreciation per §30 to §32 of the Income Tax Act - straight-line, accelerated and extraordinary - built on the OCA asset management module rather than a private reimplementation.
- Internal clearing through 395 accounts, which is what makes a multi-branch structure add up without inventing intercompany invoices.
- Loans and recurring contracts - principal, interest, repayment schedules, and leasing or subscription contracts that generate their invoices from the schedule.
Payroll that knows Czech law changes every year
The payroll module implements the three employment forms - HPP, DPP and DPČ - with the correct social and health insurance rates, progressive 15/23 % income tax, the statutory thresholds for agreements, and the taxpayer credit under §35ba applied only where the employee has signed the declaration.
One design decision matters more than the feature list. Rates are branched by year in code rather than overwritten when the law changes. A 2024 payslip recalculated today still uses the 2024 rates. Payroll where "we updated the percentage" silently rewrites history is payroll you cannot defend in an inspection.
Official forms are filled by overlaying the real MFČR templates - the ministry's own PDFs, filled at exact coordinates - instead of rebuilding them as HTML lookalikes. A form that merely resembles the official one is a form an official can reject.
What is not in there yet
Being specific about gaps is cheaper than being caught by them:
- Monthly social security and health insurance reports are not generated. They require statutory XML formats we have not implemented.
- Annual tax settlement (roční zúčtování) is not supported - employees file their own returns.
- The social insurance maximum base is not tracked, because it needs year-to-date accumulation across payslips.
- Submission to the tax portal is manual. The system produces the XML and records the submission reference; a data box integration is planned, not delivered.
Why this exists at all
We did not set out to write an accounting system. We needed one, the Enterprise route meant paying per user for functions that are legally mandatory in our jurisdiction, and the modules kept working, so they grew.
That has a practical consequence for anyone considering them: the first user of every one of these modules is our own accounting department. A bug in the VAT export is our filing problem before it is yours. That is a stronger guarantee than any roadmap.
Who this is for
- Czech companies on Odoo Community who hit the Enterprise wall at exactly the moment the accountant arrives.
- Companies with a branch structure that need consolidated statements and internal clearing without a separate ledger per branch.
- Anyone migrating off a closed Czech accounting package who wants the data model to stay inspectable.
No lock-in
The modules run on standard Odoo 18 Community. If you leave, you take the database, the configuration and the source of the custom modules with you - there is no runtime licence to switch off. Odoo itself is open source; the Czech extensions are ours, and clients running them get them.
Getting started
Tell us what you run today, how many people touch the books, and whether you have branches. We come back with a migration plan, an honest list of what is not implemented yet, and a quote.
E-mail info@cybermindnet.eu or use the contact form.