Shopify B2B 订单审批：原生功能、应用还是定制买方门户？

“Shopify B2B 订单审批”实际上可能指三种不同需求。商家可以审核企业客户的注册申请、审核收到的订单，也可以让客户公司的员工向自己的采购主管申请购买授权。只有第三种属于买方内部采购审批。选型首先要明确：谁审批、审批什么，以及批准之前必须阻止哪个业务动作。

一位商家在 Shopify Community 提出的需求就明确要求：员工提交采购申请，由客户公司的主管批准，之后供应商才能看到。“提交审批”按钮本身也不能说明审批权属于正确的组织。

核查日期：2026 年 9 月 29 日。平台事实依据 Shopify 官方文档；应用功能依据供应商文档，不代表经过实际安装验证。架构方案和验收条件是 Wavect 的建议。

您需要哪一种 Shopify 审批流程？

商家审核优先使用原生功能；员工向主管申请采购，优先测试支持买方团队的应用；只有应用无法可靠执行关键规则时，才确定定制开发范围。多位审批人或 ERP 对接意味着需要更严格的验证，不意味着必须更换整个商城。

把需求写成一句可以验收的话：“A 分支机构的员工可以申请商品，但只有负责 A 的指定主管才能放行这份具体申请；放行前不能创建 Shopify 订单，也不能创建 ERP 销售订单。”再根据实际政策调整条件。是否允许提前存在 Shopify 草稿订单，必须另行明确，不能默认等同于正式订单。

Shopify 原生支持什么？Grow 套餐也能用吗？

Shopify 按套餐列出的 B2B 功能表将企业、地点权限、结账转草稿和采购订单编号列为 Basic、Grow、Advanced 与 Plus 均支持的功能。“所有原生 B2B 或草稿审核都需要 Plus”已经不是准确的概括。不过，具体功能仍可能有单独的套餐限制。

账户审核决定准入，不决定每一笔采购

通过 Shopify Forms 提交的企业账户申请允许商家批准企业使用 B2B 采购。这属于客户准入。不要因为某个应用支持注册审批，就认定它能把员工的每一个购物车交给客户公司的采购主管。

原生草稿审核由商家处理

英文管理界面的路径是 Customers → Companies → company → location → Checkout → Order submission，选择 Submit all orders as drafts for review。Shopify 在结账设置文档中说明了这一配置。提交时不在结账环节付款，申请进入商家的草稿队列。

如果您的团队需要先确认库存、运费、协议价格或信用状况，再接受销售订单，这种方式很合适。但它本身不能证明客户主管授权了员工的支出。它也不满足“客户批准之前，商家什么都看不到”：商家已经能看到草稿。

地点管理员不是文档中定义的采购审批角色

Shopify 文档列出两种企业地点的客户权限：Ordering only 可以查看自己的订单记录；Location admin 可以查看该地点的全部订单并修改地址。这些定义没有建立主管签批链。客户权限与商家后台员工权限也不能混为一谈。

价格与授权同样需要分开。Shopify 说明，通过 B2B 结账提交的草稿默认锁定价格。但锁价不等于记录主管同意，不会自动预占部门预算，也没有定义更改收货地址后是否需要重新审批。这些规则需要独立设计。

采购订单编号是业务参考信息，不是预算负责人已批准订单内容的证据。“尚未付款”和“尚未授权”也是不同状态。流程设计必须分别说明，不能把延后付款直接当成采购审批控制。

Shopify Flow 或 Functions 能处理买方审批吗？

Flow 适合协调动作，但通知不等于强制执行采购规则。Shopify Flow支持 Basic、Grow、Advanced 和 Plus；Send HTTP Request 动作需要 Grow、Advanced 或 Plus，可用于连接外部审批服务。

还有一个容易忽略的限制：Send internal email 动作不支持通过变量指定收件人地址。如果每家客户公司的采购主管不同，就需要合适的事务通知集成。固定的内部员工邮箱并不能实现按客户动态分配审批通知。

先明确在哪个环节阻止未授权采购，再设计自动通知。订单创建后才触发的流程，无法满足“主管批准前不得创建订单”。邮件里的批准链接也需要服务器检查：当前登录用户是否有权审批这家公司、这个地点、这个申请版本。

