支付系统-对账系统

2.1、什么是资金对账

在会计上的概念：指为了保证账簿记录的正确性而进行的有关账项的核对工作，做到账实相符(正确性)、账证相符(真实性)、账账相符。

在支付机构的概念：资金对账在对账中心进行，将系统保存的账务流水与银行返回的清算流水和清算文件进行对账，核对系统账务数据与银行清算数据的一致性，保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。即核对银行实际清算资金如充值、充退、提现等业务的银行处理结果是否一致。

在会计上的概念：指为了保证账簿记录的正确性而进行的有关账项的核对工作，做到账实相符(正确性)、账证相符(真实性)、账账相符。

在支付机构的概念：资金对账在对账中心进行，将系统保存的账务流水与银行返回的清算流水和清算文件进行对账，核对系统账务数据与银行清算数据的一致性，保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。即核对银行实际清算资金如充值、充退、提现等业务的银行处理结果是否一致。

2.2、对账中心的作用

对账中心是主要处理对账的系统模块，主要业务是清算对账。对账中心部署于工作平台，分别接受会计系统和清算系统的数据输入进行对账处理。

对账中心最主要的职责是勾兑银行清算流水与支付系统入账流水，用以检查反映银存实际账户的余额变化与支付系统内部户余额变化是否平衡。对于已经核对无误的银行清算流水和支付系统入账流水，分别进入相应的历史银行流水库和历史入账流水库。

对于勾兑结果中银行清算流水多于系统入账流水的，而操作人员不明确资金的来源，需要根据所设定的分类规则将暂不明确的资金进行挂账处理。而后我们认为该部分资金已经系统入账，可以入历史流水库。

因为此时的银存实际账户的余额增加，与之对应的是支付系统内部户余额也增加了，比如：T 日的挂账可能会在 T+N 日后进行销账确认，而后续的销账行为是对明细流水的业务分流处理，我们不应将 T+N 日的销账所产生的账务流水作为入账流水，不再需要到对账中心体现。

三、对账内容和数据来源

第一步：入账流水和清算流水进行核对，目的是保证对每一笔订单银行的处理结果和我们系统的业务处理结果一致。

第二步：对账汇总确认单和银行对账单进行核对，目的是通过轧余额等方式核对各类业务的银行处理结果是否与银行实际清算给我们的资金一致。

第一步：入账流水和清算流水进行核对，目的是保证对每一笔订单银行的处理结果和我们系统的业务处理结果一致。

第二步：对账汇总确认单和银行对账单进行核对，目的是通过轧余额等方式核对各类业务的银行处理结果是否与银行实际清算给我们的资金一致。

3.1、对账业务流程

对账业务流程图

3.2、对账中心主要功能

银行发生资金变动的入账流水，包括：充值、提现、提现失败、充退、充退失败、退票、购汇、信贷放款、信贷还款、还贷失败一系列业务引起的账务变动信息。这些业务流水在账务系统入账后，会计核心接收到登记分录请求并处理完毕，发送该流水至对账中心，对账中心对于某个业务的反向资金变动所产生入账流水也同步至对账中心。

这样做的目的是让待清算与入账流水在日切点保持等额，比如：提现 T 日会员申请提现，生成文件后会员账户提现金额转入待清算提现款项，与此同时发送流水到对账中心，此时待清算与对账中心入账流水是保持平衡的。

而 T+1 日银行处理失败，系统会回充带清算提现款，如果此时不发送失败流水到对账中心与其对应的流水进行购销的话，则入账流水就会不变，和带清算提现不平衡。

（1）、完整的日结流程支持：银行清算流水入库 → 流水对账 → 流水分类 → 汇总确认单 → 自动挂账 → 销账确认 → 操作员轧账 → 总账日结以及登记银行余额等。

（2）、完善的报表模型输出：如按入账日期 / 银行日期 / 清算日期等的统计报表、银行账户余额报表、未达款项报表等；

（3）、提供日切服务：在经确认后进入历史清算流水的，同步汇总该部分数据进入历史流水汇总表中保存，所以在日切时，只需直接将该汇总数据再次汇总即可。

