当平台需要对商家进行扣款，当发现余额不足的情况，也就产生了商家对平台的欠款。那么对于这种“欠款账户”，该如何处理呢？

听说过欠款账户么，本文好好唠唠，其账务处理特别有意思。

对于一个撮合型交易平台来说，如京东、淘宝、美团等，必然会存在逆向业务，比如订单退款，出现投诉以后平台要扣商家一笔罚款等等场景。

以上场景都需要逆向扣除商户收入结算账户里的余额，此时就可能出现余额不足的情况。

这种情况，也就产生了商家对平台的欠款。

如何处理这种场景呢？这里有几个方案可以选择，最后一个是本文的主角——“欠款账户”。

一、余额不足，业务请等着

这种方式最粗暴，业务层业务发生以后请求账务系统，申请扣除商家一定金额，账务系统基于余额不足直接返回“余额不足，扣款失败”。

此时，业务层收到了失败结果，就要想了，我该怎么办？

罚商家的钱还好说，毕竟是一笔意外之财，那就再等等，等商家余额充值时，再申请扣除。

而对于订单退款来说，用户要退，而商家账户余额不足，那要不要给用户退，不退吧，对不起用户，退吧，平台得垫资。

因此，如果要强硬的根据商家侧能不能退给平台，来控制业务侧订单能不能给用户退，那么就相当于用户发起退款时要校验商家余额是否充足，不足时便限制退款。

这样的策略，对用户来说必然是体验的极大损失，毕竟现在大家都崇尚“仅退款”。

如果即使商家侧余额不足，依然给用户正常退，那么因为账务系统没有受理业务侧的扣款请求，所以在业务层有“待扣款”的业务单据，相当于业务将不能完结。

此种情况，一些与商家的待处理资金业务沉积在了业务层，这个方案很显然会被业务层极力反对，除非你很强势，否则很难推行。

二、业务正常完结，账务进行排队

本方案将释放业务侧压力，业务请求过来以后，直接返回接受成功，业务侧不用关心账务层的处理结果，专人干专事。

而账务系统记录了业务单据，并产生了扣款的凭证，订单收入退回或者罚款。

当请求账户扣减余额时，发现余额不足，那么凭证状态保持“待扣款”，等待商家账户有新的入账。

这个方案的好处是释放了业务侧对账务处理的依赖；缺点就是排队的待扣款处理起来也非常棘手。

一方面是待扣款凭证会越积压越多，另一方面就是虽然余额不足，但是还有一点余额，这时候要不要先扣部分余额，极力减少损失。

这就出现新的问题了，这就意味着，会存在扣款凭证扣了部分金额，也并没有完结，如此一来账务处理变得非常臃肿，永远有在路上的凭证无法入账

三、简单粗暴，账户直接透支

这下整个世界都安静了，简单至极。

随便扣，我直接让账户扣成负值，后续有收入直接抵扣了负值，非常简单。

当看到一个商家的账户余额是负值时，就知道，他欠平台钱，这就是纯天然数学算法的碾压式魅力。

这部分欠款，可以通过后续的收入自动偿还，也可以通过提供给商家充值的工具来偿还这部分欠款，还钱的能力在《还款“收银台”》一文中有详细地介绍。

当然，该方案也需要一些新的能力，比如风控的能力，能透支，但是不能无限透支，需要一定策略加以限制，比如设置透支限额，超过限额时需要联系商家进行偿还欠款才能继续经营。

当然，有时候可能会有人反对扣成负值，那么还有另一个办法。

四、欠款账户，咱换个地方记

可以透支，但咱别记到原来的收入账户，直到为0以后就不要再扣了，我们借一步说话。

我会为你偷偷开另一个账户，专门记透支部分，叫“欠款账户”。

新的问题来了，这两个账户关系如何，如何进行账务处理。

比如，商家收入账户有100元，我要扣150元，如何操作账户，收入账户出100，欠款账户出50分？

显然是可行的，但貌似对账务处理层的能力要求较高，相当于，账务处理层要“拆分凭证”，将凭证一分为二。

该方案看似顺理成章，但是，账务处理部分就复杂了，因为要基于账户余额情况拆分凭证，可操作性难度大。

于是，将欠款账户属性降级，区别于收入账户，并将欠款账户与业务层进行隔离，单独形成一个记账区，仅与收入账户发生账务往来。

在这种模式下，有2个基本原则：欠款账户仅与收入账户发生垫资和还款的内转账务处理；两个账户都仅进行完整的账务处理，不进行凭证拆分。

如图所示，分别分析支付场景和收入场景。

当支出类场景发生时判断收入账户余额是否充足，如果不足时先出发“欠款账户向收入户垫资”，让收入户余额充足，然后再进行扣款处理，相当于对于收入账户的支出永远是在余额充足时进行的。

当收入类场景发生时，收入户正常入账，没有特殊的账务处理，而需要增加一个随后的子账务处理，就是判断欠款户是否存在余额，如果存在，由账务系统自己发起一个“还款”的账务处理动作，将一部分收入余额转入欠款户进行偿还。

此时，欠款户需要增加一个账户风控策略，以控制额度上限和欠款拖欠周期长度，超过阈值以后，将商家扔进异常池，进行后续的处理。