企业费用结算系统设计是经营的数字核心，需从用户、架构、商业三重视角出发。本文基于20年财务经验，提炼五大结算模型，探讨其设计要点与实战应用。
在企业信息化、数字化日益普及的今天，费用结算早已不再是简单的计算与对账，而是企业经营的数字核心节点。每一次结算，都是业务价值的数字化确认；每一份账单，都是客户或供应商关系的信任背书。我们产品经理在设计费用结算系统时，从三重视角来审视：从用户视角理解业务需求与痛点，从架构视角保证系统质量与稳健性，从商业视角实现价值最大化，既不多计1分也不少确认1分，应计尽计颗粒归仓。
根据博主近20年的财务产品经验，提炼出五大结算模型，这些模型将考验我们产品人思考的广度与深度，在准确性与性能之间、在灵活性与复杂性之间、在安全性与便利之间，作合适的取舍。比如“灵活性与复杂性”这对孪生体，我会选择灵活性以确保系统的可拓展性，因为业务变化是无穷的，失去高拓展性将会陷入定制化开发的深渊。
结算系统的设计核心在于如何抽象复杂的业务场景，建立可拓展、可维护的计算模型。接下来我们将深入探讨费用结算系统的五种核心模型，坐好啦，开车！
计算模型是结算领域中原始也是应用最广泛的模型，将原始通过+、-、*、/等运算得出最终的数据规则体系。
计算模型有3种类型：
1.简单计算类型，比如固定类型、常量、阶梯等，具体如下：
2.复合计算类型，在前面基础上增大难度，有2种甚至2种以上计算类型，具体如下：
3.特殊计算类型：
周期模型是时间维度的抽象，定义了费用计算的时间边界和结算频率，具体是指：将某项持续发生的费用，按照一个约定的时间区间（周期）进行累积，并在周期结束时，基于该周期内的业务量或固定费率，一次性计算出应付总额，并完成结算。
周期模型典型应用场景有：会员订阅费、薪资与佣金、仓储物流费、平台服务费等，按月或周等维度结算。
周期模型有3种类型：
1.按时间规律划分：
2.按业务特性划分：
3.特殊计算类型：
账户是一种以虚拟账户体系为核心，对交易资金或费用进行逐笔核算、分户管理、实时清算的精细化财务管理模型。它模仿了银行账户的运作原理，是处理复杂、高频、多方分账场景的核心工具，应用最多的场景在支付领域，所以以后大家听到“支付领域清结算”就知是账户模型的结算。
账户模型核心要素有4个，账户主体、账户类型、会计（触发）事件、结算规则
1.账户主体，识别参与资金或费用分配的所有方（如：品牌方、平台方、达人、服务商、消费者保障基金等），每个主体有唯一账户ID。
2. 账户类型，区分不同性质的资金，包括：
收入账户：记录销售收入分成。
费用账户：记录营销费用、佣金、服务费支出。
保证金账户：用于冻结押金、保证金。
结算账户：用于汇总净额，准备提现或支付。
3. 会计（触发）事件，每一笔引起账户余额变动的交易，都生成一条不可篡改的流水记录。包含：事件类型（如“订单结算”、“佣金扣除”、“退款”）、关联方、金额、余额、时间戳等，实质就是一个业务动作。
4.结算规则引擎：模型的核心，预定义了各种业务场景下的 “计算逻辑” 和 “分账规则” 。例如：
规则：一笔100元的订单，平台扣点5%，达人佣金10%。
引擎执行：自动生成三条流水：商家账户+85元，平台费用账户+5元，达人账户+10元
计价模型回答了许多人首先想到的问题：这笔费用究竟怎么算？它定义了如何将业务活动中发生的经济成本，准确地、公平地、符合商业约定的转化为具体应向交易方（内部部门、外部客户、合作伙伴）收取或支付的费用金额。由此可见，它实质是一种计算、归集和分摊费用的核心规则与逻辑体系。
一个完整的计价模型通常包含以下关键要素：
a.计价基础：费用计算的基数是什么。
示例：物流运费可能按订单重量、体积、件数或包裹数计价；平台佣金按商品交易总额（GMV） 的百分比计算。
b. 计费规则，在计价基础上的具体算法，此处会应用到【计算模型】
示例：可以是单价 × 数量（如每公斤5元 × 总重量），阶梯费率（如0-100公斤一个价，100公斤以上另一个价），百分比费率（如GMV的5%），或固定费用。
c.分摊逻辑：当一笔总费用需要在多个对象（如多个门店、多个成本中心、多个产品）之间进行分配时，所依据的规则。
比如：一笔总仓到区域仓的干线运输费，按各区域仓的收货件数占比分摊到各个门店。
d.调整因子与例外条款：考虑到业务复杂性，模型会包含特殊情况的处理规则。
比如：偏远地区附加费、旺季溢价、油价浮动费、特殊品类附加费、最低消费门槛、合作伙伴特殊折扣等。
计价模型从维度上分，有固定定价、动态定价（如网约车动态定价）、组合定价等；从量上分有按用量计价、按时间计价（如包月99元）、按价值计价（如交易额5%)等。
结算模型是确定一笔费用“应由谁承担、承担多少金额” 的逻辑、算法和规则，是who、how的视角。在企业费用结算管理中，“结算模型” 是一个核心的业务规则引擎与计算框架。
结算模型由三部分组成：计费基础、分摊规则、结算主体，具体来说：
a.计费基础，即基于什么产生费用，可理解为计费源是什么。
如：基于交易金额（如平台佣金按销售额的5%）、基于操作量（如物流按件/公斤/体积计费）、基于使用量（如云服务按资源使用时长）、基于固定周期（如门店月租金）。
b.分摊规则，费用在不同主体间如何分配。
如：全额承担（由一方支付全部）、比例分摊（如商场促销券由品牌方和商场按7:3分担）、阶梯分摊（不同区间不同费率）、指定归属（指定至具体部门、门店或项目）。
c. 结算主体，参与计费结算的各方分别是谁。
如：内部主体（如公司内不同部门、成本中心、门店）、外部主体（如供应商、平台方、物流服务商、加盟商、商场）。
结算模型是费用结算的基础，是连接业务与财务的转换器，掌握了此模型再看其他模型就容易多了。其在实务中成功落地，总结起来就六个字：抽象、配置、自动。
a.梳理与固化：将分散在合同、邮件、口头约定中的各种费用结算规则（如加盟联营扣点、平台费用、物流运费、商场费用）全部梳理出来，形成标准化的 《结算规则库》。
b.系统配置：在财务中台或费控系统中，将这些规则配置成可执行的“结算模型”。例如，在系统中设置：“对于渠道类型=加盟商的销售出库单，自动按零售价*0.55生成应收结算单”。
c.集成与执行：系统根据业务单据（销售订单、物流轨迹等）自动触发对应的结算模型进行计算，生成对账单、应付/应收单，并推送到财务系统。
通过上述五个模型，基本能将99%的业务场景费用做好清结算，到此是不是不结束了呢？
NO，结算出来的费用还要对账、出账单，这两块市面上相关文章汗牛充栋，这儿只作简单概述。
对账是为了确保内部与内部（账账对账）、内部与外部数据（内外对账）的一致性。对账体系分三层：
第一层：交易（明细）级对账，比如从各渠道采集原始数据、解析，再逐笔勾对、识别差异，这是最原始最简单的逻辑，但业务是复杂的，这一层只能应对简单逻辑场景。
第二层：汇总对账，如按天、按渠道、按客户等口径汇总核对。
第三层：资金级对账，如按银行流水、在途资金、广告费、物流费等口径对账。
费用结算出来了，也对账完毕了，此时就要有承载的单据，这就是账单，它是结算结果的最终呈现。
账单的设计要点主要有以下几点：
多形态、多模板的输出；
可上查下钻、可追溯、可归因，及版本管理；
权限管理及全链路追踪。
结算系统产品架构分为三层：表现层、应用层、领域层，如下图：
表现层定位系统的用户界面与对外API接口，是系统与用户或其他系统交互的“窗口”，起到”接收请求、数据验证（如登录、鉴权）与格式化、呈现结果“的作用。比如结算结算页面、供应商对账门户、系统集成API等，是系统的脸面。
应用层可以理解为一个中间层，定位系统的业务流程组织者与协调者，是具体业务用例的实现者。它本身不包含核心业务逻辑，更像一个传话筒或中间人，协调多个领域对象完成一个完整的业务动作。
牛马，领域层就是结算系统的牛马！负责计算、结算、生成账单、对账等具体事务。它包含纯粹的业务逻辑和业务规则。它是对企业真实业务领域（费用结算）的概念抽象和模型化、落地执行。
核心职责包括：
封装业务实体与规则：定义并实现如费用单据、结算周期、成本中心、会计科目、分摊规则、审批策略等核心领域对象。这些对象拥有自己的数据（属性）和行为（方法），并强制执行业务不变量（如“已支付的单据不能删除”）。
表达业务关系：通过聚合、关联等模式，表达实体间的关系（如一个报销单聚合了多个费用明细行）。
提供领域服务：对于不属于任何单个实体的、跨多个实体的复杂业务逻辑，封装为领域服务（如费用分摊引擎、税规计算器）。
以上。
实际业务场景纷繁复杂，架构设计与产品逻辑虽不尽相同，但基本离不开上述五大金刚模型，多思考、多实践，赶路时多抬头（看方向、行业经验），登山观远时多想想实践（理论落地），早日修炼成结算领域的达摩禅师！
作者：业财老曾，公众号：业财老曾谈，专注财务信息化20年
本文由 @业财老曾 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。