隔了一周才来写这篇文章，前一篇文章介绍了自己在渠道路由的处理经历也得出了降低渠道成本的结论。这周正在做支付定向营销方案，还在规划中待后续有结果了再分享给大家。今天我主要说一下自己对于对账的经验和理解。

一、对账介绍

看这篇文章的相信大家对支付都有了解，对于对账来说应该不陌生，肯定也明白对账的目的。简单例子，就是你和另外一个人做生意，约定的结款是月结，他每天都从你这里进货，你会记账说我应该收多少钱，他也会记账说他应该付多少钱；在月底结款的时候，他会说我应该结1w给你；然后给你一个进货的明细单子，你拿着这个单子和你自己的单子对比看是否正确，这就是对账。只是支付系统的对账涉及到其他账务处理事情相对感觉会比较复杂而已。

说到对账，个人感觉不同公司业务场景不同对于对账的诉求也就会有差别。比如我之前待的一家公司是做预付卡的，持有预付卡发行与受理的牌照，公司的商业就是纯以支付为主，对账只会存在与支付渠道的对账，确保实收与应收相平，受理商户则自己进行业务对账，平台只提供对账单；现在这的这家公司有所区别，它应该跟其他具备支付牌照的互联网公司业务类似，支付更多应用于公司内部业务场景，这种情况下由于公司职责划分等的不同，对账这块就会分为渠道对账和业务对账两块，渠道对账就类似上面的情况与支付渠道进行对账确保应收和实收相平，业务对账其实就是把支付作为外部公司看待，站在公司业务的角度完成业务的交易数据与支付对账单的对账，确保业务应收与实收相平。

二、渠道对账

那我先来说说渠道对账，这块大家应该了解的最多。一般对于一个做支付的产品来说，接触到这块的机会应该不会太多，因为这块基本上是在支付早期就会建立好的，后续基本就是简单优化。

说起渠道对账，由于支付渠道提供对账单的方式不同进行渠道对账的方式也就不同，总的来说对账方式分为两类：

• 自动对账
• 手动对账

1、自动对账

自动对账主要针对支付渠道能提供线上对账单的渠道，如支付宝，微信，某些银行等。

支持线上提供对账单的渠道又会依据提供对账单的技术方式进行细分，如:HTTP,HTTPS,FTP等，以及对账单格式也不同 如：文本，XML,CSV等，对于这种是依据外部渠道为准，没办法统一标准的，基本都是在线上获取后对账单后通过定制化的脚本进行解析和转换成标准格式。

对于自动对账会涉及到支付渠道，资金对账计划，解析脚本等。 资金对账计划执行步骤与逻辑如下：

• 先会去拉取渠道的对账单
• 拉取后根据编写的对应脚本进行解析和格式转化
• 将标准的清算流水与对应的对账日的入账流水进行对账
• 生成对账结果

2、手动对账

手动对账主要针对的需求是部分渠道不提供线上对账单，即只能去渠道的商户管理后台下载或者是其他约定的手动方式获取到的对账单 比如 邮件每日发送等。

这部分功能相对就比较简单，财务人员获取到对应的渠道对账单后，手动根据对账模板整理成标准的对账单并上传到系统，并手动触发对账操作。逻辑流程如下:

• 财务人员按标准格式上传对账单到系统
• 上传成功后，财务人员查询上传的清算流水并触发对账任务
• 对账处理 并 生成对账结果。

PS~ 我这里更多聊得是产品逻辑和设计，对于对账的技术细节和具体处理大家也可以参考人人都是产品经理专栏作家凤凰牌老熊写的文章：《支付系统设计：对账处理（二）》

上述完成对账后，对账结果有差错怎么处理了? (这部分跟账务处理有关, 会涉及到一点会计知识，这里简单介绍下)

上述两个步骤生成的对账结果会有三种情况：

• 多账：即约定日期的交易数据，支付渠道的数据多了。
• 少账：即约定日期的交易数据，支付渠道的数据少了。
• 金额不符：即约定日期内的某笔交易，交易金额不同。

针对这三种情况，一般发现人都是财务，财务会根据将这些异常情况反馈给渠道与支付团队进行定位，但是定位这个并非立马就能出结果，有可能一天，有可能三天，有可能更久，那这些差错账不可能等着定位完了再处理嘛，那每天生成的支付会计报表里面就没法体现出真实的资金情况。

一般对于上述三种情况，我们会与财务约定好具体操作，如下：

• 先反馈给渠道与支付团队进行定位，排查系统问题以避免更大的影响。
• 对于未查明原因的多账情况，可以先进行挂账处理(会计处理的一种方式)，待后续查明原因后进行销账；少账的情况一般都是渠道清算流水少了，这种一般是依据渠道反馈新增清算流水，或者是渠道会在隔天补全这部分流水，这种就无需处理待隔天再查看即可；对于金额不符，一般都是让渠道进行核实，如果确实是渠道错误则修改清算流水金额，如果是我方系统问题，则需要定位后完成系统修复，并根据实际问题进行相关登账处理(会计处理的一种方式)。

有了上述的对账功能和处理机制，更难的是与财务沟通与协调，形成一套标准的业务流程机制并及时完成，只有对账能及时完成并发现问题才能保证资金流转的准确，避免资金问题。附上与财务沟通确定的业务流程简图：

三、业务对账

如果对上述的渠道对账理解了，业务对账相对就会容易很多。业务对账的实质就是设计者角色的转变，渠道对账中设计者是站在支付系统的角度考虑，与支付渠道进行对账；业务对账中设计者是站在使用支付系统的业务方角度考虑，与支付系统进行对账，本质上没有区别。

业务对账系统的需求可能不同公司差别会很大，因为业务对账这块基础模块即完成业务交易数据与支付系统的对账，产生的对账后历史交易数据的处理需求可能会差别很大。这里我就先介绍与本文相关的重点即对账。

业务对账相对要简单的多，因为毕竟是公司自有业务的对账，对账方式可以完成统一，即线上+固定交互方式(如HTTP+xml)等，基本可以实现完全自动化处理。具体自动化处理流程如下：

• 自动对账任务 自动获取支付系统与业务的对账单
• 根据配置的对账规则对对账单进行解析与入库
• 对账处理
• 形成对账结果

形成对账结果后，后续基本为财务进行账务相关的操作以确保账务平衡了(与渠道对账类似)，这块会涉及到大部分会计相关知识，后续我会专门抽一篇文章来写。

好了，对账就先写到这里，很多细节可能需要根据实际公司场景来做调整。如果有什么问题，欢迎留言探讨，希望分享的内容能对你有价值，感谢！

相关阅读

支付清结算之渠道路由支付清结算之渠道路由

本文由 @黑锅我来扛 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议