Picture a familiar year-end conversation: the auditor finds a vendor paid twice in the second quarter, the board asks why nobody noticed, and the honest answer is that the payment sat in Odoo for nine months while everyone waited for the annual audit. We wrote about that gap in why an annual audit misses eleven months. The fix is not more auditors. It is a connection that reads the books every day and raises the question while the money can still be recovered.
Connecting AI to an ERP is easy to demonstrate and easy to get wrong: the connection is a new user that sees everything the auditor sees, often run by a third party, often processing data outside the company. This article sets out the design decisions in the order an auditor would check them.
What does connecting AI to Odoo for continuous auditing mean?
Connecting AI to Odoo for continuous auditing means giving an analysis layer governed, logged and read-only access to the ledger, so that tests run on the full population on a schedule and every result points back to the records it came from. Two words in that definition carry the weight. Governed means someone owns the connection, its rights and its output. Points back means a finding can be reopened in Odoo by anyone who doubts it.
It fits the monitoring component of COSO’s Internal Control, Integrated Framework (2013): Principle 16 calls for ongoing and separate evaluations, and a daily test run is an ongoing evaluation. For how this differs from the annual cycle, see continuous auditing with AI vs traditional auditing.
Which connection route should you use: API, MCP or in-database agents?
Three routes lead into the data and one goes around it, each with its own control profile.
| Route | How it reaches the data | Best suited to | Main control |
|---|---|---|---|
| External API (XML-RPC / JSON-RPC) | A dedicated API user and key query the database; long available in recent Odoo versions, confirm in your 20 database | Scheduled full-population tests run by an outside platform | Dedicated user, read-only rights, key rotation, access log review |
| MCP connection | Odoo’s 20 release notes list connecting to the database via Model Context Protocol, so AI tools can query it | Interactive questions from an AI assistant during an engagement | Confirm in your database which user and rights it runs under before enabling |
| Odoo’s own AI agents | Agents run inside the database, triggered by automated or scheduled actions | Operational checks owned by the finance team | Agent owner, draft state for output, IAP credit budget |
| Exports and spreadsheets | Someone extracts data and sends a file | One-off analysis | Completeness check against the trial balance; no ongoing coverage |
For continuous auditing the external API is usually the backbone, because it is independent of the people being audited and can run on a fixed schedule. MCP is useful for an auditor asking follow-up questions, but treat it as a new access path with its own approval, not as a feature to switch on. The finance-side view of these features is in our feature map of Odoo 20 AI for accounting.
Why should the audit connection read only?
Because the auditor must not be able to change what the auditor tests. If the connection can write, a finding and its fix can come from the same identity, which breaks the segregation of duties the audit is meant to test. ISA 315 (Revised 2019) asks auditors to understand the IT environment and general IT controls; an audit connection with write rights is exactly the kind of access that understanding should flag.
- Create a dedicated user for the connection. Never reuse a person’s login or an administrator account.
- Grant read access only to the models the tests need: journal entries, invoices and bills, payments, partners, products and stock valuation.
- In Odoo 20, record rules are removed and the domain is set directly on the access right, so review that domain as part of the setup.
- Issue an API key for that user alone and record who holds it and when it will be rotated.
- Review the user’s chatter monthly: Odoo 20 logs user group changes there, so any widening of rights leaves a trail.
- Test the restriction: attempt a write with the key and file the refusal as evidence that read-only holds.
Read-only applies to the connection, not to everything AI does. MFT’s seg-audit platform reads the books straight from the ERP, read-only. Our Auditor agent does more: it drafts correcting entries and adjustments, but drafting is not posting, and nothing reaches the ledger without approval. For segregation of duties when an agent is in the chain, see AI, segregation of duties and internal controls.
Where does the data go, and who keeps it?
Data residency is the question owners ask last and should ask first. A connection that copies the whole ledger to an outside store creates a second set of books, outside your controls and possibly outside your country. Ask every provider, including us, the same questions:
- Is client data stored by the provider, or read at query time and discarded?
- In which country is it processed, and by which AI model provider?
- How long are prompts, answers and logs kept, and can they be deleted on request?
- Who at the provider can see the data, and is that access logged?
- Does the provider’s contract match your data-protection obligations, as confirmed by your legal adviser?
Our own answer is that client data stays on the client’s system and our agents read through the API at query time. Odoo’s native AI has its own retention rule: according to the release notes, stored conversations are kept up to 30 days after the last message. Know both rules before anything goes live.
Which tests should run continuously?
Start with tests whose exceptions are cheap to verify and expensive to miss. These are the patterns that recur in our continuous-audit work:
- Duplicate and near-duplicate payments: same vendor, similar amount and reference, close dates.
- Near-duplicate vendors: similar names, shared bank accounts or tax numbers.
- Approvals outside the approval matrix: bills or orders approved above the approver’s limit.
- Cut-off errors: receipts and bills recorded in different periods around month end.
- Inventory valuation drift between the stock valuation and the general ledger.
- Manual journal entries posted late at month end in round amounts, which ISA 240 already requires auditors to test.
Each test reads the whole population, not a sample, which is the subject of moving from sampling to full-population testing. The ACFE’s 2024 Report to the Nations found the median fraud lasted 12 months before detection, and that proactive data monitoring and analysis was among the controls associated with roughly half the losses and duration. A daily test proves nothing alone; it shortens how long a problem stays hidden.
How does an AI finding become audit evidence?
Only by pointing at the records. ISA 500 asks whether evidence is sufficient and appropriate, and ISA 230 asks that documentation let an experienced auditor understand what was done. An AI sentence meets neither. A finding that lists the record ids it retrieved, the rule that flagged them and the time of the query meets both, because anyone can reopen those records in Odoo.
If a finding cannot name the records it read, it is not a finding. It is a rumour with a confidence score.
That is the rule MFT Intelligence runs on, which we call "evidence or silence": every finding must cite the record ids the agent actually retrieved, and a finding that cites nothing, or quotes a number not in the cited records, is rejected and shown struck through, never as fact. The details are in our article on AI provenance and the zero-hallucination principle. The standards are moving too: in August 2026 the IAASB issued exposure drafts revising ISA 500, ISA 330 and ISA 520 to address greater use of technology, with comments due 15 December 2026. They are not final, so build on the current standards.
Who approves what the AI proposes?
A named, registered person, never the connection and never the person who asked for the run. Our rule set, described in agents draft, people approve, is:
- The agent drafts the correcting entry or adjustment; nothing is posted automatically.
- Approval is tiered by the client’s ISA 320 materiality threshold: above it, a second approver signs.
- Corrections are made by reversal, never by deletion, so the original stays visible.
- In seg-audit, a finding cannot be closed without a named, registered approver, and repeats are linked to earlier findings.
Live Odoo write-back of approved corrections is delivered per client, only after that client’s connector is configured. Until then, approved corrections are entered by the client’s own team, which keeps the posting under their controls.
Where should you start?
- Write down the purpose of the connection, its owner and the tests it will run.
- Create the dedicated read-only user and key, and test that a write is refused.
- Get written answers to the five residency questions above.
- Run three tests on a closed quarter first, such as duplicate payments, near-duplicate vendors and late round-amount journal entries, and calibrate false positives.
- Agree who reviews exceptions, in what time frame, and who approves corrections.
- Review the connection’s log, rights and findings monthly, as you would any privileged user.
This is the work behind our internal audit service: seg-audit reads the books read-only, scores every transaction by risk instead of sampling a few percent, and keeps each finding on record with evidence and severity. If your Odoo 20 rollout is still ahead, combine this with the step-by-step guide to AI accounting on Odoo 20.