在金融科技领域，支付账务系统的设计和实现是构建高效、安全支付平台的关键。本文深入探讨了支付账务系统的核心设计，从账户管理、记账处理到清结算与会计服务，为读者揭示了支付账务系统设计的复杂性和重要性。通过详细的图解和案例分析，文章为支付系统设计提供了宝贵的理论和实践指导。

大家好，我是隐墨星辰，深耕境内/跨境支付架构设计十余年。

在前一篇的《图解支付账务系统入门》中，讲解了账务相关的一些基础概念和关键模块的设计要点。今天继续深入讲解支付账务系统的设计，部分内容和入门篇有重复。

10个做支付的，9个不懂账务，我也是入行很久后才开始懂账务。

在入门篇中有说到，老板把账务系统也划到我这里管理，我只得被迫学习账务知识。某日的下午，窗外骄阳如烈火，我端着一杯咖啡正襟危坐，正式开始学习账务相关知识。首先映入眼帘的是账户、科目、会计分录，翻了几遍，还是云里雾里，于是去找做账务的小弟。

问：“账户和科目有什么区别？”

答：“本质上没有区别，都是一个东西。”

我不服气，继续问：“如果没有区别，为什么又有账户，又有科目。”

答：“吧啦吧啦吧啦……（具体说什么忘记了，反正问完还是不求甚解）”

然后去查各种资料，查到的定义和描述仍然是晦涩而难以理解，硬着头皮也难以记住。不过好在带账务团队长达数年，天天耳闻目染，竟慢慢摸到了门道。

可谓近墨者黑，近朱者赤，近账务时间久了就开始懂账务。

学过之后能以自己的方式讲出来，谓之“悟道”。今天继续尝试用我自己理解的方式聊聊账务。

1. 前言

每个公司的账务系统设计思路、实现方式必然是不一样的，我个人经历过好几家支付公司，实现细节千差万别，但是整体思路都差不太多，比如账户设计一定有客户账户和内部账户，一定有中间户（过渡户），也一定使用复式记账，也都有实时记账和缓冲记账等。

而不一样的地方在于，有些是集团财务统一管理电商和支付平台的资金，有些则是分开两个团队管理，这种业务上的差异（或部门职责差异）就会体现到账务系统的实现细节。比如集团财务统管的话，就会要求会计科目的编制需要和集团财务系统保持一致，每天日切完成后要并账到集团的财务系统，一些差异处理也要受集团财务的流程制约。而一些独立运营的支付公司，会计科目的编制就没有类似的问题。

本文尝试抛开那些随各公司业务部门定制的逻辑，回到账务系统的本质，聊聊一个通用的账务系统设计要点。当然不可避免会夹杂一些我个人不成熟的见解，各位读者请以“取其精华，去其糟粕”的精神辩证地看待此文内容。

2. 账务系统在支付平台中的定位

账务系统主要承担账户管理、记账、清结算及会计相关服务。

3. 一些基本的概念

账务系统的一些基本概念，包括账户分类、复式记账法、会计科目编制、会计分录、记账方向等说明，请参考前一篇：《图解支付账务系统入门》。

4. 信息流与资金流全生命周期

支付系统的本质，就是准确无误地把钱从一个地方搬到另一个地方。就这涉及到所谓的信息流和资金流，资金流还可以细分虚拟资金流和实体资金流。

因为大家的钱一定要通过银行才能变现，所以大家在支付平台（比如支付宝或微信）账户看到的余额变动，就是虚拟资金流。真实的资金在银行体系流转，就是所谓实体资金流。不过大部分情况下，也不用刻意去区分虚拟资金流和实体资金流。

此外，像收单核心、支付引擎、渠道网关等处理的就是信息流，而账务系统处理的就是资金流。所以要想理解账务系统，一定要先理解资金流。

下面分别以最常见的支付来展开说明信息流和资金流。钱包账户余额充值和余额支付会有一些差别，但原理差不多，在此处略过。

4.1. 支付与结算交互图极简版

在支付流程中，就是商户委托收单机构（支付平台）把用户的钱收回来，然后再把钱结算给商家。

下面以典型通过外部渠道的卡支付为例说明。

说明：

用户的钱最终会走到商户的收款银行账户。真实情况下用户的支付的钱会分成多份，包括通道收的费用，支付平台收的手续费，税费，营销分润，商户结算款等。通道费用还可以继续细分为发卡行手续费，收单行手续费，清算机构手续费等。

跨行一般都需要通过清算机构，这里为简化也没有画出来。

支付平台内部的资金流在详细版中给出。

4.2. 支付记账详细版

说明：

图中只画了正常场景，像明细对账出现差异（长短款）、账单对不平（渠道少打款或多打款）等场景没有画出来。

4.3. 商户结算记账详细版

