制造企业的 ERPNext + AI: 用中间件填补应付账款自动化的关键缺口

如果您正在中国境内的制造企业 (机加工厂、热处理厂、食品加工、回收再制造、代工厂) 运行 ERPNext,或在东南亚 (越南、泰国、柬埔寨) 的制造基地用 ERPNext 替代成本更高的 SAP / Oracle,那么选型理由很可能是合理的。Manufacturing 模块在 BOM、生产工单、委外加工、批次管理上能用。Frappe 框架真的可扩展。没有 Enterprise 授权加价,SME 规模的定制经济性能成立。

但与此同时,您的 AP 团队大概率仍然像导入 ERPNext 之前一样、像在上一个会计系统里一样,在 Purchase Invoice 屏幕上一个字段一个字段地手工录入供应商发票。除非有人把那个缺失的部件补上,这个状态就会继续。

与 Odoo 17 / 18 不同,ERPNext 没有内置的 OCR 或 AI 发票数字化功能。"导入 PDF 然后让系统填好草稿" 的流程开箱不可用。对中国制造企业来说,这部分是优点 (没有按欧美场景设计的、出厂即坏的功能要对抗),部分是真实的缺口。本文说明这道缺口在哪、为什么在制造业场景下尤其痛、以及我们在生产环境中用来填补它的架构。

本文基于十多年为中国境内制造企业、外资制造企业、跨境贸易公司,以及在东南亚运营工厂的中资制造集团部署 ERPNext 与 Odoo 的实战经验。这不是销售演示稿。

制造企业为什么选 ERPNext

在谈缺口之前,先把选 ERPNext 的合理性说清楚。选择 ERPNext 的中国和华人制造企业通常基于三个互相加强的理由:

纯粹的开源。 没有 Community / Enterprise 分级,没有按用户的阶梯涨价,没有按模块的授权费。50–200 人规模、利润率不厚的制造企业,经济账算得过来 — 每一块花在 ERP 授权上的钱,就是不能投到设备上的钱。相比金蝶云星空、用友 NC 系列等本土 ERP,ERPNext 在 5 年总持有成本上有显著优势,特别是在多基地或跨境运营的场景下。

Frappe 框架的灵活性。 DocType 模型确实易于定制 — 在 Purchase Invoice 上加字段、新建工厂特定概念的 DocType、通过 REST API 暴露,这一切比 Odoo 的等价定制更顺手。对每家工厂都有特殊工作流的制造业 (而每家工厂确实都有特殊工作流),这一点很重要。

Manufacturing 模块的深度。 ERPNext 的制造模块开发得相当扎实:多层级 BOM、生产工单生命周期、委外加工 (中国制造业普遍依赖外协 — 热处理、电镀、表面处理、机加工、阳极氧化)、批次 / 序列号跟踪、多仓库、报废核算。Odoo Manufacturing 也合格,但 ERPNext 在这个领域是真正的竞争对手。

这是 ERPNext 正面的故事。AP 自动化的故事是另一个对话。

AP 缺口比您想的大

50–200 人规模的中国制造企业典型的月度发票量在 200–400 张左右,大致结构如下:

• 30–40% 原材料采购 (与采购订单、入库单、批次号关联)
• 15–25% 委外加工服务费 (与委外工单关联,有时跨多道工序)
• 10–15% 公用事业 (电、水、工业气体、通信)
• 10–15% MRO (设备维修、消耗品)
• 10–15% 专业服务 (会计、税务咨询、检测认证、计量校准)
• 加上进口报关单据、货代发票、海关进口增值税专用缴款书

按每张 5–7 分钟 (制造企业的发票比办公室发票耗时更长,因为匹配的复杂性) 计算,每月 25–45 小时的 AP 录入时间。再加上每张 1–2 分钟的代扣代缴或税额勾选准备,加上月末 5–8 小时的差异修正,中国制造企业的财务团队每月会花 35–55 小时在文档处理上。

这相当于一个全职财务岗位的工作量,而工厂的财务团队本来就精简。还没算运营层面的滞后 — 发票在队列里堆积、对供应商付款延迟、进项税在错误的所属期被认定。

AI 发票处理的承诺是把每张 5–7 分钟的工作压缩到 30–60 秒的草稿确认。问题是:在 ERPNext 上怎么搭建这个能力?因为它不在盒子里。

