Tencent Video ToB / 多方结算枢纽

多方渠道结算枢纽

把运营商集采、牌照方分账、硬件厂商分成、代理商返点四类合作方各自的合同口径、渠道映射和对账规则，收敛进同一套可复核的结算视图。

这不是单渠道对账。同一套结算面要同时吸收四类完全不同的合作方——运营商的集采（带省分分摊和卡类拆分）、牌照方的产线分账、硬件厂商的按 OEM 分成、代理商的返卡返点和活动绑定补贴——每一类都带自己的合同口径。核心能力是把这四类拉进一条可复核链路，每一笔结算都能回到合同、活动 ID、渠道和数据源，业务和财务确认的不只是最终金额，是任意一个中间数。

Counterparty Classes运营商（集采 / 省分分摊 / 卡类拆分）· 牌照方（按产线分账）· 硬件厂商（按 OEM 分成）· 代理商（返卡补贴 / 活动返点）

Data Shape发货流水、VIP 消耗占比、运营商卡类拆分、硬件厂商分成、活动绑定返点

Evidence Base多期服务商对账版本（Q3 / Q4 / 年度）、回复模板、合同与补充协议

Public Boundary只展示脱敏流程与字段，不公开合作方名、分成比例、合同、订单号和金额

业务流

从业务现场到复核结论

01运营商发货流水

02牌照方分账规则

03硬件厂商分成口径

04代理商返点 / 返卡

05统一规则层

06稽核工作簿

07业务确认

证据模式

这证明了什么能力

多期服务商结算文件包含运营商侧的基数、纯新门槛、历史增量、分省结算金额和客户汇总。

牌照方对账把按产线的分账比例、兑换比率和退款抵扣拉进同一套稽核面。

硬件厂商结算带按 OEM 的分成比例和渠道编码映射——这些不在交易数据里，只能从合同里读出来。

代理商和返卡渠道材料加上返卡补贴、活动绑定激励和季度奖金，每一类都有自己的资格逻辑。

处理模型

问题、处理方式和系统价值

业务问题

四类合作方带四套合同口径，落在同一个结算面上；同一行发货记录在不同合作方下意味着不同的应付。单表视图会扭曲所有结果。

处理方式

先按合作方类别分流，按类套合同规则（分成比例、分省分摊、兑换比率、返卡资格），再把四个子账拉回同一本可复核的工作簿，附带跨类汇总。

稽核价值

每一笔结算数字都能沿着它所属的合作方类，回到具体的合同条款、渠道编码或资格规则——而不只是最终金额。

脱敏代码

sanitized counterparty classification

# Classify each delivery row by counterparty class first
flow["class"] = "operator"
flow.loc[flow["product_line"].isin(LICENSEE_LINES), "class"] = "licensee"
flow.loc[flow["product_line"].isin(VENDOR_LINES), "class"] = "vendor"
flow.loc[flow["sub_channel"].isin(DISTRIBUTOR_CODES), "class"] = "distributor"

# Each class carries its own contract terms — rates / codes omitted per NDA
ledgers = {}
for cls, rule in CLASS_RULES.items():
    sub = flow[flow["class"] == cls]
    ledgers[cls] = (
        sub.pivot_table(
            values="open_count",
            index=rule["group_by"],
            aggfunc="sum"
        )
        .reset_index()
        .merge(rule["rate_table"], how="left", on=rule["match_on"])
    )

audit = pd.concat(ledgers.values(), keys=ledgers.keys())