说明：

上述是商户结算到卡场景。

各公司的内部户编制可能有所不同。

5. 账务系统核心诉求

在第3节中提到，账务系统负责支付平台的资金流管理。根据上述图继续拆解，可以得出账务系统的核心诉求如下：

账户管理：对私、对公账户的开户、销户等。

余额管理：对私、对公账户的余额管理。

记账处理：清楚知道每笔钱的来龙去脉。

清结算与对账：把需要结算给商户的钱算清楚，把渠道和支付平台的账算清楚。

银行头寸管理与流动性：支付平台在各备付金银行开立的头寸，以及头寸间流动性管理。

内部会计报表与外部监管报表：根据会计准则出具各种要求的报表。

6. 账务系统产品架构图

说明：

账务主要负责账户的管理，以及记账服务。比如开、销户，余额操作。

清结算主要负责对商户的清分（算出应该给商户多少钱），清偿（实际打款给商户），对账以及差错处理。

会计中心主要负责科目、分录、日切、报表等。

补充：

各公司对账务系统子模块的拆分可能有差异，比如有些公司把账户和记账服务单独拆成两个模块，或者把对账从清结算模块中拆出成单独的一个对账核心。这些拆分不影响本质的东西。

何时拆何时合？公司业务规模小，就合起来，反正是一批人搞定代码实现。公司交易量大，业务复杂，招的研发多，就拆，每个小团队负责一个或几个核心模块。

7. 账务系统系统架构图

说明：

各能力基本与产品架构图对应，但会多一些技术上的设计，比如实时记账和缓冲记账，业务上并不关心。

上面只画出了核心模块的核心能力，实际实现时需要做删减。

上面的业务系统只画了支付链路的示例，实际业务可能还有充、转、提等资金产品服务。

记账服务与会计中心简要关系

为便于理解，这里做了极简化处理。

记账服务负责记账，主要关注账户余额变动等；会计中心负责会计核算，主要关注点在于会计分录、科目汇总、会计报表等。实际情况会比这个复杂。

8. 核心设计

8.1. 整体模型

说明：

科目有多级科目，所以有个自关联。

账户分为客户账户和内部账户，二者的结构有一些小的区别，比如内部账户一般不会被冻结，但是客户账户可以被冻结。

这是大的关系图。属性在下面会讲到。

没有加入清结算和对账的模型，不然画出来比较乱。

8.2. 账务核心

8.2.1. 账务模型

说明：

因为客户账户和内部户账户有区别，所以拆成两个模型更清晰。

只列出了最核心的几个字段，其它字段根据业务诉求增加。

8.2.2. 账户分类

在账务系统中，通常包含以下几种账户类型：

客户账户：对客可见。包括：对私的个人客户账户，对公的商户账户。

内部账户：对客不可见。包括：头寸、手续费收入、过渡户（也称中间户）等。

8.2.3. 记账方向

说明：

账户类型与借贷方向，相同为加，相异为减，也就是所谓的：DD+，DC-，CC+，CD-。

示例：用户提现100元，记账如下：

DR：用户余额（负债类账户）100

CR：提现过渡户（负债类账户）100

8.2.4. 实时记账与缓冲记账

一般来说，客户账户的记账需要是实时的，比如用户充值、提现，商家提现，用户退款等。

这些账户如果不做实时记账，一来有损用户体验，二来有资损风险。比如用户充值100块，如果延时不到账，用户可能会投诉。如果提现不实时记账，用户有可能重复提现成功。如果退款不实时记账，有可能在退款场景下被透支。

假设记账需要几十毫秒（数据库性能决定的），一个账户最高也就只支持30多TPS的记账请求，对于一些高并发的账户（也称为热点账户）一定是性能不足的。这个时间可以使用缓冲记账，以提高性能。开通缓冲记账的，通常是内部账户或允许商户透支的流出场景。

缓冲记账通常就是先记录流水，然后起定时任务去捞取流水，汇总后进行记账。前提是一定要做好资损防控。

除了缓冲记账外，还有拆分账户的方式来解决热点账户问题。

8.3. 会计中心模型

说明：

只列出了最核心的几个字段，其它字段根据业务诉求增加。

8.3.1. 会计科目与会计分录

会计科目就是把会计要素进行分类，比如资产、负债等。通常都会有多级分类。

会计科目示例：

说明：

一般支付系统使用三级科目就已经足够。部分特别复杂的系统，可能会用到五级科目。

为便于理解，上面的示例做了很大的精简，各公司内部对科目的编制差异可能会比较大。

下面是一个典型的支付系统会计科目的示例。

8.3.2. 记账方案

有了账户和会计科目，发生一笔交易时，如何让系统自动去记账？这个是记账方案做的事。其中一个解决方案就是给不同的交易场景制定不同的交易码，通过交易码来驱动记账。

