本文作者从实际工作实践出发，结合案例等分享了电商金融支付财务融合中的基本概念和相关原理解析，包括：订单、账单、交易流水和账知识解构，供大家一同参考和学习。

从事电商、进销存、金融、支付、财务的产品同学，是否对订单记录、交易记录、账单、账等概念给弄糊涂？或者当我们谈及对账时，是否知道对账背后的记账逻辑？只有知道了这些底层概念，我们方才可以理清业务边界、明确上述概念之间的逻辑关系，业务理清了，逻辑关系农透了，我们方可游刃有余，而非稀里糊涂、浅尝辄止、依猫画虎~

本篇是根据我们在“电商-支付-金融-财务”融合项目方面的推进中的一些实践经验和复盘总结，向大家分享“金融支付财务融合业务-实践分享”系列篇的第一篇，也即“订单、账单、交易流水、账知识解构、原理解析”，欢迎大家一起讨论。

订单、账单、交易流水、账知识解构、原理解析

1. 订单记录：面向业务发生的一个经营管理概念（记录工具）

1. 侧重业务：只要有业务发生，就必然产生订单记录；
2. 订单有两个状态：订单履约状态、订单支付状态，也有将支付状态作为履约的前置状态；
3. 订单侧重业务分析：如订单渠道、购买人、交付时间、交付方式等；
4. 不必然产生交易：订单记录不必然产生交易记录或财务记录，譬如咨询订单。
5. 金额是中性：订单中的金额基本不会出现正负号——当日金融业务场景中，充值订单这种场景例外（下文例子会覆盖）；

下图为常见订单表结构图示意：

2. 交易记录：面向交易发生的一个资金管理概念（记录工具）

1. 财务金融属性：交易记录是金融或财务领域的一个概念，交易记录的出现，必然伴随资金账户场景；
2. 侧重交易：往往发生真实的资金流动，如充值流水、提现流水、投资流水、还款流水等；
3. 与余额挂靠：一旦发生交易，其必然影响账户余额的变动（这里不讨论失败场景）；
4. 逻辑关系：交易记录属于“账单记录”的子场景，也即有交易发生，必然会产生对应的1对1账单记录，交易记录属于“广义订单”的子场景，只所以引入“广义订单”这个概念，可以用如下例子来予以说明，譬如用支付宝购物2个鼠标合并付款，订单记录是2个鼠标，交易记录是1笔支付流水；而向支付宝充值100元，就没有订单记录只有交易记录一说或者说交易记录就是订单记录。

下图为常见交易记录表结构图示意：

3. 账：面向财务的一个收支管理概念（记账工具）

1. 侧重账：发生财务往来就要入账，或者我们可以说“即使不涉及资金流动也会产生账”，譬如赊账，商户A从商户B以赊销的方式进货100件，每件价值10元，欠账1000元，这里发生了交易，但无资金流动产生。订单记录插入订单流水、交易记录不插入交易流水、但账单记录要插入财务流水（赊账记录）；
2. 复试记账：业务帐是收付实现制的单式记账，财务帐是权责发生制的复式记账；
3. 侧重交易对手：有借必有贷、借贷必平衡。而交易记录、订单记录侧重单方记账，账单记录通常用复式记账;
4. 时间粒度：账的时间粒度一般都比较粗，粒度一般为日;
5. 与业务账(业务流水)区别：业务账侧重于双方业务系统、物流数据和订单数据，主要用作购销双方是否发货；财务账侧重付款和开票情况，主要用于结款。

下图为常见账表结构图示意

4. 账单：面向用户的一个收支管理概念（记账工具）

1. 侧重单：账单账单，顾名思义是把“账”合并成单、有汇总之意，当然一个账单可以是一笔交易、也可以是几笔交易的合并;
2. 与账的关系：账的粒度是一笔一笔，账单的粒度是合并汇总（极端场景是一笔一个账单）；
3. 侧重账：同上述“账”关于此点的描述；
4. 侧重进、出：同上述“账”关于此点的描述；
5. 侧重交易对手：同上述“账”关于此点的描述；
6. 实务简化应用：实务中，账单面向的用户多是普通用户而非专业级财务人员，故此我们看到的支付宝、微信以及我们的银行的账单记录是阉割版的“财务记账记录”——也即只向用户呈现用户资金账户增减的变动及交易对手，而未对交易对手再进行财务记账（实际也记录了，只是未开放给用户，毕竟用户不是会计，开放太多信息用户会蒙圈）。

下图为常见账单表结构图示意：

下图为常见账单用户场景示意图（微信、支付宝）：

原理实践实例复盘

1. 微信零钱明细和账单的区别是什么？为什么要做这种区分？

一个优秀的产品经理应习惯对自己日常用到的产品细腻观察、透彻了解、刨根问题或者至少发起疑问，这是为什么呢？

通过梳理我们可以发现：

微信零钱明细只记录“微信零钱”里的收入、支出； 而微信账单不仅包含微信零钱的收入、支出记录，还包含绑定的银行卡的收入、支出记录。

用账套来讲（非严格定义）：微信账单是微信用户的一级账套，记录微信用户通过微信支付发生的每笔进出资金的日志；微信零钱是二级账套，记录微信零钱这个资金池发生的每笔进出资金的日志； 大家可以很自然的得出微信零钱的明细一定会出现在微信账单里，但微信的账单里的大部分交易记录是不会出现在微信零钱里。

