AIVcoreOdoo development
en
All publications
Article11 March 20262 min read

Custom accounting reports in Odoo: how we build them

Trial balance, reconciliation statements, purchase/sales ledgers and management P&L. Which Odoo mechanism fits each report type — and where not to invent your own.

Project facts

Industry
Финансы
Stack
Odoo 17QWebaccount.reportXLSX

Accounting is where an "almost correct" report is worthless. Here is how we build reporting in Odoo so that both the chief accountant and the auditor accept it.

Three mechanisms to choose from

1. The account.report engine

Best for statutory reports with a line hierarchy: trial balance, balance sheet, profit and loss. Lines are described declaratively, the engine computes balances and turnover, drills down to journal entries and exports to XLSX/PDF.

We use it whenever the report is an aggregate over the chart of accounts.

2. QWeb templates

For printable documents: reconciliation statements, invoices, delivery notes, quality certificates. QWeb gives full control over layout, supports company details, stamps and signatures, and handles multi-page output correctly.

3. SQL views plus list/pivot

For management analytics that need fast slicing: margin by customer, aged receivables, P&L by project. We create a model on top of a view (_auto = False), and users then work with Odoo's standard filters, grouping and charts.

What clients ask for most

Trial balance with analytics — the standard report plus sub-accounts and analytic accounts, with drill-down to entries.

Reconciliation statement — handling currencies, prepayments and contracts, in a format the counterparty will sign without questions.

Aged receivables — 0–30, 31–60, 61–90, 90+ days, with the responsible manager and last payment date. A separate button sends reminders to debtors.

Management P&L — a parallel chart of accounts or analytic accounts, because management and statutory accounting almost always diverge.

Month-end close — a checklist: what is unposted, which closing documents are missing, which entries lack analytics.

Three rules that save months

  1. 01Do not compute in the report what should be computed in accounting. If costing has to be "fixed" inside a report, the accounting setup is broken and the report only hides it.
  2. 02Every aggregate must drill down to a document. No accountant trusts a number that cannot be traced to an entry.
  3. 03Excel export is mandatory. Not "PDF and then copy it over", but a proper XLSX with formulas and data types.

Performance

Reports over millions of journal items are written in SQL, not ORM loops. Heavy aggregates go into materialised views refreshed nightly. Practical bar: an interactive report must open in under 3 seconds, otherwise nobody uses it.

Similar challenge?

Describe your process — we will estimate the scope and timeline.

Related publications