账户是根据会计科目设置的，具有一定格式和结构，用于反映会计要素的增减变动情况及其结果的载体。本文作者将用五个案例，围绕支付清算账户展开分析，希望对你有帮助。

账户体系是支付交易的基础，就像电池对于手机，油罐对于加油站，心脏对于人体？那么这么核心的系统是不是很难设计呢？其实恰恰不难。这也印证了那样一句话“大道至简”。

账户是根据会计科目设置的，具有一定格式和结构，用于反映会计要素的增减变动情况及其结果的载体。账户的基本结构应同时具备以下内容：

• 账户的名称，即会计科目；
• 日期和摘要，即记载经济业务的日期和概括说明经济业务的内容；
• 增加方和减少方的金额及余额；
• 凭证号数，即说明记载账户记录的依据。

如果财务知识不是很充足，可能对以上的账户定义很难理解；如果从业务视角来看账户，可以理解为账户是用于记录某个主体、某类型资金的余额、以及余额变动明细的数据载体，进而账户有3个关键的内容：

• 账户余额：这个账户有多少钱
• 账户流水：这个账户资金进进出出的明细记录
• 账户交易：怎么把钱放进去，怎么把钱取出来

抓住了上面3个点，基本就抓住了账户设计的核心了。

基于这3个点去构建账户的辅助设施，比如账户主体，账户种类，账户余额结构，账户流水的记录字段，账户的功能权限，账户的出入账，账户服务（账户开通注销，冻结解冻，余额流水查询等）等。

账户的种类：

跟科目分类相同，账户可以分资产类账户，负债类账户，损益类账户，共同类账户等。

如果从业务的视角来看，可以基于业务场景来对账户进行分类和命名，比如商户的结算款会结算到商户结算账户，支付公司在银行开的账户叫备付金账户，备付金账户又分存管户，收付户，汇缴户；按主体类型可以分个人账户/企业账户；按账户功能定位又可以分为会员子账户、商户子账户、中间担保户。

从账户命名上基本就知道了这个账户是干嘛用的；就像你有10张卡，一张是放工资的你叫他工资卡，一张是公积金的你叫公积金卡等等，基于业务命名，目的是为了区分账户用途。

但是，无论账户叫什么名字，都是有账户余额，账户流水，账户交易；无论卡叫什么名字都是银行卡；所以账户的本质属性没有改变，设计办法也基本相通。唯一不同的是附属内容存在区别，例如支出户只能打款不能收款，中间担保户不能为负等等，账户权限可能不同，主体不同，交易特点不同…..

账户的结构：

账户系统的基本功能脑图如图所示：

账户主体：这个账户是谁的，个人的？企业的？还是内部业务线的？

账户结构树：就像会计科目，就像商品类目，由于账户可能种类繁多所以有时也需要一个结构树。

• 账户类型：账户的分类，比如个人账户/对公账户，结算账户/付款账户，收款账户/打款账户
• 账户名称：便于核算
• 账户余额：账户余额一般为了业务需要，会设计多个金额属性，比如冻结金额，可用金额，可提金额
• 账户流水：账户的资金变动记录，记录对手账户，收支方向，金额，费用类型等基本信息
• 账户服务：开通/关闭、权限设置、入账、扣账、调账、冻结/解冻、余额查询、流水查询等
• 账户底线原则：支付成功才入账，扣账成功才出款

如何设计账户类型：

就像有的公司叫产品经理，有的公司就产品策划，有的公司叫需求分析师；但本质做的都是产品设计工作。如可以按照如下分类为账户命名：

• 基于主体类型命名账户：个人账户，企业账户
• 基于业务类型命名账户：电商商家结算户，快递商家结算户
• 基于资金属性命名账户：工资账户，公积金账户，手续费账户
• 基于账户职能命名账户：待清算账户，中间担保账户

01 在线租车-账户系统解析

会开车但还没买车的小伙伴们，周末出游、节假日出行，或者出差办事，大家是不是首选租个车？好处当然就是不用加入拥挤的人潮，可以做那个最自由、随性，条条街最靓的仔！

伴随用户租车需求的日益增长，提供租赁服务的中小企业也越来越多，而租车SaaS平台就应运而生，主要是撮合汽车租赁企业（商户/出租人）和租车人（用户/承租人），提供在线租车交易闭环服务

