Odoo 20 Purchase Approvals: When Studio Rules Are Enough—and When You Need a Module

For an Odoo 20 purchase approval workflow, start with the approval mechanism already available in your database, use Studio when a button needs conditional sign-off, and introduce a custom module only when the business rule must be enforced across multiple entry points or requires a new approval lifecycle.

A purchasing team asking for “two approvals above AED 50,000” may sound like it needs a development project. It might not. Another team asking for “finance approval for a new supplier, budget-owner approval for a project, and no purchase order can be released by API without both decisions” has a different problem. A button rule and an enforceable business policy are not interchangeable.

The useful starting question is not How many approval buttons do we need? It is Which business action must remain impossible until which conditions are satisfied?

Three different layers of approval

Consider a company with buyers, purchase managers, department heads, and a finance controller. An RFQ can become a purchase order, which may then create operational consequences such as receipts and future bills. The business wants control before that commitment happens.

There are three possible layers:

Odoo 20's purchase reporting source contains a “To Approve” state, but the exact settings and behavior of your installed Purchase application should be inspected in your own Odoo 20 database before specifying a configuration-only solution. See the official 20.0 purchase report source. The existence of a state is not proof that every proposed multi-level rule is natively supported.

What Odoo 20 Studio approval rules actually do

Odoo's Odoo 20 Studio approval-rule documentation describes rules attached to an action button. A user can define an approval step on that button, assign one or more specific approvers or an approver group, and optionally filter the situations in which a step applies.

That makes Studio useful for an understandable requirement such as:

Before a buyer confirms a high-value purchase, a named purchasing manager must approve the confirmation action.

For a more complex case, Studio documents additional steps and Approval Order, allowing steps to be sequenced. It also documents Exclusive Approval, intended to prevent one user from approving another step on the same record. Odoo notes an important nuance: a user responsible for a higher step can approve or reject a previous step unless Exclusive Approval is set. This is precisely the sort of detail that a segregation-of-duties test should verify rather than assume.

Approvers may receive activities, can approve or reject, and—within the documented rules—delegate approval rights. Decisions are tracked in the record's chatter and through Studio Approval Entries, according to the same version-specific documentation.

Studio therefore brings more than a hidden button or a notification: it introduces a documented approval interaction and a visible decision trail.

A concrete example

Suppose a company agrees to the following proposed policy:

• Purchases up to AED 10,000 may follow the ordinary buyer process.
• From AED 10,000.01 to AED 50,000, the purchasing manager approves.
• Above AED 50,000, both the purchasing manager and finance controller approve.
• The same person must not complete both required decisions.

These are illustrative company rules, not Odoo defaults.

In Studio, you can begin by targeting the purchase confirmation button and defining the appropriate conditional steps and approver groups. You must then test the amount boundary, ordering and exclusivity in the specific database. You should also decide whether the condition uses untaxed or total amount, whether the thresholds are per company and per currency, and what happens when an approver is unavailable.

If the requirement ends at button-controlled approvals and all relevant users perform the action through that workflow, Studio may be sufficient. If the rule must hold through additional integration paths, you need a broader control assessment.

An approval activity is not the same as enforcement

Odoo also documents Automation Rules in 20.0. An automation can, for example, create an activity after a field changes. That can be useful for reminders and routing work.

But a notification like “Finance must review this PO” is not itself proof that the PO cannot be confirmed. A reminder may be missed. Another process may confirm the document before the reminder is seen. If the risk is an unauthorized purchase commitment, the design must prove the forbidden transition is blocked—not just that somebody was notified.

This distinction is also why simply hiding a button, adding a required checkbox on a form, or creating a scheduled reminder is not a substitute for validation. Those features may improve the user experience, but your acceptance test must cover alternate record modifications and integration paths.

The practical check is straightforward: take a test user who does not have approval rights and attempt the protected action through every supported route. Confirm that Odoo rejects it, rather than merely hiding the form control.

When a custom Odoo module becomes the safer choice

A custom addon is justified when the policy has to be enforced as a business invariant across interfaces and automation. Examples include:

1. Approvers depend on multiple live dimensions

The approver might depend on company, cost center, analytic distribution, project, product category, currency, supplier risk, contract type, or a budget balance. Some conditional approval requirements can fit Studio, but a dynamic assignment engine with complex precedence and fallback is usually easier to maintain as explicit application logic.

A policy specification might say:

IF purchase crosses a configured company threshold
AND supplier is new or bank details were changed
THEN require purchasing + finance approvals
AND forbid self-approval
BEFORE purchase commitment can occur.

This is a design example only, not executable Odoo code or a built-in Odoo 20 rule.