ERPNext 当前为 AP 提供什么

公平地评估一下现有工具。ERPNext 给您:

• 一个扎实的 Purchase Invoice DocType,带明细行、税率、审批工作流
• 邮箱接入 (从供应商邮件中拉取)
• 在 Purchase Invoice 上的文档附件 (PDF、图像)
• Purchase Order、Purchase Receipt、Purchase Invoice 之间的三票匹配
• 印度本地化做得不错 (GST 电子发票、TDS) — 证明框架支持税务机关对接

ERPNext 不给您:

• 基于 PDF 或图像的 AI 抽取
• 基于抽取文本的供应商主数据匹配
• 税务机关 API 验证调用 (国家税务总局发票查验、增值税发票综合服务平台勾选)
• 一般纳税人 / 小规模纳税人 的发票处理逻辑差异
• 全电发票 (数电发票) 的 XML / OFD 解析
• 出口企业的出口退税申报数据准备
• 个人劳务报酬代扣代缴 与完税证明出具

社区有一些 Frappe 应用在朝这个方向走 (包括成熟度参差不齐的 OCR 模块和 erpnext_china 类社区本地化),但都没有达到中国制造企业生产环境可用的 AI 发票数字化级别。对中国制造企业来说,AP 自动化层是一件 "需要构建" 的东西,不是 "可以安装" 的东西。

缺口在中国制造业运营中的具体表现

有意思的失效点出现在 制造业运营复杂性 与 中国税务监管要求 的交汇处。下面每一项都是我们部署的工厂里真实发生的事情。

1. 增值税发票字段 + 工厂内部路由

中国制造企业的原材料发票同时承载监管字段 (购销双方 18 位 纳税人识别号、货物名称、规格型号、单价、税率、税额、价税合计、发票代码 / 号码 / 校验码,或全电发票的 20 位发票号码) 和运营字段 (收货仓库、批次号、关联的采购订单行、预期入库)。ERPNext 标准 Purchase Invoice 在加了本地化的情况下能处理监管字段,通过三票匹配处理运营字段 — 但前提是有人把数据正确录进去。

没有抽取层。发票以 PDF 或扫描件到达,AP 人员要同时读监管字段和运营字段,然后录入 ERPNext,同时与采购订单和送货单做交叉核对。

2. 一般纳税人 vs 小规模纳税人 的处理差异

收到的发票是否来自 一般纳税人 决定您能否抵扣进项税 — 来自 小规模纳税人 的 普通发票 一般不能抵扣。ERPNext 标准的 Supplier DocType 没有 "纳税人类型" 字段,也没有原生逻辑根据供应商类型决定 account.tax 处理方式。l10n 中国本地化通过 Studio 或自定义模块加入这个字段,但 OCR 层不知道这些字段的存在,也无法基于发票本身的特征 ("增值税专用发票" 标题、"3% 简易计税" 字样、专票 vs 普票的标题区别) 自动判断。AP 人员每张都要手动确认。

3. 委外加工请求与生产工单的关联

这是制造业特有的、办公室业务里没有的缺口。从事金属加工的企业会把零件送出去做热处理或表面处理,委外厂家把这个服务计费回来。这张发票需要关联:

• ERPNext 中的具体委外工单 (Subcontracting Order)
• 发给委外厂家的物料 (此前的领用 Stock Entry)
• 收回来的物料 (新的入库 Stock Entry,常带质检状态)
• 完成的工序及其成本
• 加上中国的税务结构 (是专票还是普票,能否抵扣进项)

ERPNext 有委外加工模型 (Subcontracting Order、Subcontracting Receipt) 但收到对应发票后在财务侧闭环这一动作几乎都是手工。AI 中间件需要理解委外工单,而不仅仅是通用供应商发票。

4. 进项税额抵扣验证 — Odoo 案例中提到的同一个 STA 缺口

任何来自 一般纳税人 的 增值税专用发票 都需要在 国家税务总局全国增值税发票查验平台 上做真伪验证 — 确认发票号码、开票日期、价税合计与税务局系统记录一致。一般纳税人 还需要在 增值税发票综合服务平台 上做 抵扣勾选。这两个动作 ERPNext 都不原生支持。