2. 微信零钱明细每笔交易都带有余额，而微信账单的每笔交易不带有余额，这又是为什么呢？为什么要做这种区分？

一个优秀的产品经理应该会对自己日常应用的产品了解非常之透彻或者至少发起疑问，这是为什么呢？

前面用了一个不严格的定义也即微信账单是一级账套、微信零钱明细是二级账套。只所以说不严格，是因为微信账单没有期初余额、期末余额的概念，不是严格意义上的账套。

微信只所以这样做，是因为微信支付是一个支付工具（通道），不是一个资金账户（池子=账套），所以无法引入“期初余额”、“期末余额”的概念，如果非要引入也是可以的——通过虚拟记录来自洽，譬如用微信支付通过招行卡充100话费，现在的策略是显示1条100元的充值记录，如果走账套策略，需要用如下来表达：

1. +100元招行充值；
2. -100元话费购买。

3. 随手记、挖财记账等记账工具可以删除，微信支付的“账单”怎么可以删除呢？

一个优秀的产品经理应该会对自己日常应用的产品了解非常之透彻或者至少发起疑问，这是为什么呢？

由于微信支付的账单记录不是严格概念上的账套，无借贷平衡的内生要求，仅是一笔记账日志，所以微信支付、支付宝的账单记录都是可以删除的（用户视角），也就不难理解了。因为他是站在用户的角度出发的，删除背后的诉求是用户本人不希望别人看见我的这笔消费，而不是我很在乎这笔记录是否真实发生或者删除之后账单数据是否自洽。

4. 微信零钱通的零钱明细-交易记录也可以删除，这是为什么呢？

一个优秀的产品经理应该会对自己日常应用的产品了解非常之透彻或者至少发起疑问，这是为什么呢？

微信零钱与支付宝的余额、银行的账户等属性基本相同，是一个严格的账套，经然也提供了删除功能，这很让人费解！！！

我认为这是微信支付团队的一个产品bug，或许是负责这个模块产品经理的一种偷懒——直接复用了微信支付“账单”里面的删除逻辑（上述3提到，微信支付里的账单提供删除是可以理解的，因为“账单”无借贷平衡的内生要求，也即无期初余额、期末余额的逻辑自洽要求），而未站在“账套”或“资金账户”的角度去思考，交易记录是不能随意删除的，一旦删除，站在可视角度，账务就不能自洽了。

下图为“微信-账单”、“微信-零钱通-交易明细”、“支付宝-账单”、“支付宝-余额-交易明细”的对比图

5. “账单”合并“交易明细”场景之支付宝实践分析

细心的产品经理（不是用户）会发现下图中的同一个支付宝账户，未做过任何删除操作，“余额宝-交易明细”、“余额-交易明细”都有6月10日322.94的交易流水，唯独“支付宝-账单”中无这笔记录（这里未用交易流水表述），难道支付宝的产品经理也像上述微信的产品经理犯糊涂了么？

一个优秀的产品经理应该会对自己日常应用的产品了解非常之透彻或者至少发起疑问，这是为什么呢？

答案是没有，支付宝是互联网金融的祖师爷，其对业务的理解深度要比微信团队深刻，其对业务的理解和用户的拿捏把握是值得我们学习的。

那具体原因是什么？想必大家看了下面的复盘分析，就明白本篇作为“支付金融财务”融合领域的前置知识掌握的必要性和本篇第一章节对“业务流水、交易流水、账、账单”的概念解构和原理分析的价值。

1. 根据蚂蚁花呗的清算指令，系统自动从用户的余额宝扣款322.94元，“余额宝账套”体系产生一条-322.94的出款入账记录，见上述图1；
2. 处于合规需要，余额宝的钱无法直接与花呗账单进行对冲，必须经过余额搭桥；
3. 故此“余额账套”中会自动插入两条入账记录，即：进账+322.94元（余额宝转入余额），出账-322.94元（余额转出到花呗），见上述图2；
4. 对于用户而言，当天还花呗账单的实际还款金额是1503.32元（通过蚂蚁金服的清算引擎，在最后还款日有系统代替用户自动完成了1503.32元的还款——322.94元通过余额账户取自余额宝、1180.38元通过支付宝划扣通道取自我的招行借记卡），无论资金来自哪里都是一件事“还款”，故在“支付宝账单”中显示为一笔1503.32，见上述图3、图4。

严格意义上讲，支付宝的这种账单处理逻辑不算严谨，会增加用户的理解成本，如这里的余额账单、余额宝账单在支付宝账单中无法直观匹配的情况。

但当我们理解了前面提到的“交易记录”、“账”、“账单”的底层概念及原理区别之后，支付宝给用户提供的“账单”是“账单”而非“账”。“账单”是一种合并的表达方式，从简化用户理解的角度讲，显示为一笔也许理解成本更轻。

以上是我在支付金融财务融合项目中的一些实践总结，限于文采拙劣和篇幅原因，未能精细呈现，海涵，欢迎大家交流切磋！

不同的行业、不同的业务场景、不同的岗位角色，会面临不同的产品任务。但万变不离其宗，方法相通，只要我们有产品盘感、业务敏感、逻辑严谨、灵通好学、干练带风、狠下功夫，放到哪我们都一样熠熠生辉。

产品之路很艰辛，也更能锻炼人，尤其是中后台、尤其是“中后台+财务”这种大量底层的项目！在此祝广大产品兄弟姐妹们不辱“产品”之title，做出好产品！

作者：九天牧人，个人微信unifarm

本文由 @九天牧人 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议