In this piece
Shopify B2B Order Approvals: Native Features, Apps, or a Custom Buyer Portal?
Shopify B2B order approval is three different buying problems, not one feature. A merchant may approve a new wholesale account, review an incoming order, or let a customer's employee request permission from their own purchasing manager. Only the third is a buyer-side purchase approval workflow. Choose a solution by who approves, what they approve, and what must remain blocked until that decision.
This distinction is practical: a merchant's Shopify Community request describes employee submission, customer-manager approval, and visibility to the supplier only afterwards. A button labelled “Submit for approval” is not enough to establish that the right organisation controls it.
Reviewed . Platform facts below come from Shopify documentation; app capabilities are vendor-documented, not hands-on certifications. Architecture and acceptance criteria are Wavect's recommendations.
Which Shopify approval workflow do you actually need?
| Decision | Decision-maker | What it authorises |
|---|---|---|
| Wholesale account approval | The merchant | A company can access B2B purchasing. |
| Merchant order review | The merchant's sales or operations team | The supplier accepts a submitted purchase. |
| Buyer-side purchase approval | A manager or budget owner inside the customer company | An employee can commit the company's spend. |
Start with native features for merchant review; test a buyer-team app for employee-to-manager approval; scope custom development only for requirements the app cannot reliably enforce. Multiple approvers or an ERP connection are reasons to test more carefully, not automatic reasons to replace your storefront.
Write the requirement as one sentence: “An employee in location A can request goods, but only the designated manager for A can release that exact request, and no Shopify order or ERP sales order may exist before release.” Replace those conditions with your actual policy. Whether a Shopify draft may already exist is a separate, essential decision.
What does Shopify support natively, including on Grow?
Shopify's B2B plan matrix lists companies, location permissions, checkout-to-draft and PO numbers on Basic, Grow, Advanced and Plus. The claim that all native B2B or draft review requires Plus is outdated. Feature-specific restrictions still matter.
Account approval controls access, not each purchase
Company account requests through Shopify Forms let the merchant approve a company for B2B access. This is onboarding. Do not buy a registration-approval app expecting it to route every employee's basket to a purchasing manager.
Draft review is a merchant-controlled queue
For a company location, go to Customers → Companies → company → location → Checkout → Order submission and select Submit all orders as drafts for review. Shopify documents this in its checkout settings. The submission reaches the merchant's draft queue without payment at checkout.
That is a useful fit when your own team checks stock, freight, negotiated prices or credit before accepting a sale. It does not, by itself, prove the customer's manager authorised the employee's spending. It also fails a requirement that the merchant must see nothing before customer approval: the merchant already has the draft.
A location administrator is not a documented purchasing approver role
Shopify documents two customer permissions for company locations: Ordering only, with the customer's own order history, and Location admin, with all location orders and address editing. Neither description establishes a manager-signoff chain. Do not confuse customer permissions with merchant staff permissions.
Distinguish pricing from permission, too. Shopify says drafts submitted through B2B checkout have prices locked by default. A price lock does not record managerial consent, reserve a departmental budget, or decide what happens when a shipping address changes. Document those rules separately.
A purchase-order number is a reference, not evidence that the named budget owner approved the contents. Likewise, “not paid yet” and “not authorised yet” are different states. A workflow design must specify each independently rather than treating a payment delay as an approval control.
Can Shopify Flow or Functions handle buyer approvals?
Use Flow for orchestration; do not mistake a notification for an enforceable purchasing policy. Shopify Flow is available on Basic, Grow, Advanced and Plus; its Send HTTP Request action requires Grow, Advanced or Plus. It can help connect a review process to another service.
There is also a specific trap: Flow's Send internal email action does not support a variable recipient address. A different purchasing manager for every company needs a suitable transactional notification integration, not a hard-coded staff email action presented as customer routing.
Decide where enforcement happens before designing automation. A workflow responding after an order exists cannot satisfy “prevent order creation until manager approval.” An email link also needs a server-side check that the logged-in person is an eligible approver for the request's company, location and current version.
Shopify's Functions availability guidance distinguishes public apps using Functions, available across plans subject to API restrictions, from custom apps containing Functions, which require Plus. Do not assume an agency can deploy any custom checkout Function to Grow.
The operation-specific limit is narrower still: the Payment Customization Function API, reviewed at version 2026-07, marks orderReviewAdd as B2B Plus-only and describes merchant review. This does not contradict all-plan location-level checkout-to-draft. They are different controls, and neither supplies a complete buyer-manager portal.
Practical rule: confirm the store plan, app distribution model, exact operation and supported checkout path. “It uses Shopify Functions” is not a sufficient compatibility answer.
Native features, an approval app, or a custom buyer portal?
| Requirement | Start here | Decision test |
|---|---|---|
| Your staff review every incoming B2B order | Native draft review | Merchant visibility before acceptance is acceptable. |
| An employee needs one customer-account owner to approve | Buyer-team app trial | The correct owner approves; employee checkout cannot bypass it. |
| Branch limits, several approvers or cost centres | App capability test, then a scoped gap assessment | Actual role scope and policy are supported, not just more email recipients. |
| Shared live budgets, unusual delegation or approval across systems | Custom layer or an extensible procurement product | Authorisation, concurrency and reconciliation work end to end. |
Keep the smallest reliable solution. An app plus a narrow ERP connector may be preferable to both a fragile collection of automations and a bespoke procurement platform. Conversely, several inexpensive apps are not a cheap solution when none owns the final decision.
Which approval apps are worth evaluating?
SparkLayer: a documented buyer-side workflow
SparkLayer's Company Users documentation describes a Limited role whose requests go to the company account owner. Pending requests are hidden from the merchant. The owner can complete or cancel them. That directly addresses buyer-side approval, rather than simply supplier review.
Use it as a trial candidate, not a claim of universal fit. Demonstrate your existing customer-account setup, pricing, payment methods and alternate checkout routes. Ask specifically about branch-scoped approvers, thresholds, rolling budgets and changes after submission. One account owner's approval should not be represented as an arbitrary multilevel policy engine without verification.
Approovly: verify the approval actor and current operation
The Approovly Shopify App Store listing advertises internal and external approval requests. A listing does not establish your required company hierarchy or a pre-order purchasing block. Check current maintenance, support responsiveness and a working end-to-end demonstration before selecting it.
For either product, ask the vendor to show the same request simultaneously as the employee, approver and merchant. Watch exactly when a draft, order, payment request and ERP message appear. Then change the amount, sign in as another company and try an old approval link. These demonstrations are more useful than a long feature checklist.
App selection should also cover data export, approval-history retention, uninstall behaviour, permission scopes and responsibility for integration failures. Request a written answer about the store plan and whether the app replaces, supplements or bypasses your existing B2B account model. This comparison is based on documentation, not an installation test of either app.
When is a custom buyer portal justified?
Custom development is justified when a commercially important rule cannot be enforced or evidenced by the available configuration. The scope should be the missing approval layer, not a Shopify rewrite.
A separate storefront is not always necessary. Shopify supports full-page customer-account extensions, including pages not tied to an existing order. Evaluate an embedded request-and-approval page before introducing a second shopping experience; confirm compatibility with the account setup and required extension capabilities.
Use a server-side request record as the authority. It should identify the customer company and location, requester, eligible approvers, policy version, currency and approval basis. Bind the decision to a versioned snapshot of SKUs, quantities, pricing basis, tax treatment, shipping and delivery address. Do not trust an editable cart attribute or customer-supplied “approved” tag.
If no purchase may be visible to the merchant before approval, keep the requisition in the approval application's storage and create the Shopify draft or order only after release. If merchant-visible drafts are acceptable, they can be part of the workflow, but protect draft completion and invoice routes against bypass. Inventory and quote expiry still need explicit policies.
Separate request states such as pending_approval, approved, rejected and expired from Shopify creation, payment and ERP delivery states. A request can be approved while ERP submission has failed. Calling both events “complete” hides the exception that operations must resolve.
Spending limits and multiple approvers need precise rules
A per-order threshold is not a monthly budget. Define whether amounts include tax and freight, which currency is authoritative, whether pending requests reserve budget and when rejected or cancelled requests release it. For shared budgets, calculate and reserve capacity atomically so simultaneous submissions cannot each spend the same remaining allowance.
Illustrative policy, not a Shopify default: an eight-branch company permits self-release up to €500 only within the branch's available monthly budget. Above €500, a branch manager must approve; above €5,000, finance must also approve. A different branch's manager has no authority. Material changes create a new version and invalidate earlier approval.
Specify whether multiple approvals are sequential, all required in parallel, or a quorum. Record delegated authority with an expiry and an audit trail. A manager on holiday should not cause silent auto-approval, and a revoked approver should not retain authority through an old link. These are acceptance criteria for an app as well as a custom build.
How should approved orders reach Shopify and the ERP?
Define the handoff before writing an integration. Is Shopify the order system of record, or must the ERP first accept credit, inventory and account mappings? Who can release fulfillment? A buyer's approval is permission to proceed, not proof that those downstream checks passed.
Shopify's draftOrderComplete mutation converts a draft into an order and supports payment-related choices. Its use is not a payment event by itself. Never mark an order paid merely because a manager approved the purchase; preserve the intended invoice or payment-terms process.
For a custom integration, maintain a durable mapping between requisition ID and version, Shopify draft/order ID and ERP reference. Save a release job alongside the approval decision, then process it through a retryable queue. Prevent duplicate creation with application-level idempotency and an ERP reference or uniqueness constraint appropriate to that system.
If a create request times out, its outcome is unknown, not necessarily failed. Reconcile the existing Shopify or ERP record before retrying. Shopify warns that webhook ordering and delivery are not guaranteed. Verify webhook authenticity, deduplicate deliveries, and run reconciliation rather than relying on a single notification.
When the ERP is unavailable, show an explicit “approved, awaiting ERP” state and keep fulfillment blocked where your business policy requires it. Do not hide the failure by sending a success email. Give operations a retry path with the same business reference, not a button that unknowingly creates a second order.
For an Odoo backend, use our separate Odoo API integration limits guide for the ERP-specific contract. This approval workflow determines when a purchase is authorised; the connector determines how that authorised purchase is delivered reliably.
What should you test before buying or launching?
Ask the app vendor or implementation partner to run these tests with real roles and representative orders in a non-production environment. “The approval email arrived” passes only the notification test.
| Scenario | Required result |
|---|---|
| Employee uses direct checkout, a saved invoice link or another enabled route | No unapproved purchase is released through an alternate path. |
| Manager from another company or branch opens the request | Access and approval are denied outside the authorised scope. |
| Approved SKU, amount or delivery address changes | Material changes require a new decision on the new version. |
| Two requests consume the last shared budget simultaneously | Only valid reservations succeed; the budget cannot be spent twice. |
| Approver is removed, delegates authority or reuses a link | Current authority is checked; replay cannot create another release. |
| Request is rejected or expires after 48 hours in the test policy | No release; reserved budget is handled according to policy. |
| Price or inventory changes while approval is pending | The agreed expiry, reservation and reapproval policy is applied visibly. |
| ERP create succeeds but its response is lost | Reconciliation finds the existing record; retry creates no duplicate. |
| ERP rejects the customer or delivery address | An actionable exception appears; downstream release follows policy. |
Capture request versions, decisions, user identities and downstream references in the evidence. Demonstrate both a successful purchase and failure recovery. The architecture should make it possible to answer: who authorised which contents, under which policy, and which Shopify and ERP records resulted?
What should a workflow assessment and implementation proposal include?
Bring your Shopify plan and customer-account configuration, one current order journey, company and branch roles, approval limits, payment rules, ERP details and a failed or manually handled example. Redact personal and commercially sensitive information before sharing sample records.
A useful assessment produces a current-versus-required workflow map, a native/app/custom recommendation, a permission and state model, an integration boundary, and an acceptance-test list. The proposal should identify assumptions, configuration versus code, third-party licences, data migration, operational ownership and what is explicitly out of scope.
Compare total operating cost, not an app subscription against a development estimate alone. Include configuration, integration, support, policy changes, regression testing and exception handling. Establish a baseline using your own time spent per request and monthly request count. Add measured rework separately; do not assume a generic approval-speed or revenue uplift.
Wavect's MyMerch case study describes targeted Shopify process automation rather than a platform rewrite. It is relevant delivery experience, not a claim that MyMerch used the approval architecture in this article.
For the wider decision, see custom software versus off-the-shelf. For an implementation gap, our custom software development service is the commercial next step. Discuss a Shopify B2B approval workflow assessment with Wavect and ask for a scoped implementation proposal grounded in the controls you actually need.
Shopify B2B order approval FAQ
Does Shopify have native B2B order approval?
Can Shopify Grow require order approval?
Is wholesale customer approval the same as purchase order approval?
Can a Shopify company location admin approve employee orders?
Can Shopify Flow email each customer’s purchasing manager?
Does entering a PO number approve a Shopify order?
Do multiple approvers or spending limits require a custom portal?
Should manager approval automatically mark the order paid or send it to the ERP?
Final thoughts
Choose the approval boundary before the technology. Native drafts are a good answer to merchant review; a verified buyer-team app may handle customer-manager approval without a custom build. Develop only the missing controls, keep payment and ERP acceptance separate, and make bypass prevention and failure recovery part of acceptance.