OCR / AI 抽取层应当在草稿生成前调用查验 API,把不通过的发票路由到隔离队列;勾选确认这一动作可以在中间件中提示并部分自动化。

5. 个人劳务报酬代扣代缴

频繁聘用个人外包 (设计师、自由撰稿人、咨询顾问、讲师等) 的制造企业,每次支付都需要按 个人所得税法 进行代扣代缴。劳务报酬所得在扣除 800 元免征额或 20% 费用扣除后,适用 20%–40% 的累进税率,企业作为扣缴义务人需在次月 15 日前申报缴纳并向个人出具 完税证明。

ERPNext 标准 TDS (印度版预扣税) 模块可以重用,但不直接对应中国 个人所得税代扣代缴 的规则和申报口径。需要本地化或自定义。

6. 多仓库入库路由

工厂的原材料入库通常按照物料类别路由到特定仓库 — 原材料库、待检库、直接进生产工单的在制品库。发票上没写 "RM-01 仓库",需要从物料代码和采购订单的上下文推断。

ERPNext 在数据正确录入的前提下能漂亮地处理这一切 (仓库级库存、批次跟踪、多步质检流程)。AI 中间件做的是推断侧 — 抽取物料代码、在 ERPNext 中查找、识别默认仓库和质量要求、按此路由 Goods Receipt。

7. 多语种供应商发票 (出海背景下尤其重要)

中国制造企业全球采购是常态。汽车配件加工厂会同时收到日本母公司或一级供应商的 請求書、欧洲供应商的英文发票、韩国设备厂家的发票、德国工具供应商的发票、加上国内的中文增值税发票。中资制造企业在东南亚的工厂还会加上越南语、泰语、印尼语的发票。

ERPNext 标准界面假设一个会话一种语言。AI 抽取层要能在同一工作流里处理 CJK、拉丁字母、东南亚字符。对在东南亚运营的中资制造集团,这不是 "锦上添花",而是 "必备"。

8. 多币种进口 + 出口退税申报

进口场景:USD / JPY 计价的进口发票、人民币计价的海关进口增值税专用缴款书、货代发票、可能的代扣代缴。ERPNext 的 Landed Cost Voucher 处理成本分摊,但前提是数据要进得去。

出口侧:出口退税申报 (一般贸易出口或加工贸易) 需要把出口报关单、发票、收汇凭证、采购增值税专用发票等数据组织起来提交税务局。这是中国出口型制造企业每月 / 季度都要做的工作,ERPNext 标准没有相关支持。AI 中间件可以在抽取阶段就把退税相关数据结构化,显著加快后续申报准备。

9. 全电发票 (数电发票) 与结构化数据

全电发票 自 2021 年起从上海、内蒙古、广东试点推广,到 2025–2026 年已成为多数省市的默认开票类型。本质上是一份结构化的 XML 数据 (附带 OFD/PDF 可视化),原本不需要 OCR — 直接解析就行。

ERPNext 标准没有全电发票 XML 解析器。如果不在中间件层加上,系统就把全电发票当作普通 PDF 处理,完全浪费了原生结构化数据的价值。

ERPNext 的架构选择

对 Odoo 来说,架构选择相对清晰 — 用外部 FastAPI 中间件通过 XML-RPC 或 REST 与 Odoo 通信。对 ERPNext 来说,有两个真正有意义的选择,正确答案取决于具体情境。

方案 A: Frappe 自定义应用 (系统内)

把 AI 处理实现为安装在同一个 ERPNext 实例上的 Frappe 应用。AI 逻辑放在应用的 Python 模块里,通过 Frappe 的 whitelisted method 暴露。新的 DocType (Vendor Bill Draft、OCR Extraction Log、WHT Mapping Rule) 扩展数据模型。Frappe 的权限系统承担 AP 审批工作流。