（4）、外围业务功能支持：提供对于银行账户（ 独立于对账中心之外，不参与处理逻辑 ）的管理功能，支持与内部户的映射管理，用以满足部分报表需求；提供基于账务核心所提供的业务代码查询功能；提供对于财务系统的交互支持，包括与财务科目的对应关系管理、通知流水数据等；提供用以校验订单与清算流水匹配状态的错账核实功能。

（1）、完整的日结流程支持：银行清算流水入库 → 流水对账 → 流水分类 → 汇总确认单 → 自动挂账 → 销账确认 → 操作员轧账 → 总账日结以及登记银行余额等。

（2）、完善的报表模型输出：如按入账日期 / 银行日期 / 清算日期等的统计报表、银行账户余额报表、未达款项报表等；

（3）、提供日切服务：在经确认后进入历史清算流水的，同步汇总该部分数据进入历史流水汇总表中保存，所以在日切时，只需直接将该汇总数据再次汇总即可。

（4）、外围业务功能支持：提供对于银行账户（ 独立于对账中心之外，不参与处理逻辑 ）的管理功能，支持与内部户的映射管理，用以满足部分报表需求；提供基于账务核心所提供的业务代码查询功能；提供对于财务系统的交互支持，包括与财务科目的对应关系管理、通知流水数据等；提供用以校验订单与清算流水匹配状态的错账核实功能。

对账流程图

四、对账中心功能模块分析

4.1、获取资金对账数据

（1）、获取方式：需要进行清算流水导入的文件一般通过人工在页面上导入，另外有些业务的流水文件通过系统自动匹配或者定时获取的方式得到。

（2）、清算流水导入渠道：需要统一各清算流水导入功能到一个页面入口， 同时引入清算通道对账的逻辑，将清算流水导入过程需要映射清算通道（ 包含新增清算流水等 ）。

（3）、各类业务的清算流水文件的解析和导入逻辑不一样。

（1）、获取方式：需要进行清算流水导入的文件一般通过人工在页面上导入，另外有些业务的流水文件通过系统自动匹配或者定时获取的方式得到。

（2）、清算流水导入渠道：需要统一各清算流水导入功能到一个页面入口， 同时引入清算通道对账的逻辑，将清算流水导入过程需要映射清算通道（ 包含新增清算流水等 ）。

（3）、各类业务的清算流水文件的解析和导入逻辑不一样。

4.3、对账逻辑（1）、一对一对账

入账流水只可能存在一条，银行入账流水也仅存在一条，然后一对一去对。目前按照一对一对账的业务涉及到：网银 B2C 充值、网银 B2B 充值、VISA、网汇E、卡通充值、正常提现、认证提现、银企互联提现、卡通提现、卖家信贷、信用卡还款提现、COD、网点支付。

对账标准：（清算通道 + 订单号 + 金额） Or （银行名称 + 业务代码 + 订单号 + 金额）。

满足一对一的业务如下：

Tips：

（1）、清算流水有，入账流水也有，金额一致，对账成功，清算流水、对账流水打上 ‘对账成功’ 标志，记录对账日期为系统当日；

（2）、清算流水有，入账流水也有，金额不一致，清算流水记金额不等，记录对账日期为系统当日，入账流水不变；

（3）、清算流水有，入账流水该订单号没有，清算流水打上 ‘银行多帐’ 的标志，记录对账日期为系统当日；

（4）、清算流水有，入账流水没有该业务代码初始状态的，清算流水打上 ‘银行多帐’ 的标志，记录对账日期为系统当日；

（5）、清算流水有，入账流水没有该银行的初始状态的记录，清算流水打上 ‘银行多帐’ 的标志，记录对账日期为系统当日；

（6）、对账之前需要判断 1 对 1 的流水中是否有重复，有重复的返回失败不进行后续对账。

Tips：

（1）、清算流水有，入账流水也有，金额一致，对账成功，清算流水、对账流水打上 ‘对账成功’ 标志，记录对账日期为系统当日；

（2）、清算流水有，入账流水也有，金额不一致，清算流水记金额不等，记录对账日期为系统当日，入账流水不变；

（3）、清算流水有，入账流水该订单号没有，清算流水打上 ‘银行多帐’ 的标志，记录对账日期为系统当日；

