什么是对账
传统的对账就是核对账目，是指在会计核算中，为保证账簿记录正确可靠，对账簿中的有关数据进行检查和核对的工作。在银行或者第三方支付中，对账其实是对一定周期内的交易进行双方确认的过程，一般都是在第二天银行或者第三方支付公司对前一日交易进行清分，生成对账单供平台商户下载，并将应结算款结算给平台商户。在往下一层，在互联网金融行业或者电商行业中，对账其实就是确认在固定周期内和支付提供方（银行和第反方支付）的交易、资金的正确性，保证双方的交易、资金一致正确。
广义的对账，所有跨应用的数据交互，理论上都应该进行对账。所以对账也可以分为信息流对账，资金流对账。信息流对账也一般用在自己内部系统的对账，比如支付系统的支付数据和业务系统的业务数据进行对账，保证资金交易和业务交易的一致性。资金流对账也就是支付系统和银行或者第三方支付系统之间的资金交易对账。
对账方式
单向对账：一般拿第三方支付机构或银行流水，与自己系统进行对账，防止出现掉单问题；
实例，渠道对账：
双向对账：两个应用间的流水进行双向核对，如订单与财务系统，既要保证财务系统支付成功的记录，订单系统也是成功的；也要确保订单系统记录成功的记录，财务系统也成功。
我们一般采用双向对账的方式进行对账
单边账、双边账的区别：
单边账、双边账的术语最初应该来源于POS收单的差错处理，后面延续到互联网支付、移动支付等领域，但似乎并没有严格的术语定义。个人是这样理解的：对于POS收单、在线支付等支付交易，一般都涉及发卡行、收单行、收单机构（例如第三方支付）、清算中心（例如银联）、商户等几个角色，对于发卡行、收单行、第三方支付、银联等平台服务提供商，对于每一笔交易，都会在各自的账务系统进行记账，然后按照约定的结算周期（例如T+1）方式与上下游对账。既然交易参与方都会记账，就存在几方账务记录不匹配的情况，因此会出现所谓的单边账、双边账。对一笔POS交易而言，记账可能存在如下几种情况（简单起见，这里只涉及发卡行、收单行，不涉及银联清算中心、第三方支付）：
情况1：发卡行扣款（入账），但收单行未入账
情况2：发卡行扣款（入账），收单行入账
情况3：发卡行未扣款，收单行入账
情况4：发卡行未扣款，收单行未入账对情况1、情况3都可以称之为单边账（只有单边入账），情况2可以称之为双边账（双边都入账了）。
对账相关的问题
不同系统日切点不一致问题：滚动对账
差错处理：补账，补偿（退款）
相关概念
轧帐和平帐
轧帐：是按照客户订单号来比较本地交易记录和渠道交易记录是否一致。从算法角度，是计算两个数组的差异。在单机运行时，可以采用的算法不少，这里不详细介绍。 我们推荐采用mapreduce来轧帐，这有个优势，可以按照订单号将渠道提供的记录和本地记录shuffle到同一个reduce处理上，这样就可以很容易进行数据比对。 轧帐中最大的坑，莫过于切分点的问题。比如以整0点为切分点，那存在一个问题，本地23:59发起的交易，到了渠道侧，可能会在00:01处理，这一笔交易变成第二天的帐了。实际处理中，一笔交易在渠道侧处理，花上几分钟都有可能。 对于切分点附近无法确认的帐，做一个时间窗，在时间窗内的数据，留待第二天对账时继续处理。
平帐：发现两边不一致的数据，那应该如何处理？数据量不大时，记录起来，人工甄别就行。但如果数据量很大，每天上千条，人工处理就成本太高了。这个没有统一的处理方法，需要根据有问题的数据，做个分析，然后做自动处理。 针对交易记录的对账的处理，主要有如下情况：
长款： 本地未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致。 一般处理是将本地状态修改为已支付，并做响应的后续处理，比如通知业务方等。
短款：本地已支付，但是支付渠道中无记录；或者本地无记录，支付渠道有记录。在排除跨日因素外，这种情况非常少见，需要了解具体原因后做处理。
金额不一致： 本地已支付，支付渠道已支付，但是金额不同，这个需要人工核查。
长款和漏单
在以平台交易为基准的情况下和银行对账，发现周期内的交易，平台有此订单而第三方支付中没有订单，成为平台长款。平台长款一般是由于用户在支付的时候跨天的情况，比如用户在23:58分创建了订单，在第二天的凌晨00:03分进行了支付。在以银行交易为基准的情况下对账，银行有此订单而平台无此订单，即为平台漏单。平台漏单很少见，一般直接转人工处理。
系统架构参考：
参考文章：
https://www.cnblogs.com/ityouknow/p/7015879.html
https://www.zhihu.com/question/59876288/answer/171482665
凤凰牌老熊：支付系统的对账处理与设计
