Odoo Analytic Accounting: Plans, Distribution and Reporting

The model in one pass

Analytic accounting adds a reporting dimension that sits beside the general ledger rather than

inside it. Three pieces:

• account.analytic.plan is a dimension. Department, Project, Cost Centre. Plans can be nested

under a parent plan.

• account.analytic.account is a value within a plan. Marketing, Project Alpha, Van 3.
• Analytic distribution is the assignment on a journal item, stored as a mapping of analytic

account to percentage.

The general ledger still answers "how much did we spend on fuel". Analytic answers "how much of that

fuel was Project Alpha", without adding a single account to the chart.

That last point is the reason the feature exists. The alternative people reach for first is encoding

the dimension into account codes, which multiplies the chart, freezes the structure, and still only

supports one dimension.

Distribution is a percentage split

An analytic distribution on a line is not a single account. It is a set of accounts with

percentages, which means one cost can be split across several destinations:

• 60 percent to Project Alpha, 40 percent to Project Beta, both in the Project plan
• and simultaneously 100 percent to Marketing in the Department plan

Percentages within one plan should total 100. Nothing stops you posting a distribution that totals

less, and the shortfall becomes cost that exists in the ledger but appears nowhere in the analytic

report. If your analytic totals do not tie back to the general ledger, incomplete distributions are

the first thing to check.

The root-plan storage rule

This is the part that is worth knowing before you write a single line of reporting code, because it

is invisible from the interface and it silently returns empty results.

Distribution is not stored in a generic table keyed by plan. Each plan is backed by a column on

the analytic line, and the column belongs to the plan's root, not to the plan the account sits

in.

In the Odoo source the column name is derived like this:

def _strict_column_name(self):
    return 'account_id' if self == project_plan else f"x_plan{self.id}_id"

def _column_name(self):
    return self.root_id._strict_column_name()

Read that second method carefully. _column_name resolves root_id first and asks the root for the

name. So:

• The default project plan is special and uses account_id
• Every other root plan uses x_plan<root id>_id
• A child plan has no column of its own

Concretely: if you have a root plan with id 2 and a child plan under it with id 3, an analytic

account belonging to the child plan stores its distribution in x_plan2_id. There is no

x_plan3_id column at all.

The failure this produces is not an error. A query built from the child plan's id targets a column

that does not exist, or worse, targets nothing and quietly returns no rows. The report renders, it

is simply empty, and the natural conclusion is that nobody has entered any data.

Always resolve the root plan before building a column name.

Plans are columns, so deleting one destroys data

The same fact has a second consequence. Because a plan is backed by a real column, removing the plan

removes the column and everything stored in it.

There is no active field on account.analytic.plan, so there is no archive-instead-of-delete

option the way there is on most Odoo models. The choice is keep it or lose the data.

In practice: retire a plan by ceasing to use it. Do not delete it to tidy the configuration screen.

Writing distribution programmatically

One caution if you are bulk-updating analytic distribution rather than setting it by hand.

Writing analytic_distribution on account.move.line through the ORM triggers the surrounding

recomputation, and on posted invoices that can reach lines you did not intend to touch, including

early payment discount lines. For a one-off correction that is fine. For a bulk re-plan across

thousands of lines it is not, and Odoo core itself uses raw SQL for exactly this reason.

If you are re-planning historical data, treat it as a migration with a backup and a verification

query, not as a mass edit from a list view.

Where this connects

Analytic accounting is the dimension the chart of accounts should not be carrying. If your account

codes have department or project encoded into them, this is the feature that lets you flatten the

chart back down. It works best once the chart itself is settled, because moving both at once makes

the reconciliation between them very hard to check.