The AI Agent Audit Trail: What to Record When an Agent Touches Odoo 20 or MYOB Acumatica, and Where It Lives

An AI agent audit trail records, per run, what the agent read, what it drafted, which model and instructions produced it, who approved it and when. Odoo 20 keeps the approved change in the chatter and its Audit Trail report; MYOB Acumatica keeps it in Record Audit History and AI Automation History. As at 2 November 2026 neither records the agent’s reasoning, so that layer is yours to add.

At a glance

• Who it is for: CFOs, finance managers and owners of Australian businesses on Odoo or MYOB Acumatica who are about to let an agent draft bills, credit holds, orders or journals, and who will be asked “who did that?” by an auditor, a bank or a customer within the year.
• Problem it solves: the ERP logs the change a person approved but not the agent run that proposed it, so six months later nobody can say what the agent read, which instructions it was running, or why the person said yes.
• Platforms: Odoo 20 and 19 Enterprise (chatter, accounting Audit Trail report, secured journals, stored agent conversations, MCP API keys); MYOB Acumatica 2026.1 (Field-Level Audit, Record Audit History, Access History, AI Automation History, AI Units); any agent framework on your approved-tool list.
• What the trail records: the trigger, the identity the agent ran as, the records it read with their as-at time, the model and instruction version, the draft it produced, the person who approved or rejected it and when, the change actually written, and the exception if it stopped.
• Where it lives: the approved change in the ERP’s own audit features; the run record (inputs, model, draft, decision) in a store you control, linked to the ERP record by its ID.
• Who reads it: the approver at the time, the agent’s owner at the monthly review, the auditor at year end, and the OAIC or a customer if a decision is ever challenged.
• Retention: five years for anything that supports a tax record, per the ATO; at least twelve months for MYOB Acumatica’s security audit, per its own minimum.
• What it never contains: API keys, the unmasked personal data of customers or staff, or a prompt copied into a third-party tool that is not on the approved list.
• Typical cost: the run store is a day or two of build inside an agent pilot from $5,000 ex GST per our AI agents for ERP in Australia hub, as at 2 November 2026; Odoo 20 AI features draw IAP credits on top of the licence.
• Typical timeline: switched on before the agent’s first production run, never after.
• Last verified: 2 November 2026 against the Odoo 20 chatter documentation, the Odoo 20 release notes, MYOB’s field-level auditing guide, MYOB’s AI Automation statistics release note and the OAIC’s automated decision-making transparency notice.

A credit controller in Brisbane approves an agent’s recommendation to put a customer on hold. Four months later the customer’s accountant rings the CFO and asks why. The ERP shows the hold flag changed on 14 July at 9:42 by the credit controller. It does not show that an agent proposed it, that the agent read an aged debtors report with one disputed invoice in the 60-day column, or that the controller approved it in eleven seconds between two other drafts. The CFO has a change record and no story.

That is the gap an AI agent audit trail closes. The ERP already records the change. What it does not record is the run that led to it.

What should an AI agent audit trail record?

An AI agent audit trail is the set of records that let a person reconstruct one agent run after the fact: what triggered it, what it read, what it produced, who decided, and what changed. It is separate from the ERP’s own audit of the final change, and it has to be, because the ERP never saw the draft.

We record nine things for every agent we run over a client’s Odoo or MYOB Acumatica, and the list has not changed since the first one.

1. The trigger. A schedule, an inbound email, a person’s question, or a business event, with its timestamp.
2. The identity. Which ERP user or API key the agent ran as, so its reads can be checked against that user’s permissions. A shared super-user here makes the rest of the trail worthless, which is the argument in our MCP server permissions post.
3. The inputs. The record IDs it read and the time it read them. An aged debtors balance at 9:40 is not the balance at 2pm.
4. The model and instructions. The model name and version, and the version of the agent’s instructions, skills and tools. When an instruction changes, the number goes up.
5. The draft. The full output the person saw, including any sources or citations the agent attached.
6. The decision. Who approved, rejected or edited the draft, when, and what they changed before approving.
7. The write. The change actually applied to the ERP, with the ERP’s own record ID, so the two trails can be joined.
8. The exception. If the agent stopped, hit a tool limit or asked a question, what it asked and who answered.
9. The cost. IAP credits, AI Units or tokens consumed, so the running cost per agent can be reconciled.

The OAIC’s guidance on commercially available AI products puts the same idea in regulatory language. It says an entity’s records should clearly indicate where information is the product of an AI output, and therefore a probabilistic assessment, not a fact, along with the data and system used to generate it. Items 3, 4 and 5 are that sentence in practice.

Where does Odoo 20 keep the trail?

