编辑导读：钱包系统是承接各类交易请求，管理余额的进出、记录余额变化的虚拟账户。钱包系统内发生的余额变动并不一定有对应的资金流。本文将从五个方面，围绕钱包系统的计费结算进行分析，希望对你有帮助。

钱包系统的上游是交易系统、结算系统、CRM等，承接来自他们的交易请求；钱包系统下游是资金系统、账务系统等。

钱包系统的业务层定义了各类交易的流水规则，底层是交易流水和资金流水，以流水账的形式记录资金和债务的变动，以及余额。钱包记录了单个账户的资金变动情况，资金的变动主要分为两种，即进项（充值、退款等）和出项（扣费、转账转出等)，下面主要介绍几种常见的交易类型：充值（打款）、支付、退款和提现。

一、交易请求

1. 充值请求

1）现金充值

• 线上充值：支付宝/微信/网银转账，以及第三方支付渠道。
• 线下充值：对公汇款。公司的银行账户收到客户的打款后，业务系统通过银企直联，获取打款金额和相关信息，生成一笔银行充值记录，再匹配相关信息，比如公司名称、用户UID、历史分配记录等，将该流水分配到正确的UID上，在账户内生成一笔充值流水。

没有银企直联的情况下，也可以由财务人工将收到的流水录入业务系统，再在业务系统完成流水分配和认领工作。

现在还有一种解决分配银行流水的做法，就是开设银行父子账户。简单说，就是企业向银行申请能够开设多个账户的服务，然后企业再将账户分配给自己的客户，一个客户分配一个专属的银行账户，客户打款到专属的银行账户内，银行再转账到企业的银行卡内，完美解决款是谁打的问题。

2）虚拟货币的充值

虚拟货币一般是作为客情赠送或返利赠送给客户的，由商务在业务系统发起充值流程。

3）充值的消耗

充值进入钱包后，会记录一笔充值类型的交易流水（实收款项）和一笔继承了交易流水的金额、资产ID、时间的资金流水，因为是资金增多，记为“+”。

如有扣费发生，会按先进先出的原则用先发生的充值流水支付先发生的扣费。被抵扣的资金流水记为“-”，直到扣费流水全部付清，资金流水再去支付下一笔扣费。这个过程就是销账。

因此，充值流水的每一笔资金流水的去向都能追溯，如有问题也可以回滚。

4）充值的会计处理

充值流水是公司的实收金额，但在财务收入确认上实收没有意义。充值流水中，未消耗的充值和已消耗但是未提供商品/服务的账款按预收账款处理，记为负债类科目。这代表以后需要用商品服务来偿还的。后续实际提供商品/服务后，预收账款转为业务收入，相关会计处理如下。

收到预收账款时：

• 借：银行存款
• 贷：预收账款

实际提供商品/服务时：

• 借：预收账款
• 贷：主营业务收入

2. 账单扣费请求

1）扣费流水（应收金额）

前面说到对账单其实是多条计费明细的汇总，那么账单执行扣费后，这每条的计费明细会产生一条扣费流水（应收金额），流水会详细记录交易类型、交易细分、发生金额、待完成金额、是否完成、发生时间、关联交易和描述等。

2）扣费核销（实收金额）

扣费流水被实际支付后，扣费流水下会记录资金流水，即实收金额，一笔扣费流水可以对应一笔或多笔执行流水，执行流水上会记录支付币种、执行前后的金额、变更金额、支付时间等。

一般而言，账户余额会按照扣费发生的先后顺序来付清扣费流水。某些业务场景下，也可以让用户指定支付的账单，而不是按先后顺序付清。

TO C的业务更喜欢说支付，因为基本都是是用户主动付清账单，而云行业主要是后付费的计费模式，需要用户在账户内预留资金，生成账单后系统会主动付清账单，其实区别在于行为的主体是人还是系统。

3）扣费流水的细分

扣费类型其实是反映资金出项的一级分类，还需要根据业务类型和交易场景来细分和定义细分类型，以便后续区分交易场景入账。下文提到的提现也是扣费流水的细分类型之一。

4）扣费的会计处理

扣费流水其实并不等同于会计上的应收金额，但业务环境中，大家一般会理解成只要交易发生，那么商品服务费用都是应收金额。差别就在于财务收入确认采用权责发生制（又称应收应付制），与之相对的是收付实现制。

• 权责发生制：只要交易发生且商品服务已交付，不管是否收到款或未收款，都应该计入收入。
• 收付实现制：以实际收款付款的时间确认收入和费用，而不是以商品服务提供的时间。

具体要看，商品服务是否已经提供给了客户，已经提供商品服务却没收到账款的按应收账款处理，计入资产类科目。

已提供商品服务但未收到打款：

• 借：应收账款
• 贷：主营业务收入

收到打款：

• 借：银行存款
• 贷：预收账款