flowchart TD
    A["发票来源<br/>邮件 / 上传 / 扫描"] --> B["Frappe Email Inbox /<br/>Custom Upload Doctype"]
    B --> C["Custom Frappe App<br/>AP Automation"]
    C --> D{"文档类型"}
    D -->|"全电发票 XML / OFD"| E["全电发票 Parser"]
    D -->|"PDF / 图像"| F["OCR Adapter<br/>外部 API 调用"]
    F --> G["AI 抽取<br/>Claude Sonnet"]
    E --> H["中文字段验证"]
    G --> H
    H --> I["ERPNext 主数据匹配<br/>Supplier / Item / Tax / Cost Center"]
    I --> J["国家税务总局发票查验"]
    J --> K["Vendor Bill Draft<br/>Custom DocType"]
    K --> L["AP 审批工作流<br/>Frappe Permissions"]
    L --> M["Purchase Invoice + 抵扣勾选记录"]

优点:UX 紧密,只需运维一个系统,使用 Frappe 的用户和权限模型,对没有独立基础设施的 SME 部署简单。

缺点:绑定 Frappe 框架版本 (升级影响 ERP 和 AI 应用两方面),AI 处理与 ERPNext 共享服务器资源,如果 ERP 组合扩大很难共用同一套 AI 逻辑。

方案 B: 外部 FastAPI 中间件 (系统外)

与 Odoo 架构相同的模式。一个独立的 FastAPI 服务负责文档接入、OCR、AI 抽取、验证,并通过 REST API 把结果推到 ERPNext。从 ERPNext 看,只是一个干净的 Purchase Invoice 草稿通过 API 进来,它不知道也不关心 AI 处理。

flowchart TD
    A["发票来源<br/>邮件 / 上传 / 扫描"] --> B["FastAPI Middleware<br/>外部服务"]
    B --> C{"文档类型"}
    C -->|"全电发票 XML / OFD"| D["全电发票 Parser"]
    C -->|"PDF / 图像"| E["OCR + 版面分析"]
    E --> F["AI 抽取<br/>Claude Sonnet"]
    D --> G["中文字段验证"]
    F --> G
    G --> H["ERPNext REST API<br/>主数据匹配"]
    H --> I["纳税人类型判定 + 真伪验证"]
    I --> J{"置信度阈值"}
    J -->|"高"| K["Purchase Invoice Draft<br/>通过 REST API 创建"]
    J -->|"低"| L["人工审核队列<br/>外部 UI"]
    L --> K
    K --> M["ERPNext 中 AP 审批"]
    M --> N["Submitted Purchase Invoice + 抵扣 / 出口退税数据"]

优点:AI 栈生命周期独立,可服务多个 ERP (跨境集团的不同子公司用不同 ERP 时有用),关注点分离更干净,AI 处理可独立扩容。

缺点:运维基础设施更多,要升级和监控两个系统,审核 UI 在 ERPNext 之外 (多一个登录)。

怎么选

对中国境内单一 ERP 运行 ERPNext 的制造企业,且没有引入其他 ERP 的计划,方案 A 通常是正确选择。Frappe 的 DocType 模式真的适合这个用例,AP 团队已经住在 ERPNext 的 UI 里,运营简洁性对工厂 IT 团队 (通常 1–3 人) 很重要。

方案 B 更适合 跨境集团 (中国境内母公司用金蝶 / 用友、东南亚子公司用 ERPNext 的常见模式),或者 3–5 年内有 ERP 迁移规划、希望 AI 投资能跨迁移延续的情况。

我们根据客户情况部署两种模式。AI / OCR / 验证逻辑的内部结构相同,变化的是集成接口和审核 UI 所在的位置。

中国制造企业的现实 ROI

代表性案例数字:每月 250 张供应商发票,境内境外混合,出口业务占比 30%,委外加工占比 20%,代扣代缴占比 8%,所有发票需要查验。

部署前:

• 250 张 × 6 分钟 = 月 25 小时 (录入)
• 200 张 × 1 分钟手工查验和勾选准备 = 月 3.3 小时
• 月 8 小时 (委外工单匹配)
• 月 6 小时 (出口退税数据准备)
• 月 5 小时 (月末差异修正)
• 合计:每月约 47 小时的财务人员时间用于 AP 相关工作

部署后:

• 250 张 × 60 秒确认 = 月 4.2 小时
• 真伪验证、纳税人类型判定、抵扣记录归档全部自动化
• 委外发票自动匹配工单 (例外手工)
• 出口退税数据自动结构化
• 月 3 小时处理异常和审核队列
• 合计:每月约 7 小时

