In standard Odoo, an inventory adjustment applies immediately. The moment a warehouse user sets a counted quantity on stock.quant (or validates an Inventory Adjustment document) Odoo writes the stock.move and stock.move.line records, updates the on-hand balance, and posts the stock.valuation.layer that revalues inventory into your general ledger. There is no native gate between "someone typed a number" and "the books changed." For teams with real exposure — high-value SKUs, tight audit requirements, or several people holding stock-editing rights — a mistyped count or an unauthorized write-off moves inventory valuation before anyone with authority ever sees it. Segregation of duties becomes a manual, after-the-fact reconciliation exercise instead of a control.

Inventory Adjustment Approval closes that gap. We build a module that intercepts the adjustment posting and routes it through a configurable approval workflow before any quant change or valuation impact is allowed. Technically, the pending change is captured into a dedicated request model (a models.Model inheriting mail.thread and mail.activity.mixin for chatter, followers, and scheduled activities) carrying the product, location, theoretical vs. counted quantity, computed difference_qty (via @api.depends compute), reason code, and attachments. A state machine — draft → to_approve → approved / refused → done — governs whether the underlying stock write is permitted. We override the apply/validate path so the physical quant update and its valuation layer only fire once the request reaches approved; a refusal leaves on-hand untouched and keeps the full audit trail in the chatter.

The workflow is designed around your real controls, not a fixed template. Routing can be threshold-based (auto-approve differences under a configurable quantity or valuation amount, force review above it), tier-based (multi-level sign-off for large write-offs, resembling Odoo's studio-style approval tiers), or segregated by warehouse, product category, or location using ir.rule record rules so a reviewer only sees requests in their domain. Access is enforced with a purpose-built approver group in ir.model.access.csv plus record rules — the requester can create and submit but never self-approve. The UI is delivered as standard XML views (list, form, kanban of pending requests, and search filters), with buttons wired to the state transitions, an optional QWeb PDF for the signed adjustment record, and automated actions or scheduled ir.cron reminders for requests sitting too long. Every transition can be surfaced over Odoo's XML-RPC / JSON-RPC API for external dashboards or a mobile approval flow. It runs on Odoo Community or Enterprise; where Enterprise-only building blocks (such as the native approvals or studio layers) exist, we implement equivalent logic in the module so the behavior is identical across editions, and we support Odoo 17.0, 18.0, and 19.0.

Because this is build-to-order, delivery starts with a short scoping call to confirm your approval tiers, thresholds, edition, version, and any multi-company or localization needs. We then build against a copy of your database, validate on staging with your data, and hand over installable source, documentation, and a support window. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); additional approval tiers, multi-company routing, deeper accounting/valuation integration, or migration of historical adjustment data increase the quoted scope.