（4）、清算流水有，入账流水没有该业务代码初始状态的，清算流水打上 ‘银行多帐’ 的标志，记录对账日期为系统当日；

（5）、清算流水有，入账流水没有该银行的初始状态的记录，清算流水打上 ‘银行多帐’ 的标志，记录对账日期为系统当日；

（6）、对账之前需要判断 1 对 1 的流水中是否有重复，有重复的返回失败不进行后续对账。

入账流水里相同订单号，相同清算渠道，相同，金额相同业务代码的流水存在对条（比如充退）；而银行清算流水也可能是存在多条的情况的，这种情况下是多对多去对账的，遵循先到的先对的原则。

对账标准：（清算通道 + 订单号 + 金额） Or （银行名称 + 业务代码 + 订单号 + 金额）。

满足多对多的业务如下：

入账流水有多条，和银行的一条去对账。

对账标准：（清算通道 + 订单号 + 金额） Or （银行名称 + 业务代码 + 订单号 + 金额）

涉及的业务：境外收单

内部流水购销是针对那种有入账流水表来说的，比如提现业务，提现文件生成就会扣款此时会同步一笔入账流水；而回导失败之后又会回充，此时也会同步一笔反向的业务流水，这两条流水不用再去和银行的资金流水进行对账，直接在入账流水这边进行购销即可。

需要购销的业务如下：

（1）、购销的规则：非已勾销状态下，同一银行同一订单号，金额一致而业务代码相反的正向流水进行勾销，而且一条反向流水只勾销一条；

（2）、日终轧账时候的购销：日终轧账的时候会对未购销的流水再次进行购销确保当天的流水都购销完全。（这个情况是为了解决反向流水先于正向流水先出现的逻辑错误情况而加的并提示流水号）；

（3）、如果业务代码相反，而金额不等的情况，就无法进行购销，这种情况原来是作为违反逻辑规则来进行标记的。这部分数据进行查明之后，可以修改流水之后，在日终轧账的时候从新进行购销；

（4）、购销分 ‘一对一’（提现）和 ‘多对多’ （充退）的购销；

（5）、勾销的流水不入历史库。

（1）、购销的规则：非已勾销状态下，同一银行同一订单号，金额一致而业务代码相反的正向流水进行勾销，而且一条反向流水只勾销一条；

（2）、日终轧账时候的购销：日终轧账的时候会对未购销的流水再次进行购销确保当天的流水都购销完全。（这个情况是为了解决反向流水先于正向流水先出现的逻辑错误情况而加的并提示流水号）；

（3）、如果业务代码相反，而金额不等的情况，就无法进行购销，这种情况原来是作为违反逻辑规则来进行标记的。这部分数据进行查明之后，可以修改流水之后，在日终轧账的时候从新进行购销；

（4）、购销分 ‘一对一’（提现）和 ‘多对多’ （充退）的购销；

（5）、勾销的流水不入历史库。

显示对账结果，选择后续的相应的处理界面，复核员在此模块进行流水的确认，还有的功能就是对于已经对账处理的银行清算流水与系统入账流水进行后续业务分流推进。

（1）、对于大部分对账成功的数据，可以将这些流水确认，确认后该部分流水将进入历史清算流水，只有进入历史清算流水的才认为银行与支付系统数据对平。对账成功的银行清算流水、账务入账流水全部进入各自历史清算流水表保存，相应的银行清算流水与入账流水同步删除。

（2）、金额不等的流水，可能是银行清算流水文件有误，也可能是错账，采取的做法是操作员手工修改金额，在银行清算流水管理里操作或直接删除，将其推进到下一轮的对账处理环节，对账是可以重复对的，只要满足初始状态要求的流水即可。

（3）、多账部分，由于各种已明确/未明确的原因，银行已经实际清算给支付公司了，但支付公司的账务系统并没有入账，需要提供一个流水分类和分类汇总挂账的操作入口。系统默认多账的流水给出的菜单是流水分类，金额不等的流水给出的流水管理页面。区别在于，在点流水分类时，只允许修改业务类型、银行日期，而且改完后不改变多账状态；流水管理，修改状态后，流水的对账状态将变成初始状态，需要进行重新对账。

