金融支付财务融合业务-实践分享2：SaaS租户、资金账户、财务账套、记账及对账系统架构设计

本文作者从实际工作实践出发，结合案例等分享了电商金融支付财务融合中的基本概念和相关原理解析，包括：SaaS租户、资金账户、财务账套、记账及对账系统架构设计，与大家分享，希望通过此文能够加深你对金融支付财务相关业务的认识。

上篇文章同大家分享了“ 金融支付财务融合业务-实践分享1：订单、账单、交易流水、账套知识解构、原理解析” 。重点向大家介绍了“金融、支付、财务”融合业务中的“订单、账单、交易流水、账套”等知识进行了概念解构、原理解析，并以支付宝、微信支付两个案例进行逆向解构，但对“账套”未做深入展开。

本篇围绕“商户租户、账套、资金账户、记账、对账”这几组概念，以我们的SaaS金融平台的建设实践经验向大家深度、系统讲解“金融支付财务融合业务”场景下我们如何处理好业务账、财务账之间的逻辑关系及产品设计策略。通过也即从如下几个维度向大家系统讲解：

1. SaaS架构下多租户的账户产品架构设计原理及实践分享；
2. 同一商户多资金账户的业务流、资金流、财务流产品架构设计原理及实践分享；
3. 同一商户不同组织的的业务流、资金流、财务流产品架构设计原理及实践分享；
4. 同一商户不同业务板块的业务流、资金流、财务流产品架构设计原理及实践分享；
5. 商户线上、线下财务收支账数据融合管理的产品架构设计原理及实践分享；
6. 通过多场景参数记账策略，设计“会计分录引擎”来实现一笔记账，自动完成会计分录的自动化作业设计思想及实践分享；

阅读对象：电商同学、金融同学、支付同学、SaaS同学、财务ERP同学及财务专业人士。

一、“业务财务金融支付融合业务”是个什么概念？

用户要想真正了解本篇分享的目的、价值及背景，必须先把这个问题给吃透了，后面的知识体系吸收将水到渠成。

1.1 业务背景

1. 电商业务、金融业务等IT平台多是面向业务系统的，也就是所有的业务链路、数据记录、数据封装（报表）都是围绕业务进行的。
2. 很多公司都是业务一套系统，财务一套系统，决策层如果想看整个盘面的数据必须看两套数据：业务报表、财务报表。
3. 业务报表数据具有实时性，财务报表数据具有滞后性，上述1和2的存在导致公司在财务上的人员投入、资金利用效率、数据利用效率不高，综合来讲就是“数据内耗”；
4. 业务记账是流水账法，如我们的订单表、支付记录、投资记录、派息记录、还款记录。
5. 财务记账是复式记账法，复式记账是基于“资产=负债+所有者权益”或者扩展公式“资产+成本+费用=负债+所有者权益+收入”进行会计分录记账，而一旦涉及到分录就会涉及到一笔交易进行分拆记账——不仅财务工作量倍增、出错率也很高。

1.2 设计诉求

1、向商户提供IT作业系统、聚合支付系统、存管银行账户托管、及财务记账及总账管理系统，也即通过“财务业务一体化解决方案”向商户提供业务平台发生的每一笔数据都能自动完成业务记账、财务记账，将业务数据与财务数据打通，减轻财务人力成本、降低账务出错率、提升对账速度、业务财务数据穿透打通、资金及数据周转速度提升、企业风险提前识别、预警及决策辅助。

2、为商户提供线上业务、线下业务及财务账务管理金融支付财务融合业务，打破企业业务系统已IT自动化、而业务平台的数据无法承载企业日常运营、线下业务所产生的数据，必须依赖第三方财务ERP系统进行独立的财务数据维护。也即通过“财务业务一体化解决方案”向商户提供财务作战平台，除可满足企业面向客户的IT自助平台外，企业内部的所有与财务相关的（这里主要指线下发生的）资金进出清结算、财务记账等传统工作均通过系统一站化解决，进而解决企业的“信息隔离”、“数据隔离”、“资金隔离”、“账务隔离”、“业务链路隔离”，为企业线上业务、线下业务、日常运营提供一站化作战平台。

