The purchase approval that fails most often is the one configured on the wrong document. A manager’s validation is set on orders above a threshold, and the threshold quietly becomes a target: two orders just below it instead of one above it, a bill entered with no order at all, a vendor’s bank account changed by the same person who releases payments. Approvals outside the approval matrix are a recurring finding in our continuous-audit work, and few involve a broken setting.
Odoo 20 adds AI agents that run from automated actions, and several purchasing and payables improvements. Neither replaces the approval matrix. Here is how to build that matrix into Odoo 20 so that automation routes, AI drafts, and the evidence of who approved what survives an audit.
What is purchase approval automation in Odoo 20?
Purchase approval automation is the set of ERP rules that routes each purchase request, order, bill and vendor change to an authorised approver by amount, category and risk, holds the next step until approval is recorded, and keeps that record as evidence. Automation routes and blocks; a person decides. There are three layers:
- The rule: who may approve what, up to which tier, independent of whom. Finance owns it.
- The mechanism: the Odoo setting, app or automation that applies the rule to a document.
- The evidence: the chatter entry, approval record, activity or signature showing a named person applied the rule on a date.
How do you build the approval matrix before configuring anything?
Start from events, not screens. A purchase cycle has six events that can need approval: the need, the commitment, the receipt, the bill, a vendor master change, and the payment. For each, decide the trigger, the approver, and whose work that approver must be independent of. Set the amount tiers from your planning materiality, as discussed in setting a materiality threshold under ISA 320, rather than from round numbers chosen at go-live.
| Event | Approval trigger | Approver (independent of) | Odoo mechanism to confirm in your 20 database | Evidence kept |
|---|---|---|---|---|
| Non-routine request | Spend outside replenishment rules | Budget owner (not the requester) | Approvals app category (Enterprise) | Approval record |
| Purchase order, tier 1 | Order total above the first tier | Purchasing manager (not the buyer) | Purchase Order Approval setting | Validation in the order chatter |
| Purchase order, tier 2 | Above the second tier, capital spend, or new vendor | Finance manager (second approver) | Approvals app, or automation rule triggering an activity plan | Approval record or completed activity |
| Vendor creation or bank change | Every change | Finance reviewer (not purchasing, not payments) | Automation rule triggering a review activity plan | Completed activity, vendor chatter |
| Vendor bill | No order, or outside tolerance | Payables lead (not the buyer) | Bill control on received quantities, order matching, duplicate warnings | Match summary, resolved warning |
| Payment | Every batch | Treasury approver (not the payables clerk) | Payment rights limited to a named group | Payment record and bank confirmation |
Two rules make the matrix hold. The approver is independent of the work approved, as covered in segregation of duties in Odoo and, once agents act in the system, of AI agents inside segregation of duties. And every row names its evidence: an approval nobody can show did not happen.
Which Odoo mechanism should carry which approval?
These are long-standing features; confirm each one’s behaviour in your own Odoo 20 database and edition.
The Purchase Order Approval setting
In recent Odoo versions, the Purchase settings include an order approval option: orders above an amount you set need a manager’s validation before confirmation. It sits on the document, which makes it good evidence. Its limits are clear: one amount for all categories, one level, and nothing that stops a split order or a bill without an order.
The Approvals app
In recent Odoo versions, the Approvals app (Enterprise) lets you define approval categories with their approvers, for example capital purchases or a first order with a new vendor. It suits requests before an order and cases needing several approvers. Odoo’s 20 release notes contain no Approvals app section, so expect it to behave as before, and test it anyway.
Automation rules, activity plans and Sign
According to Odoo’s 20 release notes, automation rules can now trigger activity plans, and Sign supports automated signature requests with fixed and role-based signers, sent from activities or activity plans, with Arabic script supported. A practical use: a vendor bank account change triggers a plan with a finance review, a call-back on a known number, and a signed confirmation. An activity does not by itself block the next step; where a step must be blocked, use a mechanism that blocks, or a small documented customisation.
The decision rule we apply: use a blocking mechanism where cash is at stake, an activity where data is at stake, and a signature where an external or legal acknowledgement is needed.
What does Odoo 20 change in purchasing and payables?
Odoo’s 20 release notes list no change to purchase approval settings. The Purchase changes concern comparison, dates and cost, and several improve what an approver sees:
- An alternatives comparison screen: evidence that alternatives were considered above your upper tier.
- An editable expected arrival date that keeps the vendor’s original date for on-time rates, and recomputed arrival when the deadline has passed.
- A vendor quality rate based on quality checks.
- Sections and notes in purchase agreements and blanket orders, totals on order sections, and a default Incoterm per vendor.
In payables, the release notes add purchase order matching improvements (auto-complete, a match summary and unmatch), matching rules with payment tolerance, red and yellow duplicate warnings, and a payment wizard that detects pending payments. Treat unmatch as a control point: restrict it and review its use monthly. Two access changes also matter: record rules are removed and the domain is set on the access right itself, and user group changes are logged in the user’s chatter, so re-check every approver group after the upgrade. The wider picture is in Odoo 20 for finance teams, and the matching logic in the three-way match.
Where does AI fit in purchasing approvals?
AI drafts; approval stays human. According to Odoo’s 20 release notes, agents can be triggered by automated and scheduled actions, create records (including from an uploaded instruction file such as a PDF), update records, ask permission through buttons, and ask before exceeding their tool call limit. Bill line prediction suggests product, account, tax and analytic from bill history and the label. All AI features need IAP credits billed per request; confirm which agent features your edition and plan include. The release notes describe no purchasing-specific agent.
- Drafting a request for quotation from a vendor’s quotation file: it stays in draft, the buyer reviews it, and the matrix applies as for any order.
- A scheduled agent drafting a weekly list of orders close to a tier, by vendor: useful only if each line cites the orders it read.
- Bill line prediction: track how often reviewers change suggested accounts, and keep review mandatory until that rate is stable and low.
The agent’s user must never sit in an approver group, the principle behind agents draft, people approve. For every AI item and its credit model, see the Odoo 20 AI feature map for accounting.
How do you test that approvals are not being bypassed?
ACFE’s 2026 Report to the Nations found that more than half of fraud cases involved a lack of internal controls or an override of existing ones. A purchase matrix is overridden in predictable ways, each leaving a trace in the ledger. Run these tests on the full population, not a sample, as explained in moving from sampling to full-population testing:
- Split orders: group confirmed orders by vendor within a short window, such as seven days, and flag groups whose combined total crosses a tier while each order stays below it.
- Bills without orders for vendors or products that normally go through purchasing.
- Orders created or confirmed after the date of the bill they support.
- Approver equals requester or buyer on the same order.
- A vendor bank change followed by a payment before the review activity was completed.
- Bills unmatched and rematched, and red duplicate warnings overridden without a recorded reason.
A worked example of the first test: if the first tier is T, three orders to one vendor within five days, each at 90% of T, will pass the setting individually and represent 270% of T together. The setting worked; the matrix did not.
An approval limit that is never tested for splitting becomes a price list for avoiding approval.
Where should you start on Monday?
- Export users and groups, and list who can confirm orders, validate bills, change vendors and release payments.
- Write the matrix on one page, with tiers derived from materiality, and have finance sign it.
- Map each row to a mechanism and mark it as blocking or reminder.
- Configure it in a test database and run the bypass tests on last quarter’s data.
- Only then add AI drafting, with a named owner for IAP credits and approvers outside the agent’s group.
This sequence fits the wider rollout in applying AI accounting on Odoo 20 step by step, and the tests can run continuously once you connect AI to Odoo for continuous auditing. In our Odoo ERP implementations, the matrix is signed before users are created. seg-audit, our continuous audit platform, reads the books read-only and scores every transaction by risk; approvals outside the matrix are among the patterns it surfaces. A Procurement agent is in internal validation within MFT Intelligence; like all our agents, it drafts and a named person approves.