（4）、流水进入历史库的校验规则。

（1）、对于大部分对账成功的数据，可以将这些流水确认，确认后该部分流水将进入历史清算流水，只有进入历史清算流水的才认为银行与支付系统数据对平。对账成功的银行清算流水、账务入账流水全部进入各自历史清算流水表保存，相应的银行清算流水与入账流水同步删除。

（2）、金额不等的流水，可能是银行清算流水文件有误，也可能是错账，采取的做法是操作员手工修改金额，在银行清算流水管理里操作或直接删除，将其推进到下一轮的对账处理环节，对账是可以重复对的，只要满足初始状态要求的流水即可。

（3）、多账部分，由于各种已明确/未明确的原因，银行已经实际清算给支付公司了，但支付公司的账务系统并没有入账，需要提供一个流水分类和分类汇总挂账的操作入口。系统默认多账的流水给出的菜单是流水分类，金额不等的流水给出的流水管理页面。区别在于，在点流水分类时，只允许修改业务类型、银行日期，而且改完后不改变多账状态；流水管理，修改状态后，流水的对账状态将变成初始状态，需要进行重新对账。

（4）、流水进入历史库的校验规则。

举例说明：A 操作员导入了一笔流水，系统对账成功，银行清算流水与账务入账流水状态都被置为成功状态；B 操作员再次导入该相同流水，由于入账流水处于成功状态的可以继续对账，所以再次对账成功。系统在对账环节认为正常，但在入历史清算流水时必须做每组流水数据的平衡检查：必须是清算流水总额与入账流水总额匹配才可以进历史数据。

对于上述的场景，如复核员针对 B 操作员的对账成功流水确认后，可以正常进入历史流水，对账批次号认最后操作的批次。而继续对 A 操作员的成功对账流水确认，则系统将认为是不合法的入历史流水行为。或者不对特定操作员的汇总确认，系统必须检验出所存在的重复银行清算流水，并将对应的明细数据显示复核员。此时可将该重复对账的清算流水删除即可。

（3）、流水分类和分类汇总挂账

清算流水管理

对于所有的清算流水，都可以在此模块下进行查询、修改、删除，同时也可以新增流水。

（1）、查询功能，银行名称、业务代码、银行日期不能为空，业务代码和银行可以多选。

（2）、修改功能，处于未对账（初始）、金额不等、多账、对账成功状态的流水可以进行单笔、批量修改操作，这里的批量修改动作与流水分类功能类似，只是该功能入口不仅支持对批量流水的业务代码、银行日期更新，也支持其他要素信息批量修改，作为（3）、提供给操作员在未对账前批量修改已知流水的手段之一；对已挂账的流水，不允许更新。

流水删除：处于未对账（初始）、金额不等、多账、对账成功状态的流水可以进行单笔、批量删除操作，已挂账状态不允许删除。

（1）、查询功能，银行名称、业务代码、银行日期不能为空，业务代码和银行可以多选。

（2）、修改功能，处于未对账（初始）、金额不等、多账、对账成功状态的流水可以进行单笔、批量修改操作，这里的批量修改动作与流水分类功能类似，只是该功能入口不仅支持对批量流水的业务代码、银行日期更新，也支持其他要素信息批量修改，作为（3）、提供给操作员在未对账前批量修改已知流水的手段之一；对已挂账的流水，不允许更新。

流水删除：处于未对账（初始）、金额不等、多账、对账成功状态的流水可以进行单笔、批量删除操作，已挂账状态不允许删除。

入账流水管理

入账流水管理功能提供对账务入账流水的查询以及下载功能；为了杜绝对入账流水的人为变更操作，禁止支持对入账流水进行修改或删除处理。

（1）、查询时银行名称、业务代码、入账日期不能为空，业务系统流水号：针对某类业务的业务流水号，如充值业务就是充值流水号；账务流水号：账务处理的流水号，即账务操作记录数据的序号，在账户明细查询里可以获取。

（2）、对于提现类失败回充的流水，在操作员进行对账动作后，系统自动进行购销，在入账流水查询时，将对账状态选为已购销可以查到，这些不进入历史库，根据数据量，系统定时清理这些数据。

