Odoo stamps every stock move and inventory adjustment with the server date at the moment you validate it. That is correct for live operations, but it breaks the moment you are entering history: an opening stock count captured a week late, a physical count reconciled at month-end, a goods receipt that arrived before your go-live, or a correction that auditors expect to sit on the date the event actually happened. Out of the box the stock.move and stock.move.line date fields are written programmatically at validation, the inventory-adjustment flow on stock.quant records now(), and the valuation layers in stock.valuation.layer inherit that same timestamp — so your stock ledger, your valuation, and your accounting periods all disagree with the real-world event date. Finance then sees inventory movement land in the wrong period, and there is no native, permission-gated way to say "this happened on the 3rd, not today."

ECOSIRE builds a dedicated Inventory Adjustment Backdate module that adds a validated, audit-controlled effective-date override to Odoo's stock engine. We introduce an effective_date (Datetime) field and a required backdate_reason (Text) field on the adjustment and move flow, wired through a targeted extension of stock.quant, stock.move, and stock.move.line. When an authorized user posts a backdated adjustment, an override on _apply_inventory() / the move validation path propagates the chosen date down to the resulting moves, move lines, and the generated stock.valuation.layer rows, so the on-hand history, the SVL journal, and the account move (when Anglo-Saxon/perpetual valuation is on) all carry the same effective date. Every backdate writes an immutable trail — who set it, the original system date, the new date, and the remark — via the standard mail.thread chatter and a dedicated log model, so nothing is silently rewritten.

The control layer is where a made-to-order build earns its price. We gate the ability to backdate behind a new security group in ir.model.access.csv plus record rules, so only a controller or inventory manager can override a date; everyone else follows the normal now() behaviour. We add a configurable guard rail — a maximum look-back window and an optional hard lock against posting into a closed accounting period — enforced with an @api.constrains validation and a clear ValidationError rather than a silent correction. The reason field is mandatory by constraint, the backdated documents surface a visible badge in the form and list views (XML in 17.0/18.0, OWL-aware where you are on 19.0), and we ship an audit report (QWeb PDF or list export) of every backdated movement over a date range for your finance and audit teams. Optional add-ons we scope on request: an automated action to flag out-of-window attempts, and an XML-RPC/JSON-RPC endpoint so a data-migration script can post opening balances at their true dates.

Because this is build-to-order, delivery works as a short engagement rather than a download. We start with a scoping call to confirm your Odoo version (17.0 / 18.0 / 19.0), Community vs Enterprise, your valuation method, and who is allowed to backdate. We then build against a copy of your environment, hand you the module on a staging database for UAT, and only deploy to production once you have signed off — with a rollback path ready. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company propagation, closed-period accounting locks, deep localization of the audit report, and bulk data-migration backdating via the API increase the quoted scope.