Subscription, SaaS, and service businesses routinely invoice up front for value delivered over months or years — annual licenses, retainers, prepaid support, multi-period maintenance. Under IFRS 15 / ASC 606 you cannot recognize that cash as revenue on the invoice date; it has to be released to the P&L as the performance obligation is satisfied. Odoo's native deferred revenue/expense handling covers the straightforward case (a start/end date and a linear split posted by a scheduled action), but real recognition policies quickly outrun it: mid-period contract modifications, partial credit notes, catch-up on a late-started contract, prorated first/last periods, multi-currency contracts, and audit-ready schedules that tie every recognized cent back to a source invoice line. Teams end up maintaining the true schedule in a spreadsheet and posting manual journals — exactly the error-prone, un-auditable process the ERP was supposed to remove.

ECOSIRE builds a dedicated recognition engine into your Odoo. At its core is a deferred.schedule model (models.Model) that owns the recognition plan for each source line, with one deferred.schedule.line per period carrying its computed amount, planned recognition date, posted state, and a link back to the account.move.line it derives from. Period amounts are @api.depends-computed from the method you choose — straight-line, days-based proration, or a custom curve captured as a percentage table — so changing a contract's dates or value re-derives the remaining unposted periods without touching what's already recognized. Recognition postings are generated as proper account.move entries (deferred liability/asset account to the P&L account on your product or fiscal position), driven by an ir.cron automated action that sweeps due lines on your close cadence and is idempotent, so re-running it never double-posts. The same framework runs in reverse for prepaid expense amortization — insurance, prepaid rent, prepaid software — releasing a deferred asset to expense on the identical schedule mechanics.

Everything is exposed where accountants already work. A dedicated menu and list/form views (XML, OWL widgets in 17/18/19) let controllers review, adjust, pause, and post schedules; a QWeb report produces the period-by-period recognition waterfall your auditors ask for; and access is locked down with ir.model.access.csv plus record rules so only the accounting group can post and multi-company/multi-tenant boundaries are enforced. Recognition is reconcilable against the deferred balance-sheet accounts, and schedules are queryable over the standard XML-RPC / JSON-RPC API for BI tools or a parent-consolidation feed. We build against your chart of accounts and revenue-recognition policy rather than forcing a generic one, and we account for Community vs Enterprise differences — where Enterprise ships partial native deferred features we extend and reconcile with them rather than duplicating.

Because this is build-to-order, nothing ships blind. We start with a scoping call to capture your recognition policies, contract types, GL structure, and edge cases, then build the module for your exact Odoo version (17.0, 18.0, or 19.0), validate it on a staging copy of your database with your real contracts, and hand over installable source, documentation, and a git repository. Typical delivery is one working week from confirmed scope, and every engagement includes a post-go-live support window plus a documented rollback path.