3、通过统一资金收款、统一资金出款为企业线上业务、线下业务、日常运营所需的现金流、赊销流提供统一资金清算、结算、记账（登记）服务，提升资金利用效能、提升资金预防式管理指引。

4、支持商户对不同子组织、业务板块提供进行业务、资金、财务三维度管理及数据透视，方便企业从横向业务管理、纵向组织管理两个维度进行精细化经营，提升企业的情报决策效能。

二、账户、资金账户、存管账户、财务账套、项目账户间的逻辑关系

2.1 商户账户

账户特指SaaS平台为商户提供的一级账户，商户超级管理员可自行配置企业的组织架构、员工角色、员工权限及业务链路。如阿里云、有赞、金蝶、用友、及我们的信贷云控平台loansaas.com等。

下图1为我们SaaS平台的商户侧表结构、及账户开立所需要的基础信息。

下图2为已开通商户租户的管理员进行商户组织架构及员工权限配置业务链路图

2.2 用户账户（注册用户）

用户账户特指商户租用我们的SaaS平台后自行开发的用户（客户），同一个用户可以是不同商户租户的注册用户，用户利用自己的账号在商户SaaS平台进行业务下单、交易支付等行为，将业务数据沉淀给SaaS商户租户。

2.3 客户/供应商（CRM客户）

