3. 发票匹配核心逻辑：采购订单、入库单、发票的三单匹配算法原理与数据流设计

三单匹配是企业应付账款（AP）流程中最关键的自动化校验环节。其核心目标是在付款前验证采购订单（PO）、入库单（GR）与供应商发票（Invoice）三者之间的数量、单价、金额及业务状态是否一致。任何一单的偏差都会导致匹配失败，进而阻塞付款流程。

3.1 三单匹配的业务语义与数据锚点

每一单都承载着不同的业务阶段数据，匹配的本质是跨单据的字段级对账：

3.2 三单匹配算法原理（2-Way / 3-Way 模式）

企业通常根据业务复杂度选择 2-Way 或 3-Way 匹配模式。3-Way 是完整校验，2-Way 则跳过入库单校验（适用于服务类采购）。

3.2.1 3-Way 匹配算法流程

1. PO 与 GR 匹配（数量校验）： 校验发票行对应的物料在 PO 中是否存在，且 GR 累计实收数量 ≥ 发票开票数量。若 GR 数量不足，标记为“欠收匹配异常”。
2. PO 与 Invoice 匹配（单价校验）： 校验发票含税单价是否在 PO 单价的容差范围内（例如 ±5%）。超出容差则标记为“单价差异异常”。
3. GR 与 Invoice 匹配（金额校验）： 计算发票金额 = 开票数量 × 含税单价，并与 GR 实收数量 × PO 单价进行比对。差异超过容差阈值（如值 > 10 元或比例 > 1%）则标记为“金额差异异常”。
4. 状态一致性校验： 检查 PO 是否已审批、GR 是否已质检通过、发票是否在有效期内。任一状态不满足则挂起。

3.3 三单匹配数据流设计

下图展示了从采购订单创建到发票匹配完成的核心数据流与状态转换。数据流采用事件驱动架构，每个匹配节点产生匹配结果事件，驱动后续流程。

3.4 匹配异常分类与处理策略

根据实际项目经验，三单匹配异常可归纳为以下四类，每类对应不同的处理路径：

3.5 三单匹配的代码实现骨架（Python 示例）

以下是一个简化的三单匹配核心函数，展示了数量、单价、金额的校验逻辑：

def three_way_match(po, gr, invoice, tolerance_price=0.05, tolerance_amount=10.0):
    """
    三单匹配核心算法
    :param po: 采购订单 dict，包含 unit_price, quantity, tax_rate
    :param gr: 入库单 dict，包含 received_qty
    :param invoice: 发票 dict，包含 invoice_qty, unit_price_incl_tax, total_amount
    :param tolerance_price: 单价容差比例，默认 5%
    :param tolerance_amount: 金额容差，默认 10 元
    :return: dict {status, errors}
    """
    errors = []
    
    # 1. 数量校验：发票数量 ≤ 入库数量
    if invoice['invoice_qty'] > gr['received_qty']:
        errors.append(f"数量不匹配：发票 {invoice['invoice_qty']} > 入库 {gr['received_qty']}")
    
    # 2. 单价校验：发票含税单价 vs PO 单价（假设 PO 为不含税单价）
    po_unit_price_incl = po['unit_price'] * (1 + po['tax_rate'])
    price_diff_ratio = abs(invoice['unit_price_incl_tax'] - po_unit_price_incl) / po_unit_price_incl
    if price_diff_ratio > tolerance_price:
        errors.append(f"单价差异超容差：差异比例 {price_diff_ratio:.2%}")
    
    # 3. 金额校验：发票金额 vs 理论金额（入库数量 × PO 含税单价）
    expected_amount = gr['received_qty'] * po_unit_price_incl
    amount_diff = abs(invoice['total_amount'] - expected_amount)
    if amount_diff > tolerance_amount:
        errors.append(f"金额差异超阈值：差异 {amount_diff:.2f} 元")
    
    # 4. 返回结果
    if errors:
        return {'status': '异常', 'errors': errors}
    else:
        return {'status': '通过', 'errors': []}

3.6 数据流设计中的关键表结构

为了支撑三单匹配的高效查询，数据库层面需要建立以下核心表及其关联索引：

通过上述表结构，匹配引擎可以基于 po_line_id 快速关联三张单据，并利用累计聚合函数计算已匹配数量，避免重复匹配。

3.7 常见匹配失败根因与排查清单

• PO 未关闭导致重复匹配： 检查 PO 行状态是否为“已关闭”或“已完成”，防止同一 PO 行被多次匹配。
• 入库单未过账： GR 必须完成“过账”操作后，其数量才会进入匹配累计池。
• 发票税码与 PO 不一致： 税码差异会导致含税单价计算错误，建议在发票录入时强制校验税码一致性。
• 分批入库与部分开票的累计逻辑错误： 匹配引擎需要维护“已匹配数量”的累计值，避免重复扣减库存数量。
• 容差阈值设置过严： 对于小额差异（如几分钱），建议设置容差自动通过，减少人工干预。