Shopify Functions 的可用性说明区分了两种情况：使用 Functions 的公开应用可在各套餐使用，但仍受具体 API 限制；包含 Functions 的定制应用需要 Plus。因此，不能默认认为开发团队可以在 Grow 商店部署任意定制结账 Function。

具体操作的限制更窄：本次核查的 2026-07 版 Payment Customization Function API将 orderReviewAdd限定为 B2B Plus，并说明其用途是商家审核。这与各套餐都支持按企业地点设置结账转草稿并不矛盾。它们是不同控制方式，也都不等于完整的买方主管审批门户。

实际选型时，要一起确认商店套餐、应用分发方式、具体 API 操作及支持的结账路径。“使用了 Shopify Functions”不足以证明兼容性。

选择原生功能、审批应用，还是定制买方门户？

保留最小但可靠的方案。一个适合的应用加上范围有限的 ERP 连接器，可能比脆弱的自动化拼接或整套自建采购平台更合理。反过来，多个低价应用也未必便宜：如果没有任何一个系统对最终审批决定负责，运营成本仍会很高。

哪些订单审批应用值得评估？

SparkLayer：文档明确描述买方内部审批

SparkLayer 的 Company Users 文档描述了 Limited 角色，其采购申请交由企业账户所有者处理。等待批准的申请对商家不可见，账户所有者可以完成或取消。因此，它确实涉及买方审批，而不只是供应商审核。

应将其视为试用候选，而不是所有情况的通用答案。要求演示现有客户账户配置、价格、付款方式和其他结账入口。重点确认分支机构审批人、金额阈值、累计预算和提交后的变更。不能未经验证，就把一个账户所有者的批准机制描述成任意多级审批规则引擎。

Approovly：核实审批主体与当前运行情况

Approovly 的 Shopify App Store 页面宣传内部和外部审批申请。但应用商店介绍不能证明其支持您的企业层级，也不能证明它能在订单创建之前实施采购拦截。选择前需要验证维护情况、客服响应和完整流程是否能实际运行。

对于这两类候选，让供应商同时展示员工、审批人和商家视角下的同一份申请。观察草稿、正式订单、付款请求和 ERP 消息分别在什么时候出现。然后更改金额、切换到另一家公司，并尝试旧审批链接。这些演示比长篇功能清单更能说明问题。

评估还应包含数据导出、审批历史保留、卸载后的行为、权限范围以及集成失败的责任归属。要求书面说明适用套餐，以及应用是替代、补充还是绕过现有 B2B 账户模型。这里的比较依据文档，不是对两款应用的安装实测结论。

什么情况下值得开发定制 B2B 买方门户？

当现有配置无法可靠执行或证明一条重要业务规则时，定制开发才有明确价值。开发对象应该是缺失的审批层，而不是重写 Shopify。

也不一定需要另建商城。Shopify 支持客户账户全页扩展，包括不依附于既有订单的页面。在引入第二套购物体验之前，应先评估嵌入式申请与审批页面，并确认账户设置及所需扩展能力兼容。

在服务器保存具有权威性的申请记录，包含客户企业、地点、申请人、合格审批人、规则版本、币种和审批金额计算依据。每次决定应绑定到一个不可混淆的申请版本，其中记录商品编号、数量、定价基础、税务处理、运费与收货地址。不能信任用户可修改的购物车属性，也不能把客户传来的“approved”标签视作授权证明。

如果批准前不得向商家暴露采购信息，采购申请应留在审批应用的存储中，放行后才创建 Shopify 草稿或订单。如果允许商家提前看到草稿，草稿可以成为流程的一部分，但必须防止通过完成草稿或发票链接绕过审批。库存保留和报价有效期也需要明确政策。

将 pending_approval、approved、rejected 和 expired 等申请状态，与 Shopify 创建状态、付款状态及 ERP 传输状态分开。一份申请可能已批准，但 ERP 提交仍然失败。把两者都叫“已完成”，会掩盖运营团队真正需要处理的异常。

支出限额和多位审批人需要精确定义

