“账户合并”这么做，必升值加薪！

为什么三国里总是说“都是些身经百战的精兵悍将”，那么跟新招募训练出来的将士有什么区别呢？我觉得最大的区别就是实战经验，实战经验是对战略战术理论的一次次验证和优化，是对每一个招式的优劣和时机的反复钻研！！！已经炉火纯青。只要对方从上往后抡大刀，比如关二爷，你就知道他要从下劈你的战马，劈中的话必然落于马下，他必等刀至半空中后回刀砍下，斩汝头颅；所以只要对方往后抡大刀，你就应该条件反射似的上提缰绳，让马匹跃起避开其刀锋，然后等马回落时，顺势一杆长枪刺过去......

天下大势分久必合

这是事物的发展规律，只要公司业务在发展，人员在流动，运营者的理念 总是在变化，变化的过程中就会有人要提出合并一些账户，同样也会有运营人员要提出拆分一些虚拟账户；那么合并和拆分的过程就要考验产品经理的综合把控能力和全面的知识储备；需要知道合并和拆分会涉及到哪些方面的改造，如何改造，今天这篇文章我们就来介绍这样一个实战案例，通过这个案例，大家可以清楚的掌握系统账务、会计账务、实际资金、业务等之间的关联和协同关系，对虚拟记账有一个更立体的认识；这个案例也可以用于面试中回答“你做过的最好的项目”这类题目

保证金账户是什么账户

我们都知道保证金是一个很常见的平台来控制风险或者制衡外部参与者的手段；比如共享单车的保证金就是为了吸纳资金池，外卖小哥缴纳的保证金就是未来制约其服务质量，代理商的保证金同样也是这样的目的

对于一个多业务线的平台来说，可能会存在每个业务线都需要缴纳不同种类的保证金，比如你在A业务线需要缴纳A保证金，在B业务线需要缴纳B保证金；这时候你就需要在钱包里分别充值AB两类保证金，同样在平台的账户中心也会有你的两个虚拟账户A保证金账户，B保证金账户；每个保证金账户独立存在，单独管理

保证金账户的多层账务

对于保证金来说账务不只是在账户中心，在多处都有电子化记录，而且相互对应，互为核算

首先就是支付系统的充值和提现记录；其次是账户系统的保证金开户、保证金余额、保证金流水的相关记录；然后是会计系统对应的保证金科目以及会计记录，和保证金资金管理账户的银行存款科目；最后就是保证金的实际资金账户的实际银行结算账户的资金账务记录

保证金为什么会发生合并

如果一个人或者商家在一个平台缴纳多种保证金的话，其实就意味着平台是以业务为颗粒度来管理保证金，这样对于用户来说势必要缴纳更多的保证金；一方面会造成用户不满，另一方面也会造成招商的难度，影响业务的发展

更好的方式可以以个人或者商家主体为维度来管理保证金，就是一个人在平台只需要缴纳一份保证金，实现“一金多用，事后核算”的模式，也就是缴纳的保证金属于平台总部统一管理，当各业务线发生保证金扣款时再计入各业务线名下，而不是在账户维度就计入业务线名下；这样大大降低了保证金账户数量以及提升用户满意度，同样也降低了资金账户以及会计的管理成本

合并账户需要关注什么

做保证金何必不是简单的账户中心虚拟账户完成合并，而是要将保证金相关的多层账务完成合并，首先是账户中心的多个保证金账户余额合并到一个账户中去，另一个就是会计系统的多个保证金明细科目结转到一个科目中去，然后就是存储在多个专用结算账户中的资金要调拨到对应的一个结算户当中，这样才真正完成保证金的合并

虚拟账户的内转处理

在合并虚拟账户的时候，我们有很多种选择，一种是选择原来的一个保证金账户作为合并后的总账户，另一种方法就是新开通一个统一保证金账户，将原来的所有账户里的余额转入即可；我这里推荐用后者，账务更加清晰，不必要背负历史的众多账务问题，以新账户为起点重新出发

会计科目的结转处理

同理会计系统也要新建对应的统一保证金科目，将原来的A类保证金科目余额和B类保证金科目余额全部结转到新的统一保证金科目当中；至于结转多少，这个要依据账户中心提供的“余额转出”的系统账务统计进行结转

这样的动作也会完成一次系统账务和会计账户的核算；比如系统账务的“A类保证金余额转出=X”，这时候会计系统的A类保证金科目余额如果不等于X那么说明这个科目的余额没办法结转为0，这说明系统账务跟会计账务核算不一致，这就需要一定的策略进行差错处理以至会计科目余额结转为0，假如结转完X以后，B类科目余额还有△X，则可以再结转一次△X，可以定义为保证金调整

资金的调拨处理

秉承专款专用的原则，前期不同业务线的保证金可能存放在不同的银行账户中，既然业务系统以及会计系统都完成了余额的转移，那么对应的银行账户的资金业务相应的进行调拨处理，假如我们又开了一个新的银行账户T，这就需要根据系统记录的转移的余额X进行资金的调拨，如果资金不足或者调拨后有结余，就需要进行历史资金账务的核算，以找到账务出现差错的原因，进行对应的差错处理；比如资金剩余了，可以确认资金为营业外收入-保证金未知结余；这就属于天上掉馅饼了

后台操作的分流处理

最后我们要处理另一个事情就是不同业务对系统的操作，因为保证金已经合并了，那么如果用户在不同业务线因为违规有进行扣除一部分保证金，那么这时候我们就需要知道这笔保证金扣除应该归属那么业务线的收入

实现方法有很多，我们可以在扣除流水上标记业务线，怎么识别业务线呢，可以在操作扣除时要求选择什么业务线要扣除

我们留个小思考题，你觉得还有什么办法来实现不同业务线扣除保证金的记账处理么？请把你的思考回复在评论区！！！

推荐阅读：365天陪伴 · 带你成支付专家！

---

365天·从入门到产品专家

扫码或者点击阅读原文访问支付课堂

365天和1.1万+支付产品经理一起学习