比如通过与第三方认证机构与持牌金融机构合作，为租车业务提供风险管理和交易见证及资金担保服务，解决交易信任问题，保障交易双方的权益。

下图就是租车SaaS平台的业务模式概览：

在租车服务过程中，存在商户与用户之间的支付退款业务（主要是下单支付租金、续租支付续租租金、线下提车支付押金等场景），商户与平台之间的分润结算业务（看业务模式，主要是平台服务费或交易佣金），以及平台与第三方支付机构之间的手续费结算业务，围绕不同角色的不同结算业务就需要建设账户体系。

下图是某个租车SaaS平台与第三方支付机构合作设计的账户体系建设需求雏形，满足特定业务场景的交易需求，目的是实现资金监管与清分。

下图是账户间基于主要交易场景的资金流拆解：

账户系统，核心是管账。首先要向上游客户中心提供入网开户和账户信息查询服务，包括银行卡绑卡鉴权、账户余额和流水查询等；当接收来自上游订单系统/清结算系统的记账请求时，要根据规则做好入账处理；当商户发起账户提现请求后，还要通知下游结算系统完成审核出款。

平台基于第三方支付账户的底层能力，包装出一个面向商户的钱包应用，本质还是账户。底层是基础能力，中间层是基于基础能力封装出来的服务单元，比如针对平台商户和用户的企业工商认证、个人实名认证服务，最上层是钱包应用，商户开通钱包后，可查看余额、账单流水、进行提现等操作。

将业务的记账请求通过配置好的入账规则、冻结规则进行处理，进入到账户系统并且生成账户流水，然后更新钱包账户余额。

一个钱包账户多个余额：

冻结余额：应收应付入账（信息流）；租金&续租租金支付款项进入担保户时，入账记为商户收入，进行冻结处理；

可用余额：实收实付入账（资金流），映射第三方支付机构的支付账户可用总余额；租金&续租租金分账给商户后，入账记为内部划转款项，进行解冻处理，由冻结金额转为可用金额；平台台服务费、支付手续费扣款后，入账记为支出。

钱包总余额：钱包总余额=冻结余额+可用余额，用于前台包装展示钱包账户余额。

通过任务流更新钱包余额：

设定账务处理任务流，每笔入账都需要从头执行到尾，不能遗漏，任何一个环节处理失败了这笔入账就进入入账的失败处理（将该笔流水的原扣账金额返还钱包），直到入账成功结束。

通过费用类型设计资金流：

入账和冻结处理规则主要依赖预先设定好的“费用类型”，费用类型是基于特定业务场景下的业务类型定义的，规则中设置好参数、入账方向、流入流出账户等内容。

可查看平台钱包用户的全部账户，包括账户的基本信息，所属主体，账户类型，账户余额等内容，还可联查账户流水明细。

以钱包用户（商户）视角，记录租车业务下各钱包账户的资金变动明细记录，记录对手账户、收支方向、金额、费用类型等基本信息。

02 线下游乐-账户系统

先简单介绍下「线下游乐行业」的角色结构，一般来说有设备厂商、内容制作商、品牌方、加盟商等众多角色，通过下图可以大致的了解下它们的关系。当然很多企业也会同时拥有多种身份，比如品牌方自己就是设备厂商和内容制作商。

在上图的角色结构下，品牌方有两种基本的业务模型。

一是自己将设备和内容包装好进行招商加盟。

二是自己充当一个独立的平台方，链接设备厂商、内容制作商以及加盟商。从商业的角度来说后者比前者有更大的成长空间但是投入的研发成本和获取行业资源的难度后者远高于前者。

所以一般的品牌方是先采用第一种业务模型将自身做大，然后想办法成长为第二种业务模式。

这里我们主要讨论的是第一种业务模型下，品牌方为了满足运营需求而搭建的自研管理系统。该系统需要为加盟商提供收银的能力，为品牌方提供分成结算的能力以及为双方提供数据报表的能力（这里只列举几个关键的能力）。

假设品牌方的分成方式为按时计费或按次计费，那么品牌方的分成和订单支付金额将没有关系。在这样的前提条件下，品牌方设计这套系统时同样有两种模式

一是收银台只是提供给加盟商的收银工具，帮助加盟商完成正常的营业工作，品牌方分成通过人工结算收款或从加盟商预付款账户扣除，我称这种模式为预付款模式