3. 调账请求

调账即账单错误，需要对错误的账单（或计费记录）及其产生的流水进行修正。

处理办法是，先判断账单（或计费记录）的结算状态，未结算状态下，对错账单（或计费记录）进行逻辑删除，再生成新账单（或计费记录）即可，按新账单（或计费记录）进行结算；若已结算，则对该计费记录的流水生成逆向流水，即退款流水，再生成新账单（或计费记录）再次结算扣费。

4. 提现请求

前面说到退款是扣费的逆向流程，其实提现也是充值的逆向流程，将用户充值的钱退回给用户。

1）提现退回的方式

原路退回：哪儿来的退哪儿去。根据充值流水的支付渠道，发起退款，一般第三方支付系统都会支持原路退回，但是仅支持退近3个月的充值流水，超过就需要走线下提现。

线下退回：需要用户填写或绑定收款银行账户，或是支付宝账号（这里需要做好风控，判断账户主体和持卡人一致），由财务打款至客户的银行账户上。

2）提现的处理

首先，要校验提现金额是否超过可提现金额。其次，不管是哪种退回，在账户内都会发生一笔提现类型的扣费流水，并由申请提现的充值流水专门支付。付清后，资金系统再通过支付渠道发起退款/打款流程，注意顺序要先扣后出。

二、资金系统

资金系统用来承接资金收付款请求，并选择支付渠道、执行资金划拨。

1. 资金划拨

资金划拨用来处理钱包侧或其他业务线发起的资金处理请求，调动支付渠道执行资金划拨的操作。

以提现请求为例，用户发起提现申请后，钱包先执行提现类型的扣费流水。该流水执行成功，且扣清后，钱包系统调资金系统生成付款请求。再由财务人员根据付款金额、时效要求、各支付渠道余额、费率等因素选择合适的支付渠道，执行付款。

接下来，银行或第三方支付渠道就会执行资金划拨，将钱从公司的账户划款至提现用户的支付账户。

2. 支付渠道管理

维护或接入支付渠道，不同支付渠道在费率、时效性、付款要求上都有不同，如何自动选择合适的支付渠道，是支付渠道管理的范围。

三、账务系统

账务系统是会计人员使用的用于管理会计科目、录入会计分录、试算平衡的系统。简单的理解，就是“做账”的。

由于会计准则要求按权责发生制核算收入，因此钱包流水的数据并不能一一映射到账务，还需要依赖其他业务系统，比如账单系统、合同系统等，作为上游系统，共同来参与会计分录的计算。

做账务系统强调产品对财务知识和逻辑的理解，建议大家可以去了 会计六要素、“有借必有贷、借贷必相等”等基础财务知识。

四、可用余额

可用余额是将各类可用资金和额度汇总计算得出的可使用金额的总和。

可用余额=现金余额+赠送金+信用额度-未支付金额-冻结金额

需要注意的是：

1. 抵用券并不会列入计算。因为抵用券通常是有使用限制，并不能抵扣全部产品，不能作为类现金的通用货币。
2. 冻结金额。

冻结金额是用来锁定用户的一部分余额，避免用户花费后账户欠费。应用场景包括申请中的提现金额、预估消费等等。

一般有两种实现方式，根据是否计入流水分为：

• 计入流水。新增冻结类型的扣费流水和解冻类型的充值流水，冻结类型需要指定扣费/锁定的资金类型和占用顺序。解冻流水即为冻结流水的逆向处理。
• 不计入流水。将冻结金额作为负值计入可用余额的计算，流水上不做区分，解冻时只要将冻结金额调整为0即可。麻烦的是，由于未真正抵扣，因此需要明确冻结占用的资金类型和数量。不然用户分不清其他资金的实际可用额度。

信用额度：

我们这里的信用额度代表的是一个欠费额度，即允许客户赊销/欠费的最大额度，区别于信用卡的授信额度是一种支付工具。通常应用于有账期的客户上，用信用额度来判断用户的是否应该还款，以及是否要进入欠费管控流程。

信用额度是要设计成额度还是支付工具，大家可以衡量下业务需要。设计成额度会更简单点，如果设计成支付工具，那么作为一类资产，还需要考虑它的进销存，以及抵扣顺序和退款逻辑等。

五、结尾

除了上述提到的充值、扣费、提现、退款，其实还有很多其他业务场景和流水类型。

总结一下，在设计钱包时需要注意：

1. 考虑钱包内的资金种类和使用规则，并设置相应的子账户、做好进销存，比如现金账户、赠送金账户等。
2. 考虑各种场景的逆向流程，并留好审计日志。由于钱包系统涉及到钱需要非常谨慎，如果弄错需要考虑好逆向流程，并保留回退记录。
3. 根据交易类型和场景，细分好进出项类型。

本文由作者@大肥兔 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议