把账算清楚，数要记明白，钱需结正确，款应打到户，本文详聊清结算用户支付完成后，平台需履行相应义务，即进行履约。履约完毕后，则需进行清算，并执行最终的结算。清结算体系与支付体系并行，构成了支付领域中的另一个庞大体系。一笔支付完成后，最终需要进行清算。业务通常涉及多个参与者或利益方，事务处理完毕后，清算系统负责算清楚各方的利益关系，并完成利益分配。1.1.清算系统概述
《支付清算组织管理办法》规定：支付清算是指支付指令的交换与计算。支付指令是参与者以纸质、磁介质或电子形式发出的，用于办理确定金额的资金转账的命令。支付指令的交换，是指提供专用的传输路径，以便接收、清分和发送支付指令；而支付指令的计算，则涉及对指令的汇总和轧差。参与者是指接受支付清算组织章程约束，能够发送和接收支付指令的金融机构及其他机构。支付清算包括清分和资金划拨两个关键环节。清分是指对交易日志中记录的成功交易，逐笔计算交易本金及交易费用（如手续费、分润等），然后按清算对象汇总轧差，形成应收或应付金额。简而言之，就是明确各方应收应付的金额。资金划拨则是通过特定的渠道和方式，完成应收应付资金的转移。简言之，就是确定如何通过渠道收回应收款、支付应付款。由此可见，清算的核心在于清分过程，即准确计算各方应收应付的金额。承载这一过程的系统被称为清算系统。清算系统位于交易、支付等业务之后，这些业务系统可能基于其自身业务需求请求清算，例如，基于订单清算商家结算款，基于交易计算卡、券营销成本，基于支付计算通道成本等。1.2.清算业务架构
清算系统业务架构主要由以下几部分组成：接入层、清分处理子系统、算账服务、计费子系统以及账务前置模块。这些部分之间的架构关系如图1所示。
接入层接收包括订单系统、交易系统、支付系统等系统的清算请求。关系模型主要负责构建各参与者之间的关联关系。算账服务与计费子系统则用于计算各方的应收和应付金额。账务前置系统则主要为后续的入账工作做好准备。1.3.对象关系模型
对象关系模型是指系统计算出的应收应付款项所属的对象，以及这些对象之间的关联关系。以外卖平台的一个订单为例，它可能涉及多个利益相关方：外卖平台需要抽取佣金，提供餐食的商家要收取餐费，配送骑士要收取配送费，还有骑士的保险费等。这些费用需要通过订单分账来确定。此外，外卖平台还可能涉及多个渠道或合伙人，需要给他们分配相应的利润。一个公司的不同业务可能对应不同的对象模型。比如，有的商家是单一经营，有的商家有合伙人，有的商家有渠道商，还有的商家有服务商。因此，每类订单可能涉及不同的关系模型，在计算时，需要考虑的维度也会有所不同。常见的几种对象关系模型如图2所示。
在商家注册或入驻时，关系模型模块会为其生成相应的对象模型及对象关系。例如，如果你通过好友的邀请注册了一个网站，那么好友就成了你的合伙人，此时你的对象模型就是“合伙人-用户”模型。当你产生消费时，系统会计算你好友作为合伙人的分成。1.4.计费规则子系统
计费子系统的核心职责是维护和管理计费规则。当接收到算账服务的请求时，它会返回相应的计费模式及参数值。例如，在单商家模型下，若需要计算平台的信息服务费，则可通过基础参数请求计费子系统，获取信息服务费的计费模式（如按比例、固定金额、按单笔阶梯或累计阶梯等）。获取到计费规则后，即可计算出信息服务费的具体数值。因此，计费子系统的核心环节在于，根据业务特点抽象出合理的计费规则模型。规则的匹配模式决定了如何从规则池中找到适用的规则。其中，条件法是一种常用方法，即通过一组参数去匹配相应的规则。为此，需要为不同的计费类型设置不同的匹配条件组，如通过“类目+城市”的组合来查找规则。这样，在匹配条件中可以设置更加灵活的条件组。以图3所示的规则设置示例为例，该规则主要用于计算合伙人的分成。其中，分成模式包括固定金额、固定比例、按单笔阶梯、按累计阶梯递减等多种方式。当选择“金额递减”作为分成模式时，需要配置相应的参数。
基于上面的配置器，可以配置出非常多的规则，那么基于不同的费用的配置模板我们就可以配置出无穷个计费的规则了，如图4所示，是由上述规则配置器配置出来的规则列表。
清算请求到来后，不同类型的清算任务其计算方式和模式各不相同，因此计算结果也会有所差异。所以，我们需要设计一个抽象的算账模型。首先，根据清算类型确定相应的清算模板，通过清算模板明确需要计算哪些费用以及执行哪些任务，然后逐一计算每项费用。关于分润和分账，基于不同的对象模型，可以明确哪些情况下需要计算分润，哪些情况下需要计算分账。如图5所示，可以看出分润分配的是手续费，而分账则是分配的交易款项。图中“算法及计算顺序”列中的数字是计算执行的顺序，数字后是计算公式。
系统根据业务类型，对联机交易数据明细进行了登记，具体如表1所示。该表包含了协议支付和付款的交易记录，每笔交易明细都详细记录了收付双方的信息以及交易金额。表1 联机交易明细
清分处理是将表1中的交易明细，按照“机构+业务类型+借贷方向”的预设维度进行分组，最终得到如表2所示的清分结果。这一结果将作为执行结算的依据。公司需要给员工结算工资，平台需定期为商家结算收入，收单机构则要为商户结算收款。这些都是典型的结算场景。2.1.结算业务概述
结算是依据清分结果来完成资金最终实际转移的环节。企业类型多样，如普通交易平台、四方支付机构、三方支付机构等，它们都涉及结算业务。尽管结算模式可能存在差异，但其基本原理和职能是相似的。2.1.1.不同类型企业的结算业务
交易平台，如滴滴、货拉拉、京东商城等，上有众多司机、商家等服务或商品提供者。交易完成后，平台会依据协议约定扣除一定费用，然后将剩余的服务款项结算给商家。与支付机构通常采用的T+1、D+1结算周期不同，交易平台的结算周期更加多样化。例如，外卖骑手可能3天一结或7天一结，家政阿姨则每月一结，有的电商平台甚至60天一结。因此，在设计交易平台的结算系统时，“结算周期”是一个需要重点考虑的因素。三方支付机构作为收单机构，负责帮助商户收款，并依据与商户入网时签订的结算协议，将款项结算给商户。三方支付机构的结算业务涵盖了向商户的代收款结算、向分账方的分账结算、向渠道商的分润结算，以及向渠道支付的通道成本结算等。无论结算对象是谁，结算处理都是基于交易记录和清分结果来进行的。2.1.2.账户在结算业务中的作用
账务核心能够为结算体系提供用于结算的账户，如“商户待结算户”、“商户结算账户”等，具体如图6所示。
图6 账户在结算业务中的作用
在整个账务体系中，会发现一些过渡账户，如商户待结算户、清算往来户等，这些账户的作用和含义常常让人感到困惑。待结算户实际上是用来管理“结算在途”资金的，即那些已经交易成功但尚未进行结算处理的资金。这部分资金可以通过交易记录统计、账户余额冻结等方式来体现，因此，并不一定非要设立一个专门的商户待结算账户，有多种手段可以管理结算在途资金。清算过渡户则是用于记录平台通过支付渠道完成的收款情况，即收款资金在途或清算在途。这时，可以设立一个“清算往来户”，用于登记平台需要向支付渠道追讨的资金。具体如图7所示。
2.2.三方结算模式解析
三方支付机构常见的结算产品如图8所示。该图展示了三方支付机构提供的各类结算服务产品。
T1结算：指工作日结算方式，即当天发生的交易，在下一个工作日进行结算；
D1结算：指自然日结算方式，当天发生的交易，在次日进行结算，全年365天均可结算；
D0结算：也是自然日结算方式，当天发生的交易，当天即可结算，同样全年365天均可进行；
H0结算：即整点结算方式，可在9:00、10:00、11:00等整点时间进行结算；
S0逐笔结算：指交易完成后即可立即结算，支持自动逐笔结算或商户按订单号手动逐笔发起结算。
- TD结算：为跨日结算方式，特别适用于酒吧、KTV等0点前后交易集中的商户。
2.2.1.常见结算模式
在结算体系的实现上，常见的有三种模式：中间户模式、冻结模式和账单模式。其中，前两种模式也被称为余额模式。即设置一个中间账户“商户待结算账户”，用于管理待结算资金的登记。交易成功后，资金计入“商户待结算账户”。在结算处理时，若采用到户结算方式，则将资金从商户待结算账户转入商户结算账户；若采用到卡结算方式，则无需对商户待结算账户进行处理。在打款扣账环节，结算到卡模式下会扣减商户待结算账户的余额；结算到户模式下，打款时会扣减商户结算账户的余额。具体流程如图9所示。
在“商户结算户”下设置“冻结余额”和“可用余额”两个余额。结算处理时，会将冻结余额进行解冻，并转入商户的可用余额中。在打款扣账时，则会扣减商户的可用余额。具体流程如图10所示。
不设置专门的结算户，为了保障资金安全，可以设立“商户收款账户”用于余额校验。在该模式下，结算处理是根据清分明细直接汇总生成结算单，然后依据结算单进行打款处理。具体流程如图11所示。
从上面的三个结算模式可以看出，是否需要设置“待结算账户”这个中间账户，取决于我们选择的结算模式。很明显，在冻结模式和账单模式下，是不需要待结算账户的。此外，在上述三种模式中，还有两个重要概念需要介绍：一是结算方向，二是结算触发方式。结算方向分为结算到卡和结算到户两种。结算到卡，即直接将结算款项支付到商家签约的结算银行卡中；结算到户，则是将结算款项先入账到商家在平台开通的结算账户中，后续商家可以自主提现。结算触发方式则分为自动结算和自助结算两种。自动结算是指系统按照结算协议，在约定时间自动将款项支付至商户绑定的结算账户；而自助结算则需要商户自主在服务平台上完成可结算周期内的款项结算申请。2.2.2.结算系统关键指标
可以从两个角度来审视结算系统。一是站在公司的角度，一个好的结算系统应该具备高准确率、确保资金安全、能让用户满意且投诉率低的特点。二是站在用户的角度，他们期望结算系统能支持多家银行、服务优质、到账迅速且成本低廉。常用的结算系统关键指标如图12所示。
2.3.结算的架构
对于不同的结算产品，需要依靠定时任务管理来推动结算流程的进行。商户后台是商家自主发起结算、查询结算信息、变更相关信息的操作平台；运营后台则是公司内部运营人员的操作台。账务系统为结算系统提供必要的结算数据，接收打款申请，并反馈出款通知。垫资系统负责处理D1、D0、S0等结算请求中的垫资申请。计费系统则负责计算结算时商家需要支付的费用。商家系统则供商家查询与结算相关的各类信息。结算系统的产品架构如图13所示。结算系统的功能主要包括：结算请求管理、结算记录管理、结算明细管理、结算信息管理以及打款管理等。
2.4.结算业务流程
整个结算流程从结算请求数据的输入开始，经过一系列结算处理后，将结果输送给打款模块，最终完成付款。该结算流程可以分为数据准备、结算处理、打款处理及打款结果更新等环节。结算业务的主流程如图14所示。
数据准备环节是指账务系统将符合结算条件的交易数据生成文件，并将该文件推送给结算系统。结算系统随后对接收到的文件进行解析处理。该环节的业务流程如图15所示。
结算处理环节的主要任务是处理已接收的商家交易数据，将符合结算条件的数据进行加工汇总，生成相应的结算单据。不同的结算产品有其独特的结算处理逻辑，以下以T1、D1和自主结算为例进行说明。T1是最常规的结算模式，其结算周期与上游渠道的清算周期保持一致，无需垫资。该模式正常结算上一个工作日的所有成功交易，处理流程如图16所示。
首先获取工作日历，然后筛选出满足结算条件的商家，即那些已开通自动结算（可在商户结算信息管理列表中查看）、已开通T1结算产品，且当前状态为可结算的商家。接下来，按产品码分产品汇总结算金额，汇总的数据为截止日期之前所有未结算的订单，且需按照出入账分类进行汇总。在调用计费系统计算结算手续费时，需传递的参数包括商户编码、最低收费限额、结算产品类型、是否为工作日以及结算金额等。与T1结算产品相似，但不存在周一一次性结算3天的情况。相比之下，D1结算多了一个垫资的场景。如果签约的上游渠道采用T1结算方式，那么机构在D1结算模式下，周六、周日的结算处理需要申请垫资，因为此时上游渠道尚未进行结算。D1结算的处理流程如图17所示。
首先获取工作日历，然后筛选出满足结算条件的商家，即那些已开通自动结算（可在商户结算信息管理列表中查看）、已开通D1结算产品，且当前状态为可结算的商家。接下来，按产品码对结算金额进行汇总，汇总的数据为截止日期之前所有未结算的订单，且需按照出入账分类进行细分。在调用计费系统计算结算手续费时，需传递的参数包括商户编码、最低收费限额、结算产品类型、是否为工作日以及结算金额等。与T1结算模式不同的是，D1结算在处理时还需判断当前是否为工作日。若非工作日，则需申请垫资。当垫资申请失败时，结算将无法进行，并会生成结算失败记录，失败原因为垫资额度不足。自助结算处理是指商户自行在商户后台发起结算申请，申请方式可以按照日期、产品或余额等进行。自主结算的处理流程如图18所示。
首先判断是否为D0结算模式。若是D0结算，则查询商户当天0点至当前时间内的所有未结算订单，按产品生成日订单明细，并将结算状态标记为未结算。需注意的是，D0结算仅支持自助结算方式，通常不会自动进行。若非D0结算，则按产品码对金额进行汇总，统计截止日期之前所有未结算的订单，并按照出入账分类对结算金额进行汇总。接下来，根据结算产品（如D1、T1等）判断当前是否为工作日，以及是否需要申请垫资。后续的处理流程与D1、T1结算模式的处理流程相同。结算处理完成后，会生成结算记录（即结算单）。随后，系统需处理并生成打款申请单。接着，请求账务系统划扣商户收款账户余额。若扣账失败，需判断是否存在逆向交易：若不存在，则流程结束；若存在，则更新结算记录和打款金额。扣账成功后，需判断打款方式是到卡还是到户：若是到卡，则将打款申请置为待提交渠道；若是到户，则直接标记为成功。整个流程如图19所示。
图19 打款处理流程
如图20所示，系统架构包含账务中心、结算中心、任务中心和计费中心等几个关键组成部分。整个处理流程涵盖了订单明细汇总、结算处理、打款处理、状态更新、付款失败处理以及付款失败重试处理等主要环节。
这篇文章有点干，如果一次性消化不来的话，可以先关注大佬公众号，下次继续~以三方支付机构场景为例，全面解析清结算的实现过程，包括各环节数据的生成、各类账户的设置，以及不同场景下的账务处理方法。支付机构的主要业务是协助交易平台进行交易款的代收。具体而言，支付机构先从消费者的发卡行收取交易资金，然后再将这些资金结算给交易平台。对于交易平台而言，其帮助店家销售商品，并通过支付机构收款。交易平台收到款项后，再结算给自己的商家。这构成了两个典型的清结算场景：一是支付机构的清结算，二是交易平台在信息层面完成的“类清结算”业务（尽管交易平台本身不具备清结算资质）。上述业务模式如图21所示。
要全面了解支付机构清结算的业务环节，才能彻底弄清楚如何着手搭建清结算体系，以及这一体系涉及哪些系统、这些系统之间有何关联。将上述内容浓缩抽象后，清结算涉及的资金处理业务流程如图22所示。所谓清结算，就是从渠道获取全部款项，并准确无误地完成对商户的结算。从上图可以看出，清结算全局主要涉及以下几个关键部分：四个环节：支付交易环节、渠道清算环节、渠道结算环节、商户结算环节。这四大环节构成了“清结算”业务的主链路。
四段数据：账务数据、交易数据、清算数据、渠道账单数据。这四段数据覆盖了清结算业务的主要数据范围。
三套对账：交易对账、资金对账、账务对账。这三套对账机制确保了四段数据的一致性。
- 三套差错：通过对三组数据的核对，会形成三组差异数据，这些差异数据构成了各类在途账务。差错处理就是解决这些在途账务，从而确保全业务链路的清结算业务顺利完成。
3.1.全局数据
无论是交易、支付，还是对账、渠道清算、商户结算，这些过程都离不开各类数据的支持。可以将全链路中的最原始数据归纳为四类，即：账务数据、支付数据、清算数据和结算数据。为了便于描述，分别将它们定义为1段数据、2段数据、3段数据和4段数据，具体如表3所示。表3 数据分段
数据分段后，通过数据编号就能清晰地了解到该数据的全量信息，包括它来自哪个系统，是哪项支付业务产生的。在后续的凭证规则设置中，可以根据数据段来制定凭证生成规则，明确哪个数据段的数据应该生成哪种凭证，以及需要操作哪些账户。例如，编号为2001的支付数据，就需要操作清算收款往来账户和商户待结算账户，具体如图23所示。
图23 2001段数据的账务处理逻辑
将所有数据段以及核对差异产生的差错处理数据的账务处理规则进行了梳理，并绘制出了如图24所示的各段数据源与账务核心的账务处理关系图。
这么多数据，它们是如何从业务系统流向账务系统的呢？系统之间的数据流转关系如图25所示。数据从各业务系统产生后，经过对账系统、转换中心、计费中心、财务处理中心到达最后的会计核心。
对账中心首先从渠道获取清算文件，解析出清算数据，并从交易平台获取交易数据，用于进行交易对账。接着，交易中心将相关数据推送至账务核心进行记账。同时，对账中心的清算数据也会被推送至账务系统，用于清算过渡类账户的账务处理。交易对账数据和账务数据会按照各段数据的格式要求，被转换成文件数据，然后推送至成本计费中心。在这里，通道成本会得到计算，并在清算数据上绑定结算账户、结算日期等信息。随后，这些数据被推送至财务处理中心，准备进行资金对账。资金对账过程中产生的长短款数据，以及长短款的核销数据，会形成新的数据段。这些数据会被推送至会计核心，生成长短款等挂账数据。最后，备付金账套中的手续费收入和通道成本会被结转给财务账套，进行内部资金的核算。至此，整个数据从业务产生到核算完成，实现了全链条的流转。3.2.科目与账户设置
清结算业务紧密依赖于账务和账户体系，因此，我们需要设立一套完善的账户，以为支付交易和清结算等业务提供坚实的账务支持。所设置的账户及其具体用途，详见表4。表4 清结算账户设置
往来账户、已核对应收银行账户和银行存款账户。其中，共同类账户进一步细分为收款类账户和付款类账户。这样的账户设置共同支撑起了基于支付交易的向内结算和向外清算的支付业务框架，具体如图26所示。
有了上述会计科目后，为了清晰理解账务处理，我们需要明确账务处理的要素和基础原理。账务处理的要素涉及进行账务处理时需关注的几个关键维度，主要包括以下四个方面：业务类型、记账时机、记账数据以及记账规则。具体来说：业务类型：指需要记账的具体业务类型，常见的业务种类包括收款/退款、打款/打款退回、差错处理、长短款及核销、客户账务调整、结算结转财务等。
记账时机：这些时机通常与业务操作的节点相对应，如支付成功、打款成功、退款成功、渠道清算对账成功、资金对账成功、账务记账成功等。
记账数据：指用于记账的具体数据，如支付数据、清算数据、结算数据、差错数据、长短款核销数据等。
- 记账规则：主要包括借贷方向以及涉及到的具体账户，以确保账务处理的准确性和规范性。
账务处理的基础原理是采用借贷记账法，根据业务数据对相应账户进行操作，如图26所示。这些数据的借贷符号也在图中清晰标示。此外，特别需要关注的是差错类的记账处理，如交易类差错、资金处理类差错以及客户调账差错等。3.3.三大在途
过渡账户的借方和贷方分别基于两份相关的数据源进行记账，因此其余额体现了这两份数据源之间的差异。当过渡账户存在余额时，意味着存在在途，主要包括客户在途、支付在途和资金在途三种情况。在途可以理解为各类挂账，而各类差错处理的记账过程就是消除这些挂账的过程。3.3.1. 支付在途
渠道待清算往来账户的余额体现了支付在途的情况。清算完成后，该账户的余额应为零。若余额不为零，则说明平台与渠道之间的清算数据存在差异，具体如图27所示。
从原理上讲，该账户的余额反映了平台支付记录与渠道清算记录之间的差额，即期末余额代表了“支付在途”的金额。在一个清算周期内，该账户的余额可能存在三种情况：当余额不为零时，意味着存在平台单边或渠道单边的情况。单边数据会在对账中心核对出来，并可以通过相应的差错处理来消除差异。例如，如果是渠道单边，可以选择进行平台补单、银行退款或平台确认收入等操作。这些差错处理操作会涉及该账户，从而抹平账户余额，完成最终的清算。3.3.2. 资金在途
已核对应收银行的账户余额用于反映长短款数据。资金对账完成后，该科目的余额应为零。若余额不为零，则说明存在长短款情况，具体如图28所示。若余额在借方，则表示存在短款，即银行少结了款项；若余额在贷方，则表示存在长款，即银行多结了款项。
3.3.3 客户在途
待结算商户账户余额表示尚有款项未完全结算。若余额在借方，则说明已多结算给商户；若余额在贷方，则说明尚少结算给商户。在少结的情况下，可以通过调增客户账户余额来进行补入账处理；在多结的情况下，则可以调减客户账户余额以进行平账。3.4.账务处理规则及示例
首先，我们来看全局核算如何进行账务处理。以收款业务为例，该业务的账务处理涉及四个环节和三类差错。具体环节包括：支付交易环节、渠道清算核算环节、商户结算环节和渠道结算环节。三类差错则包括：客户差错、交易差错和资金差错。每个环节都有相应的记账源数据，并依据相应的记账规则对相关账户进行操作。具体环节说明和记账规则详见表5。表5 清结算账务处理环节
为了加深对上述各环节账务处理的理解，我们通过一个实际的收款例子来进行说明。案例：平台收到两笔款项，每笔均为10元。渠道采用T+1的结算方式，同样，平台也给商户采用T+1的结算方式。以下是各环节的数据情况及相应的账务处理。 3.4.1. 支付交易环节
用户进行了两笔支付，每笔金额均为10元。其中一笔支付成功，另一笔仍在处理中。支付核心系统已生成相应的支付数据，具体数据情况如表6所示。交易驱动账务系统进行记账处理，以支付数据作为记账依据。具体记账操作为：借记“渠道清算往来”账户，贷记“待结算商户”账户，如图29所示。
3.4.2. 渠道清算环节
对账中心获取到渠道清算文件后，与平台记录进行了仔细核对。核对结果表明，渠道已成功清算了两笔交易。核对结果的详情见表7，其中发现了一笔渠道单边的情况。表7 交易对账结果
清算文件中的数据作为渠道清算的记账依据，记账操作为：借记“已核对应收银行”账户，贷记“渠道清算往来”账户。具体记账情况如图30所示。清算完成后，可以看出“渠道清算往来-收款”账户存在贷方余额，这是由交易对账中出现的渠道单边情况所导致的。
图30 渠道清算账务处理
3.4.3. 交易差错处理
经排查发现，平台的支付系统状态更新出现异常。对此，对账中心进行了“平台补单”的差错处理，将原本处于处理中的支付状态更新为成功状态，具体处理结果如表8所示。表8 交易对账差错处理
补单成功的支付记录将触发账务系统再次进行记账处理。由于平台补单的数据属于平台的支付记录范畴，因此其账务处理规则与平台正常支付记录的账务处理规则保持一致，具体记账流程如图31所示。
至此，所有账户的记账情况如图32所示。可以看出，此时“待结算商户”账户余额为20元，与渠道清算已成功的20元相对应。而“商户结算户”和“银行存款户”目前尚无余额。
3.4.4. 商户结算环节
假设最初那一笔支付成功的交易未能完成账务记账，而次日通过对账补单成功的交易则完成了客户记账。因此，只有补单成功的交易完成了向商户的结算，具体结算情况如表9所示。表9 账务记录
基于补单成功的交易，账务系统完成了记账处理。在T+1日执行结算后，成功完成了向商户的款项结算，具体结算流程如图33所示。可以看到，“待结算商户-收款”账户存在贷方余额，这表示应结算给商户的在途资金。该余额的存在是因为有部分交易尚未完成入账处理。
3.4.5. 客户账调账、交易补入账
系统进行了补入账操作，将未入账的交易记录补充录入，具体记录如表10所示，且这些补入记录的结算状态为“未结算”。表10 账务记录
对未结算的账务明细重新执行了结算操作，完成了商户的结算入账。至此，“待结算商户”余额归零，商户在途资金处理完毕。同时，也成功完成了向商户的款项结算，具体结算情况如图34所示。
3.4.6. 渠道结算环节
资金对账模块在获取到银行结算账单后，进行了资金对账处理。假设渠道结算文件中仅记录了一笔交易，因此在资金对账过程中出现了短款情况，具体短款详情如表11所示。
资金对账结果显示存在10元的短款，系统将自动生成长短款记录，具体记录如表12所示。根据渠道结算单进行账务记账，实收金额为10元，具体记账情况如图35所示。可以看出渠道资金对账后，已核对的应收银行款项存在借方余额，即存在短款挂账情况。这与表12中的短款记录是一致的。因此，过渡户科目余额的反映与对账结果的含义是相同的。
3.4.7. 长短款核销
经人工排查确认，收单账户的资金已经成功入账，短款原因是结算文件数据丢失。因此，对短款进行了“银行补入账”的核销处理，具体数据如表13所示。表13 长短款核销记录
针对该短款，已执行核销凭证的入账处理，具体记账情况如图36所示。
至此，收款清结算的全部环节账务处理已完成，涉及的所有账户记账情况如图37所示。
图37 全环节账户记账情况可以看出，通过这5组账户的借贷账务处理，完成了从交易到内外部清结算的全链路核算，并最终完成了记账。中间过渡户的余额为零，代表着渠道清算往来核算及商户结算核算均已完成。该账户体系能够高效、准确地实现清结算业务的全局处理。如果你也正好是支付领域的，或者刚好对支付领域感兴趣，那我推荐你赶紧关注大佬的公众号，里面全是满满的干货！