二是品牌方统一收款，再通过银联等第三方机构分账，我称这种模式为分账模式（需要注意这种模式下品牌方的分成和订单金额无关）。

上述两种系统模式，预付款模式简单而成长空间小，分账模式困难但成长空间大。预付款模式只需要为加盟商创建一个预付款账户即可，分账模式则需要创建品牌方账户和加盟商的分账账户。为了政策合规，分账模式一般是在第三方机构建立品牌方账户和加盟商分账账户，自己的系统内的双方账户只记录数据，并不会产生实际的交易行为。

于是同样的情况再次上演，品牌方一开始先采用预付款模式先将业务跑起来，当业务规模做起来后再引入分账模式。这就不可避免的在引入分账模式后的一段时间内存在双模式并行阶段，本文就将针对这种情况下的加盟商账户业务进行分析。

账户产品架构图

如下图所示，加盟商账户中心主要承担的职责是接收上游系统的记账请求，并根据入账规则确定应该计入预付款账户还是分账账户。此外账户信息的查询服务，账户余额及流水的查询等基础服务是不可或缺的。账户业务流程图：

整个账户产品的架构如下图所示：针对预付款账户具有余额管理的功能；针对两个账户都有账户管理、交易流水、交易管理的功能，但针对预付款账户提供的是充值和余额支付的能力，针对分账账户提供的是结算入账的能力。账户系统产品架构图：

针对单独的分账模式，因为主要的交易过程发生在第三方机构，本系统内只记录分账账户的交易信息，所以无特殊的入账规则，按上游系统传达的信息正常录入即可。

针对单独的预付款模式，虽然交易的过程发生在系统内部，但是因为预付款的业务比较简单，没有冻结等操作需求，所以只需要区分好本次记账是充值还是支付即可（不考虑一个加盟商接入多种分成模式的情况）。

针对同时拥有预付款账户和分账账户的，记账是基于配置好的入账规则进行。这里需要先具体说明一下加盟商是如何产生两个账户的：品牌方之前采用预付款模式给加盟商开设预付款账户，现准备对部分加盟商采用分帐模式，于是给加盟商开设了分账账户，所以加盟商暂时拥有了两个账户。

在这种情况之下，入账规则的配置就极具个性化了，分成费用可以是优先入账预付款账户、也可以优先入账分账账户，甚至是按比例都可以。

规则配置页

需要注意的是只有多个账户的加盟商才需要进行入账规则的配置

账户管理页

账户管理页内会显示所有加盟商的账户，如果一个加盟商拥有两个账户则会都显示出来，对账户的管理只有简单的开启和关闭操作，就不做演示了。这里需要注意的是分账账户因为并没有实际的资金入帐，所以没有余额。

账户流水页

账户流水管理可以查看账户的全部变动明细

预付款账户因为有实际的金额入账所以会有余额这一项。而分帐账户只用于记录账户流水，资金流转并不在自己的系统内产生，所以不记录余额只记录金额。同时因为这种特性，分账账户的流水中只会显示每次分账的最终收入。于是在每一条的流水下会显示子流水明细，显示营收和实际收入之间的关系。

03 旅游门店-账户系统

旅游门店系统是供加盟门店的经营者使用的系统，满足门店日常经营需要的功能及总部对门店的管理功能。如门店资金充值、产品预订、订后服务（包括合同、发票、扣税、保险等）、门店惩罚等。

客人在门店支付订单时，门店需要在系统上下单并给总部支付卖价，客人返程后，总部又需要与门店进行分润。门店有了利润之后，又可能会产生相应的利润支出，如支付门店员工工资、支付手续费等。

所以，在门店系统场景下的账户系统主要用于门店各交易场景下的结算业务，客人对门店的结算、门店对总部的结算、门店对员工的结算等。

账户业务流程和产品架构

线下整个的资金流程是，客人在门店将卖价（门店与客人沟通的价格）付款给了门店（实际资金流入了管理门店的总部）->系统自动将资金上账至该门店的账户->门店在系统操作下单->客人游玩返程后，将所得利润（卖价-底价）上账至门店利润账户->门店提取利润账户至个人银行。若门店不提取所得利润，这些获得的利润也可以用于门店员工工资的发放、发票、税费、保险费的支出等。