单笔金额阈值不等于月度预算。需要定义金额是否含税和运费、以哪种币种为准、待批申请是否预占预算，以及拒绝或取消后何时释放。共享预算必须以原子方式检查并预留额度，避免两个并发申请分别消耗同一笔余额。

以下为说明性政策，不是 Shopify 默认能力：一家有八个分支机构的公司允许员工自行放行不超过 €500 的采购，但前提是本分支月度预算仍足够。超过 €500 需要分支主管批准；超过 €5,000 还需要财务批准。其他分支的主管没有审批权。实质性修改产生新版本，并使原有批准失效。

还要明确多位审批人是顺序签批、并行且全体同意，还是满足指定人数即可。代理审批需要有效期和审计记录。主管休假不能导致系统默认批准；被撤销权限的人员不能继续利用旧链接操作。这些也是采购现成应用时的验收条件，不只是定制系统的开发细节。

已批准采购应如何进入 Shopify 和 ERP？

写集成代码之前，先确定交接责任。Shopify 是否是订单主系统，还是 ERP 必须先确认信用、库存与客户映射？谁有权释放履约任务？买方批准只是允许继续处理，并不意味着后续检查全部通过。

Shopify 的 draftOrderComplete mutation将草稿转换为订单，并提供与付款相关的选项。调用它本身不代表已经收款。绝不能因为主管批准就把订单标记为已支付；仍须遵循约定的发票或账期流程。

定制集成应持续保存采购申请 ID 与版本、Shopify 草稿或订单 ID、ERP 参考号之间的映射。在保存批准决定时，一并可靠记录待执行的放行任务，再通过支持重试的队列处理。使用应用层幂等控制，以及适合目标 ERP 的唯一业务参考或唯一性约束，防止重复创建。

创建请求超时意味着结果未知，不一定是失败。重试前应核对 Shopify 或 ERP 中是否已有对应记录。Shopify 明确提醒，Webhook 的顺序与送达都不保证。需要验证消息来源、去重，并定期核对状态，不能只依赖一次通知。

ERP 不可用时，显示“已批准，等待 ERP”，并在业务规则要求时继续阻止履约。不要发送成功邮件来掩盖失败。运营人员需要能够沿用同一个业务参考重试，而不是点击一个可能再建一张订单的按钮。

如果后台使用 Odoo，可参考单独的 Odoo API 集成限制指南。审批流程决定采购何时获得授权，连接器决定这笔已授权采购如何可靠进入 ERP，两者不应混为一谈。

购买应用或上线之前，应该测试什么？

要求应用供应商或实施团队在非生产环境中，使用真实角色配置与有代表性的订单运行以下测试。“审批邮件已送达”只能证明通知环节有效。

验收证据应包括申请版本、审批决定、人员身份和下游系统参考号。既演示一次成功采购，也演示故障恢复。系统需要回答：谁依据哪版规则批准了哪些内容，最终生成了哪些 Shopify 与 ERP 记录？

流程评估和实施报价应该交付什么？

准备 Shopify 套餐与客户账户配置、一个现有下单流程、企业及分支角色、审批额度、付款规则、ERP 信息，以及一个失败或需要人工处理的案例。分享样例记录前，应先删除或遮盖个人信息与敏感商业信息。

有价值的评估应交付现状与目标流程图、原生/应用/定制的选择依据、权限与状态模型、集成边界，以及验收测试清单。实施报价应明确前提假设、配置与编程分别包含什么、第三方许可、数据迁移、运维责任和不包含的范围。

比较总运营成本，而不是只比较应用订阅费和开发报价。应计入配置、集成、支持、规则变更、回归测试和异常处理。用自己的单份申请处理时间及月度申请量建立基线，再单独加入实测返工成本。不要默认系统一定能带来某个通用的审批提速或收入增长比例。

Wavect 的 MyMerch 案例介绍的是有针对性的 Shopify 流程自动化，而不是平台重建。这是相关交付经验，不代表 MyMerch 采用了本文描述的审批架构。

更广泛的选型可阅读定制软件与现成软件比较指南。如果存在具体实施缺口，可进一步了解我们的定制软件开发服务。与 Wavect 讨论 Shopify B2B 审批流程评估，根据真正需要执行的控制措施，确定边界清晰的实施方案与报价。