Fixed asset depreciation is one of those Odoo modules that looks deceptively simple in a demo. You create an asset, pick a method, set a duration, and Odoo generates a clean depreciation board — one line per period, debiting depreciation expense and crediting accumulated depreciation, right through to the end of the asset’s useful life. It works exactly as advertised for a straightforward company running one book, one method, one policy.
The trouble starts when your organisation’s actual depreciation policy doesn’t match Odoo’s default assumptions — and by the time anyone notices, there are already hundreds of asset records sitting on the wrong schedule.
How Odoo actually calculates depreciation
Odoo’s Accounting app (and Assets, if you’re on Enterprise or using the OCA equivalent) supports a handful of computation methods on the asset form: Straight Line, Declining, and Declining then Straight Line. Each asset record carries its own acquisition date, gross value, useful-life duration, and a “first depreciation date” — and by default, that first date is derived from the acquisition or invoice date, prorated to the day or month depending on your prorata setting.
That prorata behaviour is the part that surprises people. Buy an asset on the 18th of the month and, depending on configuration, Odoo will either prorate that first period’s depreciation down to a partial amount, or push the whole first period’s charge to line up with month-end. Both are defensible accounting choices. Neither is universal.
The mismatch: when HQ’s method isn’t Odoo’s method
Here’s the pattern we see most often, and it’s worth describing as an illustrative scenario rather than a specific engagement: a subsidiary or franchise operation goes live on Odoo locally, using Odoo’s sensible acquisition-date-based defaults. Sometime later — often during a group audit, a parent-company consolidation, or a first IFRS/local-GAAP reconciliation — someone points out that the group’s actual depreciation policy runs on a constant period method: every asset class depreciates over fixed, calendar-aligned periods (say, the 1st of the month following acquisition, regardless of the exact purchase date), dictated by a parent-company accounting standard rather than by each asset’s individual acquisition date.
Odoo doesn’t model that out of the box. Its depreciation engine is asset-date-anchored by design — which is correct for the majority of standalone SMBs, and wrong for anyone reporting up into a group standard with its own period-alignment rules. The result: every asset that went in under the wrong assumption has a depreciation board that’s subtly, cumulatively off from what the parent company’s consolidation expects.
This almost never shows up as a dramatic error. It shows up as a small, nagging variance in a monthly close — the kind that’s easy to write off as rounding, until someone traces it back to two hundred assets all posting on the wrong dates.
Where it actually bites: correcting it at scale
Once the mismatch is identified, the fix in Odoo’s native UI is exactly what you’d expect from a well-built single-record form: open the asset, adjust the first depreciation date or method, and Odoo recomputes that asset’s board. It works perfectly — for one asset.
There is no native bulk editor for depreciation schedules. Odoo’s list views let you mass-edit simple fields across selected records, but the depreciation board itself is a computed, per-asset artefact — recalculating it in bulk isn’t exposed anywhere in the standard UI. If your migration or go-live left 40 assets on the wrong method, that’s an afternoon of tedious-but-survivable manual correction. If it left 300 or 3,000, it’s a multi-week project that nobody signed up for, done one form submission at a time, with every click carrying the risk of a fat-fingered date.
Why this is a bad candidate for “just write a script”
The instinct at this point is usually to reach for a one-off Python script against the database, or a bulk import that overwrites the generated depreciation lines directly. Both are riskier than they look:
- Depreciation lines are linked to journal entries. Some of those entries may already be posted. Overwriting the schedule without correctly reversing or adjusting posted moves creates orphaned or duplicate accounting entries — exactly the kind of thing an auditor will flag.
- Asset state matters. Draft, running, and closed assets each need different handling. A script that treats every asset record identically will happily corrupt a closed asset’s history along with the ones that genuinely need fixing.
- Rounding and prorata rules compound. A script that recalculates using a slightly different rounding convention than Odoo’s own engine will produce numbers that are close but not identical — which is worse than obviously wrong, because it’s harder to catch on review.
- It has to be re-runnable. Real corrections rarely happen in one pass. You find 280 assets, fix them, then discover another 30 that were missed because they were filtered out by a category you didn’t think to check. A one-off script gets thrown away after the first run; the problem doesn’t.
Why this is exactly the kind of gap purpose-built tooling should close
This is a narrow problem. It only matters to organisations whose depreciation policy diverges from Odoo’s default assumptions, and it only becomes urgent at volume — which is precisely why Odoo hasn’t built a general-purpose bulk-correction tool for it, and why no generic app on the marketplace covers it either. But narrow doesn’t mean small: get it wrong on a few hundred assets and it lands directly in your fixed asset register, your depreciation expense line, and your next statutory audit.
The right way to solve it looks less like a script and more like a proper module: a bulk-selection wizard that lets you filter assets by category, acquisition-date range, or current method; a preview step that shows exactly which depreciation lines will change before anything is committed; safe handling of posted versus unposted journal entries; and an audit trail of what was corrected, when, and by what rule. That’s the difference between a fix you can hand to your auditor with confidence and a fix you quietly hope nobody asks about.
If you’re staring down a fixed asset register that doesn’t match your actual depreciation policy — whether that surfaced during a migration, a group consolidation, or a first real audit — it’s worth talking through before anyone starts editing records one at a time.