同时，总部又可以在后台系统控制门店的信用分账户，若该账户金额低于阈值，会对门店进行惩罚，如无法下单等。

账户系统架构在最底层是系统的基础能力，即展现给用户的功能。包括账户管理、交易流水管理等，中间层是需要满足基础能力封装出来的服务层架构，最上层是基于服务架构集成的资金管理。

入账规则和逻辑

会根据对应配置好的具体交易场景来入账

账户主要产品页面

账户列表包括交易场景、交易单号、账户期初余额、收支、期末余额、及本次交易具体场景的备注等。

04 家政-账户系统

家政平台是撮合劳动者和终端消费用户的平台，建立服务者与消费者之间的服务关系。其中，劳动者包括月嫂、保姆、保洁等，提供的服务包括月嫂服务、育儿嫂服务、保姆服务、保洁服务等。

服务结束后就需要给劳动者进行服务收入的结算，而在业务发展中，又存在劳动者以及用户的介绍人，从而存在转介绍的场景；同样，也会在一些城市签约代理商，就有了渠道商的场景。在这些场景中就有了与介绍人和渠道商的分成分润结算业务。

所以，家政场景下的账户系统主要用于各类角色的结算业务，对劳动者的服务收入结算，对介绍人和渠道商的分成分润结；而账户种类的建设就是围绕不同角色的不同结算业务建立。

劳动者的收入结算账户、合伙人的分成账户、渠道商的分润账户等，再结合一些其他场景比如保证金缴纳场景，又增加了保证金账户。

做为记账系统，这里的账户系统主要是接收来自上游系统的记账请求，除此之外还需要向上游提供开户服务，账户信息的查询服务，账户余额及流水的查询等服务。

下图也包含了渠道商与账户有往来的业务。

账户系统架构上最底层是账户的基础能力，包括主体管理、账户管理、交易管理等，中间层是基于基础能力封装出来的服务单元，最上层是基于服务单元集成的解决方案。

账户记账是一个非常重要的环节，该账户系统的记账是基于配置好的入账规则进行，而规则中主要依赖预先设定好的“费用项”，再介绍几个入账参数匹配到入账规则，规则中设置好入什么账户、入账的方向等内容。

账户列表按照账户的维度可以查看全部的账户，包括账户的基本信息，所属主体，账户类型，账户余额等内容。

账户信息是某一个具体账户的详细内容，该页面可以对账户进行冻结、余额进行冻结。

账户流水管理可以查看账户的全部变动明细。

05 ETC-账户系统

ETC钱包是用于高速ETC通行消费的专用账户。由于现在大部分ETC为记账卡，也就是先通行后付款的模式，因此车主需将通行费充值到ETC钱包才能在高速通行后进行正常扣款，一方面满足部分不想使用代扣模式的用户的需求，另一方面也算是为了降低经营单位的垫资风险。

若车主未提前或及时在通行后存入通行费导致扣款失败，且没有按时补缴的则会被列入高速ETC限制通行名单，直至缴清欠款后才会解除。（ps.ETC被列入限制通行名单，则只是走不了ETC通道，可以走人工通道。当然ETC逃费是违法的哈，也是会被稽查的~）。

欠费之后，ETC钱包就会被扣减至负数，直接体现出当前欠款金额。此外根据ETC产品的不同，欠费超过一定次数或者时长也可能产生违约押金，延伸出了违约押金钱包。

而为了抢占市场，经营单位如果给用户补贴通行费用，则又延伸出了红包钱包。

钱包账户模块，最主要是接收来自账单模块发起的通行账单扣款记账和支付模块发起的充值记账，其次伴随着车辆用户欠款违约，会产生违约扣款记账；车辆用户注销，则需要把余额提现返还给用户；更有用户偶尔的多充、错充，导致需要给用户充值退款。

常规的账户业务流程如下图。

初由于ETC扣款的场景没有特别多，入账规则和逻辑并没有走配置化，费用场景也是代码枚举写死的。

当业务有对应的交易场景的时候，比如分佣、奖励、违约金、消费等，可以根据我们预先配置好的入账规则，来决定给某个主体的哪个角色的哪个钱包加钱还是减钱，是否冻结金额，怎么冻等等。

