Adobe Commerce B2B purchase orders turn every order from a signed-in company user into a PO, and approval rules decide which POs need sign-off. Rules trigger on order total, shipping cost, or SKU count and route to approvers by company role. The logic is server-side, but the buyer-facing screens need Hyva Enterprise to render on a Hyva storefront.
Most guides explain the admin and account clicks and stop there. What they miss is the split that decides a real project: the approval engine is backend logic that runs regardless of theme, while the buyer-facing dashboard is B2B storefront UI that does not render on a stock Hyva theme. This article covers how purchase orders and approval rules actually work, how to build multi-level approval, and what it takes to make the whole flow render fast on Hyva.
What a purchase order is in Adobe Commerce B2B
When purchase orders are enabled for a company account, any order placed by a customer signed into a company user account is automatically created as a purchase order rather than going straight through checkout. The PO becomes a record that can be reviewed, approved, rejected, or edited based on the buyer’s role. Adobe’s My Purchase Orders documentation is the reference for the buyer-side flow.
One detail matters for pricing accuracy: a purchase order creates a snapshot of item prices, discounts, and shipping prices at the time the order is created. If a scheduled price change lands between PO creation and approval, the PO keeps the price it captured. That is usually what a B2B buyer wants, but it is worth knowing when you also run scheduled catalog changes, a topic covered in Bemeir’s guide to content staging on Magento and Adobe Commerce.
Purchase orders are one of three related B2B ordering tools. They sit alongside negotiable quotes, where a buyer requests custom pricing, and requisition lists, which speed up repeat ordering. Purchase orders are the piece that adds internal spend control.
How approval rules work
Approval rules are policies a company administrator sets from inside the company account on the storefront. Each rule defines a condition that, when met, forces a PO into an approval workflow before it can be placed. Per Adobe’s purchase order approval rules documentation, there are three rule types.
| Rule type | Triggers on | Common use |
|---|---|---|
| Order Total | The order total, including tax | Cap unsupervised spend per order |
| Shipping Cost | The shipping charge | Flag expensive freight for review |
| Number of SKUs | The count of unique products | Control large or unusual orders |
Each rule type uses one of four comparison operators: is more than, is less than, is more than or equal to, or is less than or equal to. So a rule reads like “Order Total is more than 5,000” and then names who has to approve it.
Approvers are chosen by company role, and the role needs at least one user assigned as an approver. A guard rail is built in: the creator of a purchase order cannot approve their own PO. When several users share an approver role, someone other than the creator approves it, unless an auto-approval permission is granted to that role. Since version 2.4.1, approvers can also process multiple purchase orders in bulk rather than one at a time.
Building multi-level approval
The power of the system is stacking rules to model a real procurement policy. Because each rule names its own condition and approver role, you can layer them:
- Any PO under 1,000 is placed with no approval, so routine reordering stays fast.
- A PO of 1,000 or more but under 25,000 must be approved by the buyer’s manager.
- A PO of 25,000 or more must be approved by both the manager and a finance approver.
- A PO with shipping cost over 500 is flagged for review regardless of order total.
Because approvers are tied to company roles rather than named people, the policy keeps working when staff change, as long as the roles stay populated. That is what turns approval rules from a single gate into genuine multi-level, role-based governance for a company account.
What the approver actually does
When a PO trips a rule, it moves to a pending state and the assigned approvers see it in their account dashboard, where they can approve or reject it, and add a comment explaining a rejection so the buyer knows what to fix. A rejected PO can be edited and resubmitted rather than started from scratch, and the whole exchange is recorded against the order. Because the creator can never approve their own PO, a single-person “company” with one approver role effectively needs the auto-approval permission, or nothing ever gets placed. This is the operational detail worth walking approvers through before go-live, since a confused approver stalls real orders. The buyer and approver views both live in the company account dashboard governed by Adobe’s B2B company roles and permissions model.
The prerequisites nobody mentions until it breaks
Two things must be in place before approval rules do anything useful.
First, purchase orders have to be enabled, both globally and for the specific company account. Without that, orders never become POs and there is nothing to approve.
Second, and this is the one that surprises teams, approval rule setup requires a defined company structure. Adobe’s documentation is explicit that a company structure is needed to specify approval by the purchasing customer’s manager. If your company accounts are flat, with every user reporting to no one, manager-based approval has nothing to resolve against. Building that hierarchy is part of the company account modeling covered in Bemeir’s guide to Hyva for B2B, and it is foundational work, not a later tweak.
The Hyva reality: where the approval flow actually renders
Here is the split that decides scope, and that generic guides never separate.
The approval engine is server-side. The rule evaluation, the snapshot pricing, the routing to approvers, the guard against self-approval, all of that is backend logic in the Adobe Commerce B2B module. It runs the same no matter what theme sits on top. Your approval policy does not care whether the frontend is Luma or Hyva.
The buyer-facing experience is B2B storefront UI. The My Purchase Orders dashboard, the approval and rejection screens, the interface where a company administrator creates approval rules, all of that is customer-facing frontend. The native Adobe Commerce B2B storefront was built with Luma and its Knockout-based UI components, and those do not render on a stock Hyva theme. On a plain Hyva install, the B2B account screens break.
The fix is Hyva Enterprise, the paid set of Hyva modules that reimplements the Adobe Commerce B2B storefront, including company accounts, negotiable quotes, requisition lists, and the purchase order and approval interfaces, in Hyva’s Alpine.js and Tailwind stack. What Hyva Enterprise adds, and when it is required, is laid out in Bemeir’s guide to Hyva Enterprise versus the free Hyva core and, feature by feature, in the Adobe Commerce B2B on Hyva compatibility guide. The short version: to give company buyers a fast, working purchase order and approval experience on Hyva, you need the Hyva Enterprise B2B modules, or a custom rebuild of those screens.
That is why “add approval rules” is a five-minute admin task on paper and a scoped project in practice. The rules are easy. Making the buyer-facing flow render correctly and quickly on your storefront is the Hyva development work.
A rollout sequence that works
To stand up purchase orders and approval on a Hyva storefront without dead ends:
- Enable B2B and purchase orders, and confirm the company accounts you are targeting have it turned on.
- Build the company structure so manager-based approval has a hierarchy to resolve against.
- Confirm Hyva Enterprise B2B modules are installed, or that the B2B account screens are on your custom build list.
- Model approval rules to match the real procurement policy, starting simple and layering.
- Assign approver roles and verify at least one user occupies each.
- Test end to end as a buyer, an approver, and an administrator, on the Hyva storefront, not just in the admin.
Testing as each persona on the real theme is the step that catches the rendering gap before your customers do.
Where this fits in your platform decision
Deep, role-based purchase approval is a reason enterprise and mid-market B2B merchants choose Adobe Commerce over lighter platforms. Merchants on Shopify and Shopify Plus get a simpler B2B approval model, and those evaluating BigCommerce or Shopware will find different depth again, which is exactly the kind of comparison that belongs in a replatforming decision rather than an afterthought.
For merchants who need this on Adobe Commerce and Hyva, Bemeir builds it as the first US-based Hyva Gold Partner with a decade of B2B focus. You can see the team on the about Bemeir page and the integration technology partners that connect approval workflows to the ERP systems where purchase orders ultimately settle.
Frequently asked questions
Do approval rules work on a Hyva storefront?
The approval logic works on any theme because it is server-side. The buyer-facing screens where users see purchase orders, approve or reject them, and where an administrator manages the rules, do not render on a stock Hyva theme, because the native B2B storefront was built with Luma. You need Hyva Enterprise B2B modules or a custom rebuild for those screens to work on Hyva.
What are the three purchase order approval rule types?
Order Total, which triggers on the order total including tax; Shipping Cost, which triggers on the shipping charge; and Number of SKUs, which triggers on the count of unique products in the order. Each uses a comparison operator such as “is more than” or “is less than or equal to” to set the threshold.
Can one purchase order require more than one approver?
Yes. Because each approval rule names its own condition and approver role, you stack rules to require multiple approvals. A high-value order can require both a manager and a finance approver, while lower-value orders require one approval or none. The creator of a PO can never approve their own order.
Why do approval rules need a company structure?
Manager-based approval has to resolve “the purchasing customer’s manager” to an actual person, and that only works if the company account has a defined hierarchy. Adobe requires a company structure for approval rule setup for this reason. Flat company accounts with no reporting lines cannot use manager-based approval until the structure is built.
Is Adobe Commerce B2B available in Magento Open Source?
No. The full B2B feature set, including company accounts, purchase orders, and approval rules, is part of Adobe Commerce, not Magento Open Source. On Open Source you would need extensions or custom development to approximate purchase order approval, and you would not get the native company account and role model these rules depend on.