每月释放约 40 小时的财务人员时间。在中国一线、二线城市的就业市场,经验丰富的 AP 财务很难招,把人重新分配到现金流预测、供应商谈判、主数据治理、出口退税申报优化等更有价值的工作,通常比减员对企业更划算。

周期时间的好处同样重要。原本要在录入队列里待 2–3 个工作日的原材料发票,现在收到后一小时内就能形成草稿、当天匹配。委外计费周期缩短,改善了在制品到成品的周转测量。月末结账从 7 个工作日压缩到 4 个工作日。

实施考虑

决定推进前要想清楚的几件事:

主数据先行。 制造企业的 ERPNext 部署积累了多年不一致的供应商记录、漂移的物料代码、与现状不符的 BOM 版本。AI 抽取的精度只能达到背后验证层的水平。我们标准做法是在 AI 中间件部署之前或并行,做 2–4 周的主数据治理。跳过这一步,AI 会忠实地把发票匹配到错误的供应商和错误的物料,然后有人会得出 "AI 用不了" 的结论,整个项目就浪费了。

Frappe 应用还是外部服务 — 早决定。 项目中段从方案 A 切换到方案 B (反之亦然) 意味着重写集成层。基于您的集团结构和 ERP 路线图,在最开始就做架构决定。

分阶段推进。 从公用事业和 MRO 发票开始 — 模板化、量大、复杂度低、置信度高。在这一类上达到 95% 直通率,再叠加原材料、委外、进口和出口退税。试图先自动化最难的工作流,产出会是不能用的系统和不信任它的团队。

本地部署还是云端。 国内制造企业的 ERPNext 大多本地部署或部署在国内私有云 (出于 个人信息保护法、数据安全法、网络安全法、等保 2.0 的考虑)。AI 中间件应当在同一环境运行。Claude Sonnet API 对大多数制造企业可用 — 流向 LLM 的数据是发票内容,不是核心 IP。对供应商保密要求严格的制造企业 (国防供应链、特定汽车合同),可以用 Ollama 加近期开源权重模型作为本地专用回退。东南亚的中资工厂则可以根据当地数据合规要求选择就近 (新加坡、香港) 或本地部署。

别忘了纸质输入。 中国制造企业的发票相当一部分仍然是纸质 (虽然全电发票普及在快速改变这个比例)。在收货码头或 AP 桌面规划扫描工作流。AI 流水线的下游一样,上游需要扫描仪和路由规则。

ERPNext + AI 在大趋势中的位置

Frappe 的母公司在投资 AI 能力,ERPNext 社区也在出 AI 相关的应用。这些都还没达到中国制造企业开箱即用的 AP 自动化方案的级别。路线图会推进,但 "我们有一个 AI 应用" 与 "我们有面向中国制造业的、生产可用的、本地化完整的 AP 自动化" 之间的差距,比 "Odoo 有发票数字化" 与 "Odoo 有完整的中国本地化发票数字化" 之间的差距更大。

目前对中国制造企业的现实路径是把 AI 层作为定制扩展构建 — 无论是 Frappe 应用还是外部中间件 — 选择一个同时熟悉框架和中国监管要求 (增值税发票体系、查验勾选、纳税人类型差异、出口退税、代扣代缴) 的合作伙伴。我们服务的规模的工厂,这项投资通常一年内回收成本,得到的系统是真正属于自己的,不受 SaaS 供应商路线图或定价变化的影响。

与我们沟通

如果您正在中国境内或东南亚的制造企业运行 (或评估) ERPNext,而本文描述的 AP 工作流让您觉得熟悉得疼,我们提供 30 分钟 ERPNext + AI 免费评估。我们会一起走一遍您当前的 AP 和委外工作流,识别您具体工厂画像下自动化收益最高的发票类别,坦率告诉您应该构建为 Frappe 自定义应用还是外部中间件 — 基于您的集团结构,而不是默认推荐。

Simplico 在曼谷,十多年来在中文、英文、日文、泰文市场为制造业、贸易公司和服务业部署 ERPNext 与 Odoo,服务对象包括日资制造企业的泰国工厂和东南亚制造业。我们在生产环境构建 AI 中间件 — 在真实的工厂里,不是在幻灯片里。

[预约 30 分钟评估 →]