下面是一个典型的支付系统的记账方案示例。

8.3.3. 会计日与日切

会计日，也称为会计结算日或账务结算日，是支付平台在会计周期中进行账务处理和结算的特定日期。比如在分布式环境下，各机器可能存在时间差，一笔交易在零点时有可能跨天处理，如何判断一笔交易归属于哪天，就依据会计日来计算。

所谓日切，简单理解就是切换到下一个会计日。

主要做的工作：

借贷试算平衡。

父子科目试算平衡。

总账试算平衡。

日、月、季度、年汇总。

会计日变更。

日切试算平衡核心逻辑：

借方发生额 = 贷方发生额

借方余额 = 贷方余额

期末余额 = 期初发生额 + 发生额

父科目累积额 = 子科目累积额

8.4. 清结算核心模型

8.4.1. 极简商户清结算流程

图中各方关系画得很清楚，不需要再做过多说明。

8.4.2. 渠道对账模型

说明：

只列出了最核心的几个字段，其它字段根据业务诉求增加。

我方流水和渠道流水单号、币种、金额、状态都对上，就是对平。双方如果有缺少，就会有长短款。

流水对账完成后，形成我方账单，再和银行账单对账，因为银行可能多次打款，所以二者是多对多的关系。

8.4.3. 对账差异处理

对账一般有几种结果：

对平：双方交易类型、单号、状态、币种、金额都是一致的。

长款：我方多钱。支付长款：支付90块，渠道清算100块，或我方失败，渠道成功。退款长款：退款100块，渠道清算90块。充值长款、提现长款类比。

短款：我方少钱。支付短款：支付00块，渠道清算90块。退款长款：退款90块，渠道清算100块。充值短款、提现短款类比。

因为我方和渠道之间有一定的时间差，所以长短款在T+1对账对不上时，往往先进入存疑清单里面，第T+2对账还是对不上，才会进入差异处理。

8.4.4. 渠道三层对账体系

第一层是信息流对账。我方流水和银行清算文件的流水逐一核对。可能会存在长短款情况。

第二层是账单对账。就是把我方流水汇总生成我方账单，然后把银行流水汇总生成银行账单，进行对账。可能会存在银行账单和我方账单不一致的情况，比如共支付100万，渠道分2次打款，一笔98万，一笔2万。

第三层是账实对账。就是我方内部记录的银行头寸和银行真实的余额是否一致。可能存在我方记录的头寸是220万，但是银行实际余额只有200万的情况。

9. 内部系统实时与离线对账

前面的对账主要是和银行渠道对账，除了这个之外，一般的支付平台还会有内部系统之间的两两核对，这种核对主要是信息流层面的核对，主要核对状态、金额的一致性。

再细分，还可以拆成离线核对和实时核对。离线核对一般就是把生产数据库的数据定时清洗到离线库（一般还可以分为天表和小时表）。实时核对一般就是监听数据库的binlog，当数据有变动时，延时几秒后请求双方系统的查询接口，查到数据后进行核对。

10. 拓展阅读

账务系统除了底层知识比较通用外，还有很多内容是和实际业务场景挂钩的，推荐几篇供大家拓展阅读，互相补充。

看完后，就会发现，大家语言描述千差万别，但本质就是会计原理、银行核心那一套。场景复杂的，比如跨境，无外乎多几个主体，加几个主体之间的关系而已。（说得轻巧，实现还是相当有难度的）

《解密：站在资金的视角看支付（上）》、《站在资金的视角看支付（下）（跨境篇）》（来源公众号：支付进阶之路）

《一文搞懂“支付·清结算·账务”全局》（来源公众号：陈天宇宙）

《最后的黑盒，账务核心》（来源公众号：刚哥白话）

《跨境支付中的清结算体系解析》（来源公众号：墨玉跨境学堂）

《账务系统设计基础》，《支付清结算之账户和账务处理》（来源公众号：凤凰牌老熊，从2024年往回看，账务系统的核心设计仍然没有太大的变化）

11. 结束语

账务系统负责为支付平台处理资金流，是支付平台最核心的子系统之一。相关会计报表是公司经营决策的依据，也是合规申报相关报表的基础。

理解账务系统的核心设计概念，才能让我们构建出完整的支付系统设计与实现的理论基础。

本文从研发工程师的视角，介绍了账务系统核心的设计思路，希望能为大家在学习账务系统相关知识时能提供一些有益的参考。如果还是看不懂，建议先去买本会计入门的书读读，基本就能懂了。

这是《图解支付系统设计与实现》专栏系列文章中的第（36）篇。

深耕境内/跨境支付架构设计十余年，欢迎关注并星标公众号“隐墨星辰”，和我一起深入解码支付系统的方方面面。