Every SoX, ISO 27001, or external-audit engagement eventually asks the same question your Odoo instance struggles to answer cleanly: "Who changed this journal entry, when, and what was the value before?" Odoo Enterprise ships base.audit.log (mail.thread chatter tracking) that records tracking = True field changes on a handful of models, but that coverage is inconsistent across accounting objects, is scattered per-record instead of centralized, and — crucially — is stored in ordinary writable tables that a user with the right access can edit or a write() can overwrite. Odoo Community has even less. For a controls environment you need a single, query-able, non-repudiable ledger of change, not a pile of chatter messages, and you need it to survive an auditor asking to export twelve months of modifications to a specific bank account or tax code.

ECOSIRE builds a dedicated audit-trail module that centralizes change capture across the accounting stack. We add an ecosire.audit.log model (models.Model) whose rows are written by ORM create/write/unlink overrides on the models that matter to your controls scope — typically account.move, account.move.line, account.payment, account.account, account.tax, and res.partner bank details. Each row stores the model, record id and display name, the acting res.users, a precise UTC timestamp, the source IP and session captured from the request context, the operation type, and a per-field old_value/new_value diff serialized as JSON. Field-level compute helpers (@api.depends-driven where a derived view is useful) render the diff into a readable QWeb report so an auditor sees "amount_total: 12,400.00 → 14,900.00" rather than raw JSON. Log rows are made tamper-evident: the model has no write/unlink access for any user (enforced via ir.model.access.csv granting create+read only, plus a record rule blocking edits), and each row carries a chained SHA-256 hash of the previous row so a deletion or in-place edit at the database level breaks the chain and is detectable on the verification report.

On top of capture we build the controls reporting auditors actually request: a segregation-of-duties report that flags where the same user both created and posted a journal entry, or both created a vendor and paid it; tamper-evident locking that hardens Odoo's posted-entry and fiscal-lock behavior with an explicit "sealed" state; and filtered exports (XLSX/PDF via QWeb) scoped by date, user, model, or record. The whole log is exposed read-only through the standard XML-RPC/JSON-RPC API so your GRC tooling or an external SIEM can pull it on a schedule. Optional automated actions / ir.cron jobs run the hash-chain verification nightly and email compliance if integrity is ever broken.

Because this is a controls module, it is build-to-order rather than a one-click marketplace install. We start with a short scoping call to fix exactly which models and fields fall inside your audit boundary, which SoD rules apply to your org chart, and your Odoo edition and version (17.0 / 18.0 / 19.0, Community or Enterprise). We then build against a copy of your configuration, validate on a staging database with your real chart of accounts, run UAT with your compliance team, and deploy behind a rollback plan. Typical delivery is one working week from confirmed scope. You receive the full source, the git repository, and a support window after go-live.