Usage-Based Depreciation in Odoo: Where RFID Data Legitimately Fits

Someone asks whether RFID can drive depreciation. The honest answer is that it cannot, and that the useful version of the question is different: can RFID produce evidence good enough to change how a depreciation policy is applied?

Depreciation is an accounting decision, not a sensor output

The rules come from accounting standards and tax authorities, not from a reader.

• Useful life and method are determined by policy, and changing them requires justification and approval.
• A sensor can inform a review; it cannot post an entry on its own.
• Usage-based depreciation exists, but it is a defined method (units of production), not a data feed.
• Any deviation from straight-line needs documentation that an auditor will accept.
• The correct integration point is the periodic review, not the nightly job.

What RFID actually measures

Be precise about the observable, or the analysis becomes fiction.

• Presence at a location, at a time, with a confidence level.
• Movement between zones, inferred from consecutive reads at different read points.
• Absence, which is only meaningful when coverage is known to be complete.
• Nothing about intensity of use unless read points are placed where work actually happens.
• Nothing about condition, unless the process records inspection events separately.

From reads to usage metrics

The transformation needs a model, not a query.

• Define the asset's "active location" as the zone where it was most recently observed with high confidence.
• Count distinct days with at least one observation, which is more robust than raw read counts.
• Count zone transitions per month as a proxy for deployment intensity.
• Exclude the commissioning period and known maintenance windows from the baseline.
• Publish the metric definition next to the number, because definitions get argued about more than values.

Mapping usage to useful life without inventing numbers

The policy has to survive an audit, so the mapping must be simple and explicit.

• Define bands: idle (below a threshold of active days), normal, heavy.
• Assign the same standard life to idle and normal assets, and only consider a shortened life for heavy use.
• Require a minimum observation period, typically two to three quarters, before any reclassification.
• Cap any adjustment, and require a second approval beyond a defined threshold.
• Never adjust life on assets below the capitalisation threshold, where the accounting effort outweighs the effect.

Where this fits in Odoo's asset model

Odoo already models assets, categories and depreciation boards; the job is to feed them.

• Keep the asset record as the master, and attach usage metrics as a related dataset with its own period.
• Use asset categories to carry the default life and method, and override at the asset level only when justified.
• Prepare a monthly usage report that finance can review, rather than writing values directly.
• If you automate, automate the report and the review queue, not the journal entry.
• Keep the usage history immutable, so a reclassification can be explained two years later.

Idle assets are the real target

The financial win is usually a disposal or redeployment decision, not a depreciation tweak.

• An asset idle for two quarters is a candidate for redeployment to another site.
• An asset idle for four quarters and not strategically held is a candidate for disposal.
• Quantify idle capital, because that number moves management faster than any life adjustment.
• Route idle findings to operations, not to accounting, and let accounting record the consequence.
• Track redeployment success, because moving an asset and then leaving it idle again is a common outcome.

Maintenance and condition, not just motion

A hard-working asset and a worn-out asset are different questions.

• Usage intensity is an input to maintenance planning, which is where the operational return sits.
• Pair usage with service records, so a heavily used asset gets inspected on a shorter interval.
• A sudden drop in usage can indicate a fault, and is worth an alert, not a depreciation change.
• Condition data comes from inspection, not from reads; keep the two separate.
• Never infer condition from movement, or you will retire healthy assets and keep broken ones.

Audit and tax constraints

The cautious version is the version that survives.

• Many tax regimes prescribe minimum lives, so a shortened life may be acceptable for management reporting only.
• Keep statutory and management depreciation in separate views where the regimes diverge.
• Document the data source, the metric, the threshold and the approval for every change.
• Retain the raw observation history for the period in which it justified a decision.
• Get the accounting firm's view early, because retrofitting compliance is expensive and visible.

A worked policy, stated plainly

An example makes the whole design concrete.

• Assets are reviewed annually, at the fiscal year end, using twelve months of observation.
• Heavy-use classification requires at least 220 active days and at least 30 zone transitions per quarter.
• Heavy-use assets may take a 20 percent reduction in remaining life, subject to controller approval.
• Idle assets are reported to operations; disposal follows a separate approval process, not depreciation.
• All other assets keep the category default, and the review records why no change was made.

Reconciling reads against the asset register

A read only counts if it resolves to exactly one asset record.

• Duplicate or reclaimed asset codes break the metric silently, and the failure looks like usage.
• An asset never observed may never have been tagged, which is a different finding from being idle.
• Reconcile monthly: assets with no reads, reads with no matching asset, assets carrying two tags.
• Keep the reconciliation output next to the usage report, because both answer different questions.
• Publish the reconciliation rate as the data-quality metric for the whole programme.

Governance: who signs off

A quarterly review with named roles is worth more than any automation.

• Operations owns the usage data and its quality.
• Finance owns the policy, the thresholds and the journal effect.
• Internal audit or the controller approves any life adjustment and keeps the evidence.
• IT owns the pipeline and the reconciliation between reads and assets.
• Review the policy annually, and record the decision even when nothing changes.