当业务场景多的时候，用户名下账户也多起来的时候，如果要快速支持响应业务场景的变更，那就需要更灵活的配置来实现，而不是每次去改代码，并且有管理后台记录我们每一个账户场景，也便于业务运营。

下图以ETC举例子，当建设了统一账户系统之后，可以根据不同的业务线配置和修改不同的入账规则，如每一笔推广费用如哪个账户、是否冻结，冻结多久等。

在ETC违约欠款这个场景下，还有一个比较特殊的点跟大家分享一下，用户欠款之后钱包余额往往为负数，违约之后会被扣取一笔违约金，但是此时往往是扣不到钱的（因为钱包余额已经不足），而实际扣取到的违约金是记录在上述【违约押金账户】，等到用户注销之后是要退还给用户的。

在用户端需要给用户展示两个信息，一是用户目前所有欠款金额（路费欠款+违约金欠款），二是用户违约金，如果没有新增一个【待交押金账户】，用于区别用户实际扣取到的违约金，和仍需缴纳的违约金，则无法区分用户的钱包欠款有多少是属于违约金欠款，也无法定义用户如果部分还款的时候是先还违约金欠款还是通行欠款。

账户列表：

账户主体信息：

入账规则配置：

如果企业业务涉及到多客服咨询的业务，给客服同事聚合一个查询页面，能快捷地查到某个用户（主体）名下各类账户信息及其他业务信息。

06 电商-积分账户系统

积分电商平台是一个撮合商家和消费者的平台，销售商家入网到平台，上传相应的产品，用户通过平台公域商城或商家私域商城购买商品，用户支付方式有全积分、积分加第三方支付、全额第三方支付。平台通过支付方式及积分抵扣金额计算并生成支付单。

商家入网成功后，平台将生成积分账户和现金账户，积分账户主要用于计算用户积分抵扣部分，结算时平台将通过第三方代付或营销补贴进行金额结算；现金账户主要记录用户通过第三方支付的金额，结算时平台将通过分账进行订单金额结算。

因此，平台账户系统-商家角度，主要用于记录商家的资金流水及总额，分为已结算金额、冻结金额、在途金额；平台角度，生成平台使用费账户，主要通过商家设置商品的积分比例计算出的平台抽佣金额，可分为已结算金额、冻结金额、在途金额。

另外用户在平台每消费一笔，都会按照积分比例产生相应的积分赠送，所以还会有用户积分账户。

账户系统的记账，主要通过订单履约系统订单支付成功后发出的记账请求完成账户之间的收入流水、退款流水、提现流水等。当订单完成时订单履约系统又会请求账户系统，并且将各角色的账户推送至结算系统，由结算系统完成相应的现金、积分结算，现金将T+1进入商家对公账户，积分将实时到达用户账户。

账户系统涉及平台主体的管理、账户类型管理、账户管理、各账户流水的变动明细、账户操作和通过账户信息生成的报表展示；商家入网成功后，系统将生成类型所涉及的账户号，并在销售完成或消费成功后产生账户明细记录及账户余额变动，并由各个子系统之间共同完成。

用户在平台消费产生订单，商家执行订单履约，履约完成后用户确认收货，此时系统将执行清算，订单内第三方支付金额将记入商家收入现金账户，如果有积分抵扣部分将记入收入积分账户，具体入账金额计算方式为通过订单内商品设置的积分折扣，计算出每个商品需要收取的平台使用费，在按照积分抵扣比例，分别计算到每个商品上，最终计算出平台现金佣金X元，平台积分佣金Y元，订单实付金额扣除平台佣金后为商家实际入账金额；在清算完成后入账资金状态为可提现金额，系统定时执行请求第三方结算资金。

另外在订单确认后，系统还会计算赠送用户积分数，同样按照商品积分比例，求和统计出每个商品应赠送积分数，并将积分入账到用户积分账户，用户积分不可提现，只可以在下次消费时抵扣使用。

账户列表页主要展示账户所属主体，账户当前余额、账户在途金额（产生订单未入账）、冻结金额（异常情况操作冻结）、账户创建时间、类型等；因对接第三方机构，结算按照订单来执行，账户金额总数为明细内订单不同类型的总和，平台可针对明细进行冻结/解冻操作（仅限待结算）。

平台收入=订单总金额-商家收入，会产生增加，但因为积分部分平台会涉及营销补贴至商家，会从平台收入内扣除，平台总收入-总支出=总利润。

