Odoo and itsme: governing qualified electronic signatures
The announced integration between Odoo Sign and itsme brings strong identity evidence closer to the business process. Its value is not limited to the signature itself: it depends on selecting the right assurance level, retaining evidence, and controlling every automation that prepares or triggers a document.
1. What was announced
On 30 September, Odoo and itsme announced the integration of qualified electronic signatures into Odoo Sign with Odoo 20. Odoo says users will be able to identify themselves through the itsme application and obtain a certificate issued by a qualified trust service provider without leaving the Odoo workflow. A qualified signature is the highest assurance level defined by eIDAS and has the legal effect of a handwritten signature.
Odoo says this option will complement its simple and advanced signatures. It is intended for powers of attorney, important contracts, documents submitted to authorities, selected HR processes, and regulated activities. The announcement does not mean every document requires the qualified level.
2. What changes for a Belgian or French company
For an SME, mid-market company, large group, or public administration, verified identity can now remain within a more continuous ERP process. This reduces breaks between preparation, approval, signing, and archiving. The value is particularly tangible in Belgium, where itsme is widely used, while the announcement says the application is available in 32 European countries, including France.
The operational benefit needs a document matrix: contract type, authorised signatories, required signature level, retention period, personal data processed, and delegation rule. Applying the highest level systematically would add cost and friction without replacing legal analysis of the process.
3. Evidence must cover the full workflow
A qualified signature protects the signing act; by itself, it does not prove that the data inserted into the document was accurate or that the correct version was approved. An organisation should link the final document to the template version, Odoo data used, internal approvals, signatory identity, and retained evidence file.
Permissions deserve the same attention: the people who prepare a contract, authorise its dispatch, and modify templates should not automatically have the same powers. Logs, access revocation, and exception procedures should be tested before rollout.
4. Underside analysis: separate automation from authority
In Odoo Enterprise, an AI agent can already help extract data, draft a document, or select a workflow. A qualified signature must not turn that assistance into implicit authority. An agent can prepare; a deterministic rule and an identified accountable person should decide the assurance level, recipients, and final trigger.
For contractual RAG, sources and their versions must remain attached to the file. For local or cloud AI, model residency is not enough: data sent to itsme, the trust provider, connectors, and logging services must be mapped. Sovereignty here means being able to explain, export, and replay the evidence chain.
5. Implementation plan
Start with one high-value document, define its signature level with legal and security teams, then test roles, failed identification, revocation, archiving, and evidence retrieval. Measure processing time, abandonment, and exceptions before extending the setup to other processes.
Priority: build a “document, risk, signature level, approver, retained evidence” matrix and prevent any automation or AI agent from bypassing that separation of responsibilities.
Govern an Odoo workflow