Odoo’s answer is the chatter. The chatter documentation describes it as a record of the updates and edits made to a record, with a log note posted when a tracked field changes, carrying the time stamp, the previous value and the new one. Changes made by an import or by the system are credited to OdooBot. Log notes are visible only to internal users, which is what you want for an audit record.

Odoo 20 changed how that works underneath. The release notes say tracking values have been removed and the tracking message is now generated on the fly, with a dedicated module for admins who still need the values as data. The same release adds a chatter filter to show only tracked changes, records the source of mail postings to ease auditing, and logs user group changes in the user’s chatter as well as the console. Note the limit the documentation states openly: users with admin-level access rights can edit any sent message. The chatter is a good record. It is not a tamper-proof one.

For the ledger, Odoo has a stronger tool. The Audit Trail report under Accounting, Review, Audit Trail tracks changes to fields that affect accounting, with the date and time, the user, the type of change, the previous value and the updated value, and a Restrictive Audit Trail setting that stops those records being deleted (they can only be cancelled or archived). Journals can be set to Secure Posted Entries with Hash, which gives each secured entry a SHA-256 fingerprint, after which the feature cannot be switched off and the entries cannot be edited. Lock dates, including the irreversible Hard Lock date, log every exception and its reason in the chatter of the company record.

On the AI side the trail is thinner, and the documentation is candid about it. Conversations with agents are stored for up to 30 days after the last message, and when an agent is summoned by an automated or scheduled action you can check the automation chat to see how it handled the run. Agents assigned no skills can only provide information; with the Create Records or Update Records skills they can write, and the person approves permission requests by clicking buttons. The MCP server authenticates every request with an API key scoped to MCP, so the agent runs as the user who issued the key and each connection shows up in that user’s security preferences. Two things the documentation does not describe: a per-request log of MCP calls, and a per-request log of IAP credit usage beyond the balance on the View My Services page. If an auditor asks what the agent read through MCP on a given morning, Odoo 20 as documented cannot tell them. Your run store can.

That 30-day conversation window is the number to notice. A tax record lives five years. An agent chat that explains a journal lives a month, unless you copy it out.

Where does MYOB Acumatica keep the trail?

MYOB Acumatica has had a field-level audit for years, and it is more complete than most of its users have switched on. The implementation guide walks through it: enable the Field-Level Audit feature on the Enable/Disable Features form (CS100000), configure the Audit History Access role on User Roles (SM201005), then on the Audit form (SM205510) pick each form to audit and tick Active. From then on, Settings, Audit History on any audited form opens Record Audit History (SM205540) for that record, and Audit History by Screen (SM205530) shows the user, the date and time, the operation and the columns that changed, with a blank column meaning the value was unmodified. The one caveat worth planning for: the help notes a limit of 1,000 history records for each source form before the collapsed view stops at date, screen and user.

A second layer is always on. System-wide security auditing records login, failed login, logout, screen accessed and customisation published events, plus OData refreshes of generic inquiries, on Access History (SM201045) with the username, operation, host, IP address and screen ID. The retention period is set on Security Preferences (SM201060) with a twelve-month minimum. An agent reading MYOB Acumatica through a generic inquiry over OData leaves a line here under the user it authenticated as, which is the identity record from item 2 above.

The AI features got their own log in 2026.1.1. The AI Automation statistics release note says the system now collects statistics on your LLM prompts, connections and commands, and that each operation adds a record to the history form (ML400000, named AI Studio History in the release note and AI Automation History in the current user guide, after the rename). The data masking note for the same release says the real values of masked fields stay within the system and are never shared with the LLM, which matters for what your trail may contain. The AI Assistant stores each chat’s questions and answers, lets the user delete a chat, and meters consumption as AI Units on License Maintenance (SM201510). MYOB’s AI page adds that conversation history stays within the platform and is stored in Australia, and that customer data is not used to train external models.

What MYOB Acumatica does not do, as documented, is tie an AI Automation prompt result to the record a person then changed. The history form shows that a prompt ran; the audit history shows that a field changed; the join between them is yours. We cover the hand-off itself in the AI Automation post and the chat’s access rules in the AI Assistant setup post.

A worked example: the credit hold, and what the auditor sees

Take a Queensland equipment hire company on Odoo 20 running the credit management agent each weekday at 7am. On 14 July it reads aged receivables, open orders and the last 90 days of payment behaviour for every account over its limit, and drafts three recommendations. One is a hold on a customer with $38,400 overdue, including a $9,200 invoice the customer disputed in June.