2. An approval can expire or become stale

Imagine a manager approves AED 30,000, then the buyer changes the vendor or increases the amount to AED 85,000. Should the original approval remain valid?

For most controlled purchasing processes, this must be answered explicitly. The rule may need to invalidate approvals after certain edits, record a new version of the approved values, and require re-approval. An approval attached to a button should not be assumed to cover every subsequent modification automatically.

Useful fields in a proposed custom design include the approved amount, vendor, currency, approving user, decision timestamp, and a reference to the values or version that were approved. The final data design should follow Odoo conventions and be reviewed against the target release.

3. External systems can create or confirm the record

An integration may create purchase orders through an API or trigger actions through scheduled code. You must determine whether the approval control is applied consistently across those paths. Do not assume that a user-interface-specific rule automatically governs all backend operations—or, conversely, claim that a particular Odoo 20 API bypass exists without reproducing it.

For higher-assurance procurement controls, define and test the invariant at the server-side transition that actually commits the business action. Keep the authorization behavior consistent for browser, mobile, imports, and supported APIs. Avoid broad sudo() use in integration code, since elevated operations can undermine controls that were meant to apply to ordinary users.

4. Approval requires more than a yes/no decision

Examples include rejected-for-rework states, substitute approvers, deadline escalation, budget reservation, attachment completeness checks, and a clean exception process for urgent purchases.

A workflow with those requirements is a domain feature, not just a decorated button. A well-scoped module may be more transparent than a dense collection of overlapping automation rules.

Studio versus code is also a hosting and subscription decision

The Odoo current pricing page lists Odoo Studio under the Custom plan and distinguishes Custom from Standard. Confirm the actual plan and contractual arrangement before assuming Studio is available or adding it to a production database.

The deployment model affects customization too. Odoo Online, Odoo.sh and self-hosted installations do not offer identical extension paths. A custom Python addon generally requires a hosting route that supports custom modules, while Studio provides its own in-app configuration approach.

That does not mean every Custom-plan database should use code. For a simple and stable approval policy, less code is often the better maintenance decision. But it also does not mean Studio removes the need for testing or security review.

Design the policy before clicking any settings

Write a one-page approval contract first. For each approval scenario, capture these fields:

A useful policy is one that the finance team can read, the purchasing team can follow, and the engineering team can turn into deterministic tests.

Threshold edge cases are not optional

Threshold-based rules often fail at the boundaries. If a buyer can bypass a finance review by changing an amount from 50,000.01 to 50,000.00, is that correct? How are currency conversions handled for foreign-currency POs? What if the total changes because a tax or discount is recalculated? What happens if a purchase is split into multiple smaller orders?

Not every risk should be solved inside a single approval button. Some require budget policy, purchase analysis, or an anti-splitting exception process. The system should reflect a defined business policy rather than invent one.

A realistic approval acceptance-test matrix

Test these cases in a staging database that mirrors the intended roles and companies. Do not run a control test only as an administrator.

The outcomes are acceptance criteria, not claims that these tests were executed here. Confirm any unsupported requirement before choosing a module or adding production code.

Common implementation mistakes

The approver is configured only as a follower. Following a document or receiving an activity does not establish authorization to release the purchase.

A condition is built on the wrong amount. Comparing company-currency thresholds with document-currency values may route orders incorrectly. Define the basis before configuring the rule.

An approval remains valid after a material edit. The business may think the controller approved the new PO, when they only approved an earlier version.

Higher-level approvers can also complete lower steps. Odoo 20's Studio documentation explicitly notes this behavior unless Exclusive Approval is applied. Verify segregation-of-duties in your own configuration. Source.

A mobile portal has a different control path. A custom app can be easy to use, but must not become an alternative way around a required purchase approval. Inspect the server-side operation it calls.

The team installs a broad third-party approval app without testing it. Review target-version compatibility, permissions, upgrade strategy, audit history and maintenance ownership. A screenshot or marketplace description cannot certify those properties.

Which approach should you choose?

Use the existing purchase controls when the native approval process exactly matches the business rule. Use Studio when the policy is primarily conditional authorization of a specific button, the approved actors and steps can be configured clearly, and every relevant action path passes validation in staging. Build a custom module when approvals must be centrally enforceable across integrations, depend on complex dynamic conditions, or require versioned approval records and lifecycle states that Studio cannot represent cleanly.

Odoo 20 provides useful approval building blocks. The engineering decision is knowing where those blocks end and where the company's actual control policy begins.

For purchasing workflows involving multiple companies, custom mobile applications or external integrations, Octivex's Odoo customization and integration services can help turn the approval policy into a testable implementation scope before anyone changes production configuration.