我们知道账务系统是用会计核算的理念来设计，生成、记录并处理账务，提供账户余额、授信的系统。本文阐述的账务系统集中在对外部账（即客户账）的实时处理。
账务系统的搭建在落实到实践的过程中，并没有标准统一的方法，需要根据公司本身的业务以及需要达到的目的灵活地搭建。
一、理解业务
笔者是做海外面向B端发卡业务的，我们把具体的业务抽象出来这边做个简单汇总，方便我们接下来分析怎么去搭建账户系统，读者在实践中同样要完整地理解自己公司的业务后再去制定方案。
1. 发卡
我们会向企业发卡，卡类型有借记卡和信用卡，每家公司支持发多卡。借记卡不可透支，每张卡有单独的余额，消费金额不可超过卡片余额；信用卡可透支，向一家公司下发的所有信用卡共享公司授信的总额度。
2. 入账
借记卡充值或信用卡还款。
3. 消费
持卡人持借记卡或信用卡消费。
4. 转账
分两种，一种是借记卡卡内余额转到同公司的另一张借记卡，再有就是借记卡余额转出到外部。
5. 其他
除以上的大家经常需要处理的业务外，不同公司会有不同的业务场景，但实践过程中基本都可以参照以上的场景的账务处理逻辑。如果业务场景中需要用到账户冻结，或账户内金额/额度冻结，自行增加即可，本文不会再详细展开。
二、账户&分录
充分了解了公司业务后，我们就可以着手制定我们的账户和分录。
1. 账户
对标会计科目，账户会更细分指定到每个具体客户，即科目和账户的关系为一对多的关系。由于账务系统通常更关心外部账（即用户账），所以我们需要的科目并不多，我们先讨论最基本的：银行存款、用户存款、客户授信。
因为上面我提到过，我们的业务是每张借记卡有独立的余额，而信用卡则是一家企业公用一个授信额度，仅仅是通过卡的介质把额度消费掉。那么我们可以建立科目和账户的对应关系如下：
2. 分录
我们按照上面抽象出来的业务逐个看下分录怎么做：
（1）发卡
向企业下发借记卡：不需要记录分录，但是需要在发卡前建立好这张借记卡对应的账户。账户的命名方式各种各样，有时候为了更好从业务角度理解账户名，我们可以建一些规则，比如第一个字节用1表示借记卡，第二个字节用1表示特定的发卡行等等，都可以根据大家自己的喜好来命名。
向企业下发信用卡：不需要记录分录，但是需要在给予公司授信前建立好该公司总授信额对应的账户。
（2）入账
借记卡充值：
- 借：银行存款
- 贷：用户存款（充值的借记卡）
信用卡还款：
- 借：银行存款
- 贷：客户授信（还款的企业）
（3）消费
持卡人持借记卡消费：
- 借：用户存款（消费的借记卡）
- 贷：发卡行备付金账户
持卡人持信用卡消费：
- 借：客户授信（消费的信用卡所属公司的授信账户）
- 贷：发卡行备付金账户
（4）转账
内部转账：卡内余额同公司内转账：
- 借：用户存款（转账的借记卡）
- 贷：用户存款（转入的借记卡）
外部转账：卡内余额转出公司外部，首先扣除用户的借记卡余额。有时候用户的借记卡余额虽然扣除了，但本身转账不一定发生，或者为了业务方便统计转账总金额，我们会引入一个中转账户（对应负债类科目）——待转出账户，当然如果大家业务上不需要，可以不引入。
- 借：用户存款（转账的借记卡）
- 贷：待转出账户
从转账渠道发起转账后：
- 借：待转出账户
- 贷：转账渠道账户
（5）其他
以上四种场景的分录包含了虚拟账户的入账、出账，有业务上的独立账户，也有共享账户，还引入了中间账户，其他的业务场景都可以参照以上的分录来处理。
三、后台交互逻辑
然后我们来看下账务系统怎么跟交易系统合作完成一笔交易。
在B端场景中给卡设置一些限额，或者给卡上锁终止后续交易都是非常常见的，我们要尽量把这些限制和账务系统区分开来，账务系统更关心账户的余额和分录。我们抽象出来有一项服务叫卡中心，卡中心专门负责处理卡状态、商户黑名单、卡限额等逻辑。
这里先记账后返回交易结果保证了交易与记账的一致性。
四、对账
最后我们来看下对账，下面列的三种应该可以覆盖大家的业务场景了。
（1）外部系统交易对账
与外部系统有定期的核对，保证双方中任务一方不存在比另一方多单或少单。
（2）交易系统与账务系统对账
确保期间内交易系统中所有订单在账务系统中都有对应的分录产生和处理，实践中一般我们会记录每一笔分录，以及处理该分录对应的账户余额的变动。
（3）账务系统内部自查
确保期间内账务系统中每笔分录处理正确。实现方法可以是对所有账户，检查上期余额加上本期发生额是否等于账户期末余额。
以上三项中，第一项一般所有的公司都会有相应的对账策略，第二项和第三项可以酌情考虑是否制定相应的对账策略。
本文由 @西门吹雪 原创发布
微信扫一扫 
支付宝扫一扫 