（1）、查询时银行名称、业务代码、入账日期不能为空，业务系统流水号：针对某类业务的业务流水号，如充值业务就是充值流水号；账务流水号：账务处理的流水号，即账务操作记录数据的序号，在账户明细查询里可以获取。

（2）、对于提现类失败回充的流水，在操作员进行对账动作后，系统自动进行购销，在入账流水查询时，将对账状态选为已购销可以查到，这些不进入历史库，根据数据量，系统定时清理这些数据。

历史流水管理

分为历史入账流水和历史清算流水，查询功能在同一页面，查询时可以一起查询，也可以单独查询。历史流水只供查询和下载，不允许进行修改和删除操作。选择历史银行流水和历史清算流水（清算日期的时间间隔不能超过 7 天）进行查询，历史入账流水中无银行日期，历史银行流水中无入账日期。

（5）、银行余额录入功能

在该模块下，实现对每个银行账户的实际余额录入，以此来和内部账户余额进行匹配校验。分为银行余额登记，银行余额导入（复核），以及银行余额查询功能。

（1）、银行余额登记：选择对应日期以及银行账户录入后，保存，此时去银行余额查询是看不到录入余额的，需要复核导入核对完毕后才能看到，保证核对的有效性。登记后系统记录一个临时余额。系统每天凌晨 1:15 的时候会跑批，取上一日已复核过的余额自动带入下日临时余额，如果不登记的话，就取上日余额。

（2）、银行余额导入：标准格式是一个填写银行余额的 excle 模板，导入后的核对逻辑，对复核员导入的数据进行检测该帐户是否有临时余额。根据银行账号、银行日期、银行余额等条件查询银行余额表。

判断 1 ：如果查询出结果为空那么将返回给用户：“这个银行帐号找不到对应的银行临时余额！”。

判断 2 ：如果查询结果大余一条，将返回给用户：“这个银行帐号的一天有多个银行临时余额，不正常！”

判断 3 ：检测该银行帐号对应的银行余额是否相等。如果不相等将返回给用户：“临时余额和实际余额不相等，核对失败！”当余额核对成功后，将复核员导入的余额写入该对应帐户的实际余额，并修改余额状态为已复核。实际余额更新成功后，将删除当天日期的临时余额。

（3）、银行余额查询：对操作员登记余额的信息，以及复核员复核过的余额进行查询，查询条件：银行名称、银行帐户、帐户状态、银行日期、余额状态。帐户状态：分为正常、废除、和销户三个状态，默认为正常状态。余额状态：分为未录入（N）、已录入（A）、已复核（Y）三个状态，默认为全部。

（1）、银行余额登记：选择对应日期以及银行账户录入后，保存，此时去银行余额查询是看不到录入余额的，需要复核导入核对完毕后才能看到，保证核对的有效性。登记后系统记录一个临时余额。系统每天凌晨 1:15 的时候会跑批，取上一日已复核过的余额自动带入下日临时余额，如果不登记的话，就取上日余额。

（2）、银行余额导入：标准格式是一个填写银行余额的 excle 模板，导入后的核对逻辑，对复核员导入的数据进行检测该帐户是否有临时余额。根据银行账号、银行日期、银行余额等条件查询银行余额表。

判断 1 ：如果查询出结果为空那么将返回给用户：“这个银行帐号找不到对应的银行临时余额！”。

判断 2 ：如果查询结果大余一条，将返回给用户：“这个银行帐号的一天有多个银行临时余额，不正常！”

判断 3 ：检测该银行帐号对应的银行余额是否相等。如果不相等将返回给用户：“临时余额和实际余额不相等，核对失败！”当余额核对成功后，将复核员导入的余额写入该对应帐户的实际余额，并修改余额状态为已复核。实际余额更新成功后，将删除当天日期的临时余额。

（3）、银行余额查询：对操作员登记余额的信息，以及复核员复核过的余额进行查询，查询条件：银行名称、银行帐户、帐户状态、银行日期、余额状态。帐户状态：分为正常、废除、和销户三个状态，默认为正常状态。余额状态：分为未录入（N）、已录入（A）、已复核（Y）三个状态，默认为全部。

