Czech accounting teams that run their books in Odoo hit a hard wall every month: the tax office expects the Kontrolni hlaseni (VAT control statement) and the Priznani k DPH (VAT return) as structured XML submitted through the EPO portal, with every taxable supply classified by the correct reverse-charge subject code and split across the A1/A2/A3/A4/A5/B1/B2/B3 sections. Odoo core ships generic accounting and base_vat VAT-number checks, and a stock localization gives you a chart of accounts and a few tax records, but it does not generate a submission-ready EPO XML, does not enforce the kod predmetu plneni table on reverse-charge lines, and does not produce ISDOC invoices that Czech partners expect. Teams end up exporting to spreadsheets, re-keying into third-party portal tools, and reconciling by hand — exactly the work that triggers late-filing penalties when a code is wrong.

ECOSIRE builds a made-to-order Czech localization module for your Odoo database that closes those gaps end to end. On the accounting side we install a Czech uctova osnova chart-of-accounts template, the 21% and 12% VAT rates with their matching tax tags, and the reverse-charge tax codes wired to a kod.predmetu.plneni reference table so posting a construction or scrap-metal supply automatically carries the right subject code. On top of account we add new models.Model classes for the control-statement and VAT-return periods, with compute fields (@api.depends on the posted account.move.line tax tags) that bucket every line into its correct Kontrolni hlaseni section and roll the totals into the DPH return. A QWeb-driven XML export renders the exact EPO schema for both the control statement and the VAT return, plus the Souhrnne hlaseni (EU recapitulative statement) for intra-community supplies, so you download a file that uploads straight into the portal. DIC/ICO fields are validated and enriched through an ARES company lookup service, ISDOC e-invoices are generated from account.move and can be imported back into vendor bills, and bank statements in the ABO and GPC formats are parsed into account.bank.statement lines. Czech rounding and haler-handling rules are applied at invoice and payment level so totals match to the last heller.

Everything is delivered as a proper installable Odoo module: a clean __manifest__.py declaring dependencies on account, base_vat, and the base localization, access rights in ir.model.access.csv plus record rules for multi-user segregation, backend views and OWL widgets for the control-statement workbench, QWeb reports for the human-readable filings, and automated actions that flag periods approaching their deadline. The XML exports and the ARES/ISDOC exchanges are also reachable over Odoo's XML-RPC/JSON-RPC API so you can wire them into an existing filing or document-management workflow. The build targets your exact platform version and works on both Community and Enterprise for Odoo 17.0, 18.0, and 19.0 — where Enterprise adds document and OCR features we integrate with them rather than reinventing them.

Because this is build-to-order, nothing is auto-installed from a marketplace. After you request a quotation we run a short scoping call, confirm your Odoo version, edition, company structure, and which filings and formats you actually need, then build against a staging copy of your database, run UAT with your accountant on real periods, and hand over the installed module with documentation and training. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); additional legal entities, extra bank-format or portal integrations, deeper reverse-charge code coverage, and migrating historical VAT periods increase the quoted scope. You receive a fixed quote after the scoping call, before any work begins.