客户(供应商是客户的一个细分场景）分两类，一类是线上业务，已是商户的注册用户，一类是线下业务，未注册为商户的用户，而是有商户的销售人员在CRM中进行客户信息维护。通过为用户建立CRM电子档案，这样无论是线上用户还是线下用户（客户）都在商户系统拥有唯一的“customer id”，进而为我们开展业务提供唯一身份识别码，也即为下文要讨论的业务关联客户、账务关联客户提供了前置工作准备。

备注：关于“用户与CRM客户数据互通”的相关介绍可详看“ CRM知识解构、策略设计及SaaS体系下的柔性开发实践分享 ”文章中第“ 2.2.3 产品设计应对策略”相关讲解，节选部分业务链路图如下。

2.4 资金账户

1、资金账户是账户的派生场景，不能脱离账户而独立存在。

2、账户与资金账户多是1对多的关系，具体有几个依赖业务场景而定。就金融行业C端来讲，通常有余额账户、冻结账户、股票账户、黄金账户、XX宝账户。就B端行业来讲，多以余额(结算)账户、待结算账户、保证金账户、手续费账户、营销款账户等来设定。

3、同一个商户的资金子账户如上述提到的“待结算账户、结算账户、保证金账户、押金账户、手续费账户、风险备用金账户”等共同构成商户的财富账户，以下图示例，用户的总财富值=210万；

4、非“金融、支付、财务”产品经理最常见到的“资金账户”有一个更通俗的叫法“钱包余额”。下表是我们SaaS平台所涉及到的资金账户，通过此表大家可以看出不同的资金账户有不同的使用对象、业务场景。

5、如果商户的某客户不是商户的注册用户，也即不具备前述“2-4”所讨论的“资金账户生存范畴”，在我们的SaaS平台，通过“客户账套”也即财务学上的“广义科目”来完成“虚拟资金账户”标记抽象。这句话比较绕，翻译成白话就是，每个客户的“customer id”就是其最底层的“资金账户”，譬如向某供应商A预付定金1000元，资金账户的主体就是“供应商A”，尽管“供应商A”不是平台的注册用户。

2.5 存管账户

1、存管账户是资金账户的子场景，特指银行或支付公司为商户及商户的用户开设的资金托管账户。商户需要在商户平台侧与上述金融机构的存管账户进行1:1映射；

2、存管账户的本意是为了防止商户（企业）触碰用户资金，从事非法动作的。但业务的灵活性、交易指令依旧有商户自身掌控，为了业务的灵活性，商户通常会在自己的平台再对上述一级“存管账户”进行拆分（如前述资金账户中提到的余额账户、待结算账户、手续费账户、营销款账户等）。通过这种拆分来完成用户资金的灵活调度和清分核算，详细介绍可前往我此前分享的 “集合理财计划：资金资产撮合系统、财务分润清结算产品架构设计” 详细了解。

下图是理财行业典型的商户平台的资金账户与存管银行（或支付机构）之间的存管专户映射关系图：

2.6 账本、账套

没有财务ERP之前，我们叫“账本”、“账簿”，财务ERP出来之后用“账套”来取代“账本”的说法，本质上依旧是为了区分集团公司不同子组织自己的独立核算体系而建立的，只不过“账套”概念有配套的凭证设置、科目设置、结账设置等一系列配套的动作，而早期的“账本”时代无这些财务ERP软件的概念。

2.7 项目账户

项目账户是一种特定业务的场景，属于另一层级的概念，不能与上述“待结算账户、结算账户、保证金账户、押金账户、手续费账户、风险备用金账户”放在同一个维度进行讨论包含关系。

反证示例1：某理财业务平台，张三有两笔投资，李四有3笔投资，系统分别为张三、李四的这5笔投资建立“项目账户”，每笔投资的回款及收益均以项目账户为边界进行约束，这些项目账户的资金或财富不能算作商户的，见下图：

反证示例2：某公司成立了一个5G研发小组，财务为该公司建立了一个项目账户，该小组的所有吃喝拉撒睡及创收都挂靠在这个项目上，通过该项目账户来透视支出、收入等财务指标。

三、SaaS多租户的“业务·财务·支付·清算·结算”融合系统产品架构设计

3.1 多资金账户概念抽象、萃取、逻辑关系下的合规产品设计思想及策略

（1）设计诉求

租户思想：

商户是SaaS平台的一级租户，如同某大型购物中心的商户租户；

会员思想：

用户是商户的用户（客户），同一个用户可以是不同商户的会员，商家只能知道自己会员的情况，不能知道其他家的会员情况。消费级SaaS平台首要解决的就是上述多商户、多用户账户的逻辑关系隔离。只不过在金融级SaaS平台，譬如我们的loansaas.com平台，还要在上述账户体系基于业务运行考虑，开立资金账户体系；

合规思想：

由于平台不能触碰资金，底层资金需要在存管银行或支付机构的存管系统监管，以防止SaaS平台或商户自己非法接触、动用用户资金。

由于存管银行或支付机构是托管机构，其自身系统一般而言只提供一个资金账户，而实际业务运行中所涉及的待结算账户、结算账户、冻结账户、保证金账户、冻结账户、项目账户等都需要有平台自己根据业务需要自行设计、开发。

平台的上述多资金账户体系通过交易指令与存管银行的资金账户体系进行同步，SaaS平台通过交易指令来调度存管银行的资金来完成资金流动。非P2P领域的某些业务场景对合规无刚性要求时，SaaS平台可以自行设置清结算引擎（资金池）来完成商家及用户的资金清算，这样做是为了让平台的资金利用率更高。

典型场景譬如批发行业的进销存软件，商户的买卖收入可以是虚账，只有当提现发生时才涉及资金流动，此时就无需在存管银行或支付系统为该用户设立资金账户。再譬如有赞的用户推广返佣平台，用户的返佣收入也只有在提现这一刻才发生资金的流动，其佣金或钱包账户也无需在存管银行开立专户。

下面是我们的金融级SaaS平台，核心要点有三个：

1. 商户及用户均在金融机构在虚拟资金账户；
2. 我们的SaaS平台为用户提供多资金账户体系——其本质是一种记账体系；
3. 金融监管线业务走存管系统规避法律风险，非金融监管线业务资金流转走内部“清算引擎”确保资金利用效率。

3.2 多组织账套概念抽象、萃取、逻辑关系及伞形账套产品设计思想及策略

设计诉求：

1. 入住SaaS平台的商户有多个子组织，每个组织都自成一套经营体系、账务体系。
2. 站在商户角度看总账，要看各个经营单元的经营流水、收支数据。
3. 站在子组织角度，只能看自己的对应数据。
4. 各个经营的单元的支出审批经过所在组织及上级组织审批（如需）通过后，其支付款项从商户的总账上进行资金出款及相关记账。
5. 同一笔业务即希望出现在子公司的账套上，又希望出现在总账上，还希望出现在业务板块账上，而记账动作要简化，要一笔完成。

SaaS平台的商户伞形账套设计策略：

• 数据权限： 通过SaaS平台的权限体系的“组织线”来控制用户可视数据的边界，也即组织边界决定其数据可视边界；
• 审批路由： 通过SaaS平台的权限体系的“角色线”和“职位线”及审批条件来控制审批流；
• 出金策略： 所有的资金出款均走集团（商户），账务挂靠到对应的经营部门、业务挂靠到对应的业务场景和经营部门；
• 入金策略： 所有的资金入款均走集团（商户），账务挂靠到对应的经营部门、业务挂靠到对应的业务场景和经营部门；
• 业务流水： 所有的业务流水挂靠到对应的业务场景和经营部门。

3.3 业务记账、会计记账概念抽象、萃取及矩阵化记账、自动会计分录设计思想及策略

设计诉求：

只需一个记账动作，自动完成资金收付、业务入账、会计分录入账——基于“会计分录引擎”和记账参数自动完成会计分录，而非像金蝶用友等传统财务ERP的需要手工分录记账。

设计思想：

1. 业务自动记账：通过系统撮合的交易通过“会计分录引擎”自动向财务中心登记入账；
2. 财务手动记账：公司线下日常运营的财务收支只需手工做一次入账登记，然后通过“会计分录引擎”自动向财务中心登记入账；
3. 会计分录引擎：通过记账提取的如下挂靠参数“经营组织、业务板块、科目、客户、订单等多维信息”及“会计规则引擎”完成一笔入账，多笔分录。
4. 清分结算：通过清算引擎、支付引擎和财务记账引擎向商户提供清算、分润及结算闭环服务；
5. 对账平台：通过“业务-财务对账”、“财务-支付对账”、“财务-账实对账”向商户提供对账闭环服务。

矩阵化记账产品策略（线下业务手工记账示例）：

1、下图是手工记账，记账人员通过“关联组织”、“关联部门”、“关联业务”、“关联订单”、“关联员工”、“关联客户”、“关联科目”、交易对手等场景化参数输入为后续的“会计分录”引擎提供决策参数；

2、通过“极速录账”中提供的模板进行参数一键提取上述“大量需要人工录入的参数”，减轻手工记账操作效率与“会计分录引擎”多参数决策的供需矛盾；

3、申报入账提数是通过前置审批工单快速完成上述“大量需要人工录入的参数”的快捷通道。

四、财务总台-财务视角下的账本数据指标封装设计思想、报表结构设计

传统财务讲究“三表”，也即“资产负债表”、“利润表”、“现金流量表”，我们的财务总台在设计上除提供上述三表外，还分别以“钱包视角”、“组织视角”、“业务视角”、“收支视角”、“消费视角”向决策层提供一站化数据查阅服务，详见如下：

4.1 钱包视角

钱包视角主要是向用户传递商户在SaaS平台各资金账户的资产分布情况，通过钱包视角让商户了解自己虚拟资金账户的现况，同时提供了向商户资金平台进行商家充值、商家提现、内部资金子账户之间转账的快捷操作入口。

为了方便了解企业钱包值的贡献或变动原因，我们在财务总台的最底部（下图2）提供了企业钱包子资金账户的对账单，方便财务决策者快捷查询各资金子账户的资金变动明细，为后续外部对账提供入口支持。

4.2 收支视角

收支视角主要是向用户传递商户的收支概况，具体又分三个子场景，分别是：

1、业务交易：见下图1中的“昨日交易”，是指站在业务成交视角看企业的运行情况，以成交笔数、成交额、退款(金融场景特指资金或债权退出）三个指标，以过往7日数据走势来向用户呈现业务运行趋势；

2、钱包收支：见下图1中的“昨日交易”，是指站在企业钱包的收支角度看企业钱包的进出账，也即我们通常说的线上账务。

3、财务收支：见下图2的，是指站在企业财务角度，不管是线上还是线下，只要涉及企业资金及账务的变动，都统一落账，也即我们通常说的“财务收支流水账”。

4、“钱包收支”是“财务收支”的子场景，特指发生在企业钱包中的收支交易，两者是包含关系。

特别提醒：

1、财务上的收入，收入是个科目，而非纯粹的“1笔进账”记账，基于前述“资产+成本+费用=负债+所有者权益+收入”和会计分录的复式记账法，我们知道财务上发生1笔收入时，除了在等号右侧的“收入”科目下记录1笔收入账外，还必须在等号左侧的“成本”、“费用”及等号右侧的“应付税费”（如需）上做分录记账，也即多笔记账记录，如下图出售商品收入100元的复式记账法示例：

2、上述讲的“收”、“支”指的以“账本为中心”的进账、出账，而非“财务上的收入”;

3、上述讲的“收”、“支”通过“会计分录引擎”自动完成“会计分录入账。

4.3 台账视角

台账视角主要想用户展示当前企业的【1-库存现金】、【2-银行存款】（含资金账户的可用余额、返佣账户、手续费账户）、【3-应收账款】（含资金账户的待结算金额、冻结账户、保证金账户、风险备用金账户）、【4-应付账款】（含资金账户的押金账户）、【5-预收账款】、【6-预付账款】的6个子钱包的资金余额。

同时向用户提供手工记账的快捷操作入口。

4.4 财务报表视角

本模块是真正意义上的财务报表模块，相对传统财务报表，我们做了如下的策略处理：

1、“简化指标”设计思想：如图，我们只向用户呈现最常用的3-4个指标，剩余指标数据统一合并到到“其它指标”，如“其它流动资产”、“其它流动负债”，如果用户想看详细的财务报表，点击【详情】即可进入标准模式查看；

2、“定制指标”设计思想：每家企业的业务不同，关注的财务指标就不同，譬如生产型企业和金融型企业对“存货”这个指标有不同的需求，我们为用户提供“指标定制”服务，用户自行定制自己的最关注的核心指标；

3、“总分结构”优先设计思想：传统的财务报表是自上而下通过“分总结构”来表达数据，我们这里用了“总分结构”，方便用户第一眼提取企业的总体财务现况数据——配合时间选择（本月、本季度、本年度、自定义起始日期）来看企业的资产、债务、所有者权益变动情况。

简易资产负债表

标准资产负债表示例

4.5 组织收支视角

本模块是方便决策者直接透视公司下属各经营组织的业务经营能力，通过组织间的横向对比来透视各经营组织的营收贡献。

收支差：这个指标直接通过现金流来透视子经营组织的生存能力；

挂账净值：这个指标作为现金收支差的递延指标，站在“往来赊销”角度透视子组织业绩中“负债、偿债”所占的分量有多大；

账户浮盈：是现金收支差与挂账净值的求和值，进一步透视子经营组织的生存造血能力。

4.5 业务成交视角

业务视角的财务台账侧重业务成交笔数、成交金额，以及不同产品的业务贡献及相关数据的走势。

我们的平台是面向金融行业的，主要业务板块为理财板块、放贷板块，这两个业务板块相对传统的电商板块更复杂——多一个“业务回收场景”，也即我们将钱投资出去，涉及一个回款计划的“兑付”机制。经营指标上需要新增加一个核心指标“财富管理净值”。

业务指标非正常的暴增通常意义上都不是正常的，或者可能是具体的业务负责人再冲短期业绩，为此我们引入了“成本”、“费用”、“收入”、“毛利”四个指标来辅助用户客观的审视各业务板块的成本消耗、毛利贡献。

4.6 平台消费视角

本视角系商户租用我们SaaS软件以及使用平台上的相关付费服务引擎而产生的消费账单，方便平台查看系统运行成本及与SaaS平台进行消费对账、开具发票等服务。

以上是我们在“金融支付财务融合业务”方面的一些设计思想和实践分享，限于篇幅原因，“聚合支付引擎”、“清结算分润引擎”、“会计分录引擎”、“对账引擎”等模块未能向大家展开说明，后续将分篇以以专题方式向大家展开讲解。

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

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