业务简述：针对日常结算工作中非银行待查类的内部账户进行登记，如：清算款、利息、手续费等；该业务登记不产生后续业务登记行为，即不具有作为初始凭证号的使用功能。对于批量销帐类业务处理中，多会员转帐失败的，导致过渡户上有剩余金额情况的，可通过此处进行内部户登账，将过渡户（负债）和银存（资产）余额同时减少，再通过待查收入挂帐实现平衡。

业务校验规则：

（1）、必须登记的是一借一贷帐户信息；

（2）、借贷方帐户不能一致；

（3）、金额必须大于 0 ；

（4）、不允许任意一方是销帐帐户。

（1）、必须登记的是一借一贷帐户信息；

（2）、借贷方帐户不能一致；

（3）、金额必须大于 0 ；

（4）、不允许任意一方是销帐帐户。

是否同步对帐中心流水：不需要同步对帐中心流水。

（7）、待查收入挂账

业务简述：应用于结算操作员针对日常结算工作中的银行待查收入进行登记，所产生的业务凭证号作为后续销帐业务的原业务凭证号，并且作为所有该登记所引发的后续业务登记的初始凭证号。其中待查收入挂帐业务凭证的借方（银存帐户）所对应的银行名称作为后续销帐业务的银行名称，包括差额重新挂帐部分再销帐的业务凭证，都递沿该银行名称。

业务校验规则：

（1）、必须登记的是一借一贷帐户信息；

（2）、借贷方帐户不能一致；

（3）、金额必须大于 0 ；

（4）、借方帐户必须是银存帐户；

（5）、贷方帐户必须是销帐帐户。

（1）、必须登记的是一借一贷帐户信息；

（2）、借贷方帐户不能一致；

（3）、金额必须大于 0 ；

（4）、借方帐户必须是银存帐户；

（5）、贷方帐户必须是销帐帐户。

是否同步对帐中心流水：不需要同步对帐中心流水。

（8）、待查收入确认

业务简述：针对银行待查收入登账的挂帐，可以通过本模块进行销帐。此处采取销帐确认方式进行处理，需要选择相应的待查收入挂帐业务凭证进行销帐业务登记。该业务登记可能产生后续业务登记行为，如差额销帐情况下，系统会自动做不足额部分的重新挂帐并复核通过，所产生的挂帐凭证作为后续销帐凭证的销帐卡片号。

业务校验规则：

（1）、所销的原待查收入挂帐凭证必须合法；

（2）、所销的原待查收入挂帐凭证必须已复核通过，处理完毕；

（3）、所销的原待查收入挂帐凭证不能已被销帐；

（4）、销帐总额(贷方发生额之和不得大于原待查收入挂帐凭证发生额)并大于 0 ；

（5）、贷方必须是内部户。

（1）、所销的原待查收入挂帐凭证必须合法；

（2）、所销的原待查收入挂帐凭证必须已复核通过，处理完毕；

（3）、所销的原待查收入挂帐凭证不能已被销帐；

（4）、销帐总额(贷方发生额之和不得大于原待查收入挂帐凭证发生额)并大于 0 ；

（5）、贷方必须是内部户。

业务简述：针对日常结算工作中的银行待查支出进行登记，所产生的业务凭证号作为后续销帐业务的原业务凭证号，并且作为所有该登记所引发的后续业务登记的初始凭证号。其中待查收入挂帐业务凭证的贷方（ 银存帐户）所对应的银行名称作为后续销帐业务的银行名称，包括差额重新挂帐部分再销帐的业务凭证，都递沿该银行名称。

业务校验规则：

（1）、必须登记的是一借一贷帐户信息；

（2）、借贷方帐户不能一致；

（3）、金额必须大于 0 ；

（4）、贷方帐户必须是银存帐户；

（5）、借方帐户必须是销帐帐户 。

（1）、必须登记的是一借一贷帐户信息；

（2）、借贷方帐户不能一致；

（3）、金额必须大于 0 ；

（4）、贷方帐户必须是银存帐户；

（5）、借方帐户必须是销帐帐户 。

是否同步对帐中心流水：不需要同步对帐中心流水。

（10）、待查支出确认