07 校园一卡通-账户系统

一卡通平台用于管理学生各类活动的充值及学生校内消费。一卡通平台提供一卡通充值服务及一卡通消费服务，包含餐费充值及消费、水费充值及消费、电费充值及消费、公话充值及消费等等。

学生通过充值点进行一卡通充值，学生消费后，平台从中获得一定比例的平台服务费。

账户中心是整个平台的核心，主要的业务流程如下，包含学生账户的开立，一卡通充值、一卡通消费及其分账的过程。

账户中心主要包含账户主体信息管理、账户管理、账户流水管理。账户根据账户科目的设置可建立层级关系，主要目标是把账记清楚。

一卡通充值入账规则：选择充值人、一卡通充值费用类型、充值金额，充值成功后，在费用类型账户中记入充值金额。

一卡通消费入账规则：学校一卡通消费时，不同的刷卡终端设置不同的费用类型，根据费用类型进行一卡通账户的记账。

分账入账规则：不同商户设置不同费用类型的分账规则，分账规则中含有分账收入方信息，根据一卡通消费记录中的费用类型匹配分账规则，算出分账明细，在分账收入方账户中记录待结算明细。

结算入账规则：通过结算定时任务进行账户中待结算数据的结算，并将待结算明细更新为已结算。

08 银行收单-账户体系

银行建设的收单系统一般会涉及结算户、内部户、虚拟户等。

结算户是指商户的收款账户，因为商户账户的资金都是收单未结算资金，银行一般要求商户开立本银行的账户作为结算户。

内部户是指机构为了方便其结算资金使用的过渡记账账户，这类账户都是机构预设的，只有机构才能操作这些账户，商户对其是无感知的。

虚拟户是指收单系统内部的建立的一套登记簿，不属于银行账户，仅仅用于记录多种交易场下的记账。下文讲到的客户待清算、待结算、已结算等账户都属于虚拟户。

支付平台（收单系统）对接银行核心系统，业务平台于银行内部核心系统开立总账户，支付平台内开立平台商户、平台用户二级虚拟户。收款资金沉淀在银行，通过支付平台指令由银行将资金清算至平台商户、平台用户的实体资金账户中，实现资金流转合规化，规避二清风险。

账户系统主要实现建立多级账户体系、凭证管理及账户记账等功能，可满足账户扩展功能及新业务接入时自动记账规则配置。

银行仅需为平台在核心系统中开立内部户，无需对现有系统进行任何改造；电商等平台子商户通过调用支付平台商户入网提交资料请求接口，完成在银行支付平台中子商户信息录入和开户、个人信息录入和开户、银行卡绑定，符合小核心、大外围的核心思想。

平台商户和交易商户入网成功后，支付平台会生成如下账户，主要包含待清算账户、待结算账户、已结算账户以及基本户等。

根据不同的交易节点讲解入账逻辑，本文主要讲解支付、分账、结算以及提现对应的记账逻辑。退款、对账等场景由于篇幅原因暂时不讲解。

用户在优选平台上下单，选择某种支付方式完成交易。支付成功后支付平台（收单系统）会做一次记账。以优选为平台商户，海盐为交易商户为例，用户张三在优选平台海盐店铺购买一件商品1000元，使用了微信支付，用户支付完成后支付平台（收单系统）会进行清分记账，记账结果如下：

备注：记账顺序从下往上看

用户确认收货后进行分账，支付平台（收单系统）根据优选平台分账指令进行分账，分账到平台商户及交易商户账户中。假设分给海盐900元，分给优选平台100元，记账结果如下：

备注：记账顺序从下往上看

T+1日支付平台根据结算规则生成对应的结算单，然后再给平台商户和交易商户打款，平台未接触到资金，由收单系统进行清分结算，业务操作合规、资金安全。

备注：记账顺序从下往上看

系统根据提现规则，支持自动提现和手动提现。下图中监管账户是由支行开立的内部户，平台无法操作账户，只能提现属于其的资金。

备注：记账顺序从下往上看

重点说明：客户未提现前的资金都存放在银行的监管账户中，平台无权限挪用资金，当客户提现或者系统自动提现时，资金由监管账户到客户账户，整个环节保证了资金的安全。

整个交易的过程资金流走向如下图：