Audit Trail & SoX Compliance Log

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 2–4 weeks from confirmed scope. You receive the full source, the git repository, and a support window after go-live.