业务简述：针对银行待查支出登账的挂帐，可以通过本模块进行销帐。此处采取销帐确认方式进行处理，需要选择相应的待查支出挂帐业务凭证进行销帐业务登记。该业务登记可能产生后续业务登记行为，如差额销帐情况下系统会自动做不足额部分的重新挂帐并复核通过，所产生的挂帐凭证作为后续销帐凭证的销帐卡片号。

业务校验规则：

（1）、所销的原待查支出挂帐凭证必须合法；

（2）、所销的原待查支出挂帐凭证必须已复核通过，处理完毕；

（3）、所销的原待查支出挂帐凭证不能已被销帐；

（4）、销帐总额(借方发生额之和不得大于原待查收入挂帐凭证发生额)并大于0 ；

（5）、借方必须是内部户。

（1）、所销的原待查支出挂帐凭证必须合法；

（2）、所销的原待查支出挂帐凭证必须已复核通过，处理完毕；

（3）、所销的原待查支出挂帐凭证不能已被销帐；

（4）、销帐总额(借方发生额之和不得大于原待查收入挂帐凭证发生额)并大于0 ；

（5）、借方必须是内部户。

五、意外数据恢复逻辑

5.1、意外数据恢复逻辑

（1）、重复支付：对同一内部订单号进行了二次或二次以上的支付。

（2）、支付失败，金额不等：买家实际支付的金额与交易金额不等。一般产生的原因是，买家在支付时，产生了掉单，卖家随后修改了交易价格。在进行网银对账的时候，即会出现订单金额和交易金额不等的情况，且是一笔掉单。2、3 两类情况只发生在支付上。

（3）、支付成功，金额不等：商户订单状态为成功，后台订单状态也为成功，并且交易状态是买家已付款，等待卖家发货。

（1）、重复支付：对同一内部订单号进行了二次或二次以上的支付。

（2）、支付失败，金额不等：买家实际支付的金额与交易金额不等。一般产生的原因是，买家在支付时，产生了掉单，卖家随后修改了交易价格。在进行网银对账的时候，即会出现订单金额和交易金额不等的情况，且是一笔掉单。2、3 两类情况只发生在支付上。

（3）、支付成功，金额不等：商户订单状态为成功，后台订单状态也为成功，并且交易状态是买家已付款，等待卖家发货。

金额不等，支付成功：是因为会员对一个交易进行支付，但由于网络或银行系统等原因支付公司未接收到银行扣款信息，支付侧交易状态未予以变更，后卖家对该交易修改了价格，买家又对该修改过的价格进行了支付。但该支付成功的信息仍然没有被支付侧接收到，该交易状态仍未变更，后支付侧后台人员先对后面的那笔意外数据进行了恢复，后再对前面那笔意外数据恢复，就会出现这种“金额不等，支付成功”的数据

5.2、对帐及异常恢复逻辑（1）、以商户成功订单为准

用商户上的成功订单与后台的订单来核对：

（1）、若商户订单为成功，后台为初始或者失败，则更改后台状态为成功；

（2）、若后台为成功，商户成功订单中无该订单（时间差），则不更改后台状态；

（3）、若后台为初始或失败，商户成功订单中无该订单，则不更改后台状态。

（1）、若商户订单为成功，后台为初始或者失败，则更改后台状态为成功；

（2）、若后台为成功，商户成功订单中无该订单（时间差），则不更改后台状态；

（3）、若后台为初始或失败，商户成功订单中无该订单，则不更改后台状态。

T+1 日恢复T 日的订单，并且在 T+1 日后不再下载 T 日的订单进行二次或多次恢复。（为考虑会员感受，T 日下班前恢复 T 日 0 点到下班时点的订单）

（3）、时间性差异

由于各家银行系统日切点均不同，并且大多不会在每日的 24 点（或早或晚），所以下载到的 T 日的订单流水与后台T日（ 0:00－24:00 ）的订单流水并不能全部对应上。将商户订单流水与后台订单流水核对，会出现商户有，后台无；商户无，后台有；商户有，后台有三种情况。对于 1、2 两种情况为我们所说的时间性差异。

商户数据与后台数据的关系为：商户数据－（商户有，后台无）＋（商户无，后台有）＝ 后台数据

返回搜狐，查看更多