The run store writes: trigger, the 7:00 schedule; identity, the API key issued to the credit controller’s own user with MCP scope; inputs, the 14 partner, invoice and order IDs read between 7:00:04 and 7:00:11; model and instruction version 1.7, which had added the rule “flag any disputed invoice in the overdue total” the week before; the draft, with the disputed invoice flagged and a recommended hold pending the dispute; and the cost, in IAP credits.

At 9:42 the credit controller reads the draft, removes the disputed invoice from the overdue figure, sees $29,200 still past 60 days, and approves the hold with a note. The run store records her, the time, and the edit. Odoo records the hold on the partner in the chatter under her name, with the previous and new value and the time stamp. The run store keeps the chatter message ID.

In November the customer’s accountant asks why. The CFO opens the run, sees the agent’s draft, the disputed invoice flagged, the controller’s edit and her note, and answers in five minutes with the numbers as they stood that morning. Without the run store she has a chatter line and a memory.

The ERP’s audit trail tells you what changed and who clicked. It cannot tell you what the agent read or why the person agreed, because the ERP never saw the draft. If you only keep one extra thing when you switch an agent on, keep the draft the person approved and the record it became.

Josh Craig, Director, Auboros

How long do you keep it, and who can read it?

Three Australian sources set the floor. The ATO’s record-keeping rules say most business records must be kept for five years, generally from when the record was prepared or the transaction completed, whichever is later. An agent draft that explains a journal, a credit note or a bill is part of the record that supports it, so it inherits the five years. That is the reason Odoo’s 30-day agent conversation window and MYOB’s twelve-month security audit minimum are starting points. Neither is a retention policy.

From 10 December 2026 the OAIC says APP entities must include information in their privacy policy where a computer program makes or informs decisions that significantly affect an individual’s rights or interests, including the kinds of personal information used and the kinds of decisions made solely by the program. A credit hold on a sole trader can be that kind of decision. The trail is how you know which decisions the agent informed and which a person made, and we walk through the policy wording in our automated decision-making post.

The National AI Centre’s Guidance for AI Adoption, published 21 October 2025, asks businesses to document every activity under its six practices so they can audit and review their governance, to create and maintain an AI register, to set up monitoring that detects changes in performance and behaviour, and to document and analyse AI-related incidents. It is voluntary. It is also what a reasonable-steps argument under APP 1 will look like if one is ever needed. The ACSC’s event logging guidance adds the security view: an approved logging policy, centralised access, secure storage with log integrity, and retention long enough to support an investigation, with a warning that default retention periods are often insufficient.

Who reads it is simpler. The approver reads the draft at the time. The agent’s owner, named in your AI agent register, reads a sample monthly. The auditor reads it at year end. In MYOB Acumatica that means the Audit History Access role for the owner and the auditor’s user and nobody else; in Odoo it means keeping the run store outside the reach of the admin accounts that can edit chatter messages.

Where it goes wrong

• Logging the prompt into the wrong place. The easiest trail to build pipes every prompt and response into a third-party observability tool. If that tool is not on your approved-tool list, you have just created a second copy of customer data outside the ERP. Keep the run store under the same access rules as the ERP.
• Treating the chatter as tamper-proof. It is a record. Admin users can edit sent messages. For anything an auditor will rely on, use the hashed journals and the Audit Trail report, and keep the run store append-only.
• Hitting the 1,000-record cap. An agent that touches the same MYOB Acumatica form hundreds of times a day will reach the per-form history limit in weeks. Audit the forms that carry approvals, and let the run store carry the volume.
• Keeping twelve months of a five-year record. Retention defaults are set for logins, not ledgers. Set the run store to five years on day one.
• A trail nobody reads. A run store that is never sampled is a liability with a timestamp. The monthly review in the register exists so that someone opens ten runs and checks the drafts still make sense.
• A shared super-user. If every agent runs as “integration”, item 2 is blank on every run and the ERP’s own audit shows the same name for every change. Run each agent as a scoped user and the ERP does half the trail for you.

Goes well with

• The AI agent register: the trail answers “what happened on this run”; the register answers “who owns this agent and when was it last reviewed”.
• AI agents and automated decision-making in your privacy policy: the 10 December 2026 obligation the trail helps you meet.
• The approval gate is in the code: how to make the decision in item 6 a real step instead of a formality.

Before the first agent run, decide what you’ll be able to say about it in five years

Auboros designs drafts-first AI agents over Odoo and MYOB Acumatica from Brisbane, and every one we run for a Queensland or interstate client starts with the run store and the ERP’s own audit switched on, before the first draft. If you’re about to let an agent near your ledger, your credit holds or your orders and you want the trail designed before the auditor asks, book a free 1-hour scoping call. We’ll map the nine fields to your platform in the first hour, and if your ERP already covers most of them, we’ll say so.