在做对账系统之前，需要掌握一定的财务知识。对账系统很难做，网络上基本没有手把手教怎么做对账系统的。本文作者结合自身所经历的对账系统项目进行自我梳理整合输出，希望能够对你有所帮助。

本篇文章基于我本身所经历的对账系统项目进行自我梳理整合输出。

虽然我尽可能往通用性去编写，但它还是不一定适合所有系统及业态，而我本人也是在不断的学习自我提升中，或许文章内容有些错误或描述不严谨的地方，懂行的老师辛苦帮忙指出来，我会修改优化。

所以，这篇文章我仅提供参考。

在做对账系统之前，系统的学习财务基础知识是有必要的，要不然你在需求沟通时，或许连需求方（财务人员）的话都听不懂。

财务人员，有一套专业的财务语言！很有意思的，大家可以去了解一下！

互联网的迅猛发展，带动了各行各业的数字化转型，数字化的转型又免不了要从2C，2B两个大方向上下功夫。

前几年，大家忙于搭建属于自己的业务及管理系统，通过中台集群或SaaS或PaaS模式，让自己进入互联网时代的赛道，时至今日，随便去哪个地方，都可以小程序、APP、三方平台进行购物点餐预约等。

在面向消费者的方向，2C的业务遍地开花；而在后方，2B能力也在不断的提升，2C与2B的融合也为各行业品牌带来了一个较大的痛点：

对账难。

为什么会对账难呢？

数据种类多、来源多、样式多、完整性参差不齐、准确性参差不齐、各系统或三方提供数据时间节点一致性弱、对账功能靠后前端感受不到；

对账系统介于业务与财务系统之间，市场没有通用能力强的对账系统。

它所在位置如下图：

从上图可以看到，他的上游有订单和支付（账单），下游有财务（用友、金蝶等），还有各类的财务能力工具，如发票管理等。

在写这篇文章之前，我有在网络上、书籍中去学习了解行业中对账系统的做法，总的来说，因行业问题和专业性问题，各有优劣，同时，我自己也主导过多次对账系统从0-1的建设，有相对简单一点的，也有复杂一点的，其中涉及的难点巨多。

复杂一点的，当时系统评审会就连续开了十个工作日以上，平均每天不低于6小时的会议时间。而且，对账系统介于业务与财务系统之间，单纯的了解业务是不可行的，必踩坑，所以同步需要了解财务的相关知识，具体的后文会讲解一部分。

在这几年对账系统的建设过程中，从十位以上财务从业人员、财务专家那里学习到很多财务对账相关的知识。

有些知识在对账系统中的运用很重要，但在前面所了解学习的对账相关文章或教程中都没有看到过，而本人也觉的这部分内容在对账系统中作用性很大，在后续的篇幅中也会进行讲述。

对账系统很难做，网络上基本上没有手把手教做对账系统的，很多的内容似是而非，前后翻阅能把人看懵。

想着既然要写这篇文章，不如就干脆写的细一点。

因为会写的比较细，所以对账相关的文章肯定不是短时间能写完，毕竟不是一两篇的篇幅就能讲清楚的。

会分成多次更新，更新频率“随缘”，但肯定会更新完。

第一篇会为大家普及一些财务知识，以方便大家迅速进入有效的财务基础理解阶段。

同时，在第一篇中先预设一个对账系统建设的需求场景，把需求进行罗列，作为后续详细拆的来源。

2.1 对账的基本概念

对账，就是核对账目，是指在会计核算中，为保证账簿记录正确可靠，对账簿中的有关数据进行检查和核对的工作。

对即是核对，账即账目。

在互联网产品中，检查指的是对需要对账的数据进行查验，保证数据的完整性与准确性，一般会在不变动数据的情况下，对该部分数据进行有效获取、校验、标准化（统一格式）。

核对指的是一对一的核实对比，比如订单与账单对比，订单指的是电子或纸质合同，账单指的是资金记录（支付宝账单、银行账单等）。

对账就是将需要对比的数据，经过校验及标准化后，进行一对一的对比，以保证数据记录的可靠，同时找出双方的差异，并支持对差异数据进行溯源处理。

2.2 本方与对方的概念

对账是指将需要核对的数据（一般为订单及账单）进行一对一的对比，在对比前，需预设本方与对方。

本方指的是可靠性较高（主观判断）的一方数据，或需主要对比的一方数据。

对方指的是被对比的一方数据。

在订单和账单两种数据类型上，理论上任何一方都可以被定义为本方，一类数据仅能被定义为某一方，不可同时将某数据既定义为本方又定义为对方。

2.3 原始凭证

会计凭证按照编制的程序和用途不同，分为原始凭证和记账凭证。

原始凭证是在经济业务发生时取得或填制的，用以记录和证明经济业务发生或完成情况的凭证。

我们在购买商品或服务时，所获得的原始票据，即为原始凭证，如：

去餐厅点餐时，点餐完成服务员提供的点餐单（有的有价格有的没有价格），付款时手机付款记录；

去超市购买商品时，付款完成，超市所提供的交易清单及付款记录；

通过互联网购物，产生的订单，订单对应的支付记录（支付宝、微信等）均属于原始凭证。

因此，原始凭证的种类很多，如发货单、收货单、领料单、银行结算凭证、各种报销单据等在业务发生过程中产生的依据都算作原始凭证。

从对账业务来说，涉及的凭证偏向于订单、账单、支付单等原始凭证。

2.4 记账凭证

记账凭证，会计专业术语，是财会部门根据原始凭证填制，记载经济业务简要内容，确定会计分录，作为记账依据的会计凭证。记账凭证亦称分录凭证，又称记账凭单，按照登记账簿的要求、确定账户名称、记账方向（借贷方向）和金额的一种记录，是登记明细分类账和总分类账的依据。

那会计分录又是什么？

我们日常如果有记账的习惯的话，一般会这么记：

• 购买商品：电脑，单价8000元，数量1台
• 支付总额：8000元
• 支付方式：支付宝（招商银行卡）

而，财务侧在对原始凭证确认后，记账的方法叫做复式记账法（借贷记账法），其所记录的内容，叫做会计分录，会计分录基于复式记账法有标准的格式。如：

• 借：库存商品-电脑 8000元
• 贷：银行存款-招行 8000元

基于借贷逻辑（参考资产负债表），我们可看出，库存商品-电脑属于资产类科目，在本分录中属于借方，代表资产增加，银行存款-招行属于资产类科目，在本分录中属于贷方，代表资产减少。

即，在我所有的资产中，库存商品增加了一台电脑，但银行存款减少了8000元。

如果购买商品时，商户开具了发票，在借方的分录应该是库存商品-电脑不含税价与税金两条记录，这里就不细写了。

因此，记账凭证其实就是会计分录，会计分录就是财务人员的标准记账方法。

记账凭证是由会计人员对审核无误的原始凭证或汇总原始凭证，按其经济业务的内容加以归类整理，作为登记账簿依据的会计凭证。会计人员填制记账凭证要严格按照规定的格式和内容进行。

专用记账凭证，是指分类反映经济业务的记账凭证。这种记账凭证按其反映经济业务的内容不同，又可以分为收款凭证、付款凭证和转账凭证。

在对账系统中，对账的整体动作，其实相当于财务人员对原始凭证的对比与审查，审查完成的记录成会计分录，最终生成明细账（有多少订单就有多少条明细）及汇总账（无论多少条，只要在我计算的归属范围内的，统一汇总成一条）。

因此，对账系统完成对账后，会根据用户实际诉求，生成明细账及总分类账，即记账凭证。

2.5 单边

在一对一对账完成之后，发现某一条数据对应的另一方无数据，一般称为单边。

比如有订单信息，但无与订单对应的账单数据，那么本次对账差异称为订单单边。

比如有账单信息，但无与账单对应的订单数据，那么本次对账差异称为账单单边。

举例以订单为本方，某订单金额为300元，但对账时未找到账单，则对账差异为300元，差异类型为订单单边。

其公式为：本方金额-对方金额（双方均可以是合并金额）

公式金额等于0为平账，金额等于本方金额为本方单边，金额等于对方金额为对方单边，金额大于零且小于本方金额或金额为负责默认为金额不一致，属于长短款，需溯源查询差异原因。

2.6 长短款

财务侧的现金长短款是指在盘点和核对库存现金时，发现除挪用现金、白条顶库、超限额留存现金等情况以外原因的现金日记账余额与库存现金数额不符。在对账系统中，一般代表应收与实收不符（非单边）。

对账时，除了会发生2.5项所述单边现象，也会存在长短款现象。

• 长款：应收100元，实收120元，计算后，出现了20元的额外收益，这部分即为长款。
• 短款：应收120元，实收100元，计算后，少收20元，这部分即为短款。

2.7 轧（gá）差

轧差是指利用抵销、合同更新等法律制度，最终取得一方对另一方的一个数额的净债权或 净债务，如市场交易者之间，可能互有内容相同，方向相反的多笔交易，在结算或结束交易时，可以将各方债权在相等数额内抵销，仅支付余额。

上述为财务侧轧差的概念，或许难以理解，但举个例子就明白了：

预设A和B都很讲信用，A欠B10万元，B欠A4万元，没有轧差的情况下，B需要向A支付4万元，而A需向B支付10万元；轧差后，则A对B的净欠额为6万元，A只需向B直接支付6万元。

在对账系统中，轧差一般指的是两两之间金额汇总之后的总差额。

2.8 平账与差异（差错）

这里的平账是指对账系统的对账结果：对账对平，而不是财务管理所说的让各个分类账户的金额与其汇总账户的金额互相核算相等，达成会计中的所说的“账账相符”。

差异（差错）指的是未对平的数据。一般差异包括单边、长短款等。

差异的原因一般包括：

• 单边，即本方或对方无数据；
• 长短款，即本方与对方有数据，但对账金额不一致。

单边及长短款可以依靠系统进行初始预判断，再人工复核；但长短款的原因一般需要人工判断及确认。

2.9 财年财月

财年指财务年度，财月指财务月。

一般来说，我国的财年指的是自然年，财月指的是自然月。

国外的财年和财月有遵循自然年自然月的，也有跳出自然年与自然月单独设定的，比如美国部分州，会将企业成立当年的10月份定义为下一年的财年初始，10月份为下一财年第一个财月，且其财月并非自然月，而是以445标准执行，即第一季度第一个财月是从10月1日起的四周，第二个财月为后续四周，第三个财月为再后续五周，所以每个财月都跨自然月。

一般我国国内系统对应的财年财月以自然年自然月为准。

2.10 其他

只要涉及与财务相关的系统，绝对不允许对源数据（原始凭证）进行任何修改。

除了最终汇总金额小数位控制，其他任何阶段，在计算过程中，不可进行四舍五入、小数位限制等操作。

本章2.3-2.8仅作基于对账系统的简单描述，其在财务中所代表的含义相对较为复杂，个人建议应该从财务的角度去丰富相关的知识。

同时，没有财务基础想走对账或需要走对账发展路线的，建议先恶补复式记账法、资产负债表等；若有财务基础的，忽略本篇财务基础部分，当然，若发现我有描述不当的，还请不吝指出，我将请教确认后进行修改更新。

某零售品牌2C业务扩展迅速，对账系统老旧，且人工干涉较多，原对账中心已经跟不上业务发展，需建设最新对账中心。

3.1 现状

• 法人A：负责自有渠道，包括APP、微信小程序、支付宝小程序；
• 法人B：负责三方渠道，包括京东、天猫、美团、抖音；
• 支付方式：APP对接微信、支付宝、云闪付，以直连模式接入；
• 储值卡：APP支持储值卡支付，支持储值卡 三方组合支付；
• 储值卡账户：合规的单用途预付费卡，消费者储值统一存入法人A管理账户，消费者使用储值消费时，从法人A管理账户支付至门店/渠道账户；

3.2 建设目标

搭建对账系统，以三方账单为本方，实现最小周期T 1的对账，每财月月结输出明细账、汇总账，汇总账支持按法人、渠道维度进行查询，支持输出汇总凭证，输出月结报表；

• 当业务渠道新增时，支持灵活配置化补充渠道信息，迅速接入对账系统；
• 当支付渠道新增时，支持灵活配置化补充渠道信息，迅速接入对账系统；
• 支持订单以文件形式导入；
• 支持账单以文件形式导入；
• 支持账务审核流程；
• 支持用户权限管理及数据权限管理；
• 支持人工平账。

3.3 数据关系

APP、微信小程序、支付宝小程序、京东、天猫、美团、抖音各渠道统一通过订单中心向对账中心输出订单，其周期为D 1，即每日0点获取前一日全部订单，以接口形式获取；

各支付渠道支付账单需从各渠道下载导入对账系统，其可支持下载周期为T 1。

3.4 其他说明

以上为基础需求描述，在后续讲解中若发现有遗漏的，在实际设计篇幅中进行补充，同时会对本篇进行优化更新。

学习做产品时，总有人在你耳边说，要想把产品做好，需要有自己的产品方法论。

什么是产品方法论？以需求梳理阶段举例，其实就是你去获取、拆解、梳理、规整需求的方法、使用的工具或者步骤等。

我所常用的方法是从上往下看，通过总-分模式，先从大框架上了解整体业务目标，再基于组成大框架的一个个小模块，去分别拆解、梳理细节内容。

这也就是人们常说的，框架思维。

以当前需求为例，首先确认清楚，我们要做什么？

做什么：做一套财务人员所需要的基于业务订单与支付账单的对账系统，对账完成后输出财务人员所需的凭证及报表。

使用者、输入、输出、核心能力已经很明确了。

• 使用者：财务人员；
• 输入：业务订单与支付账单；
• 输出：凭证及报表；
• 核心能力：基于订单与账单的对账。

框架方向了解后，我们应该怎么去梳理细节内容呢？

从整个产品的维度思考，我们的用户是财务人员，系统的属性也是偏向于财务的，那么整体来说，我们系统中将包含很多的财务底层规则。

因此，如果在看同学没有财务基础的，或财务基础很薄弱的，建议先阅读第一篇。而财务知识很丰富的同学可以接着往下看。

我们已经对框架熟悉了，也知道需要考虑财务规范，那么我们在需求的拆解与梳理过程中，每一个步骤应该把模块功能和财务规范做有效的结合。

4.1 业务输入

从第一篇模拟的业务需求来看，我们可以对获得的信息进行拆解：

法人： 是具有民事权利能力和民事行为能力，依法独立享有民事权利和承担民事义务的组织，是企业、公司的另一种称呼。在本需求中，某集团下有两个分公司（法人），分别负责自有渠道（自行建设）和三方平台渠道（外部合作渠道）的业务管理。

补充阅读：一个公司就是一个法人，我们看到公司营业执照中有法人代表，一般该法人代表就是公司老板，法人代表的含义是，他代表这个公司，是该公司（法人）的代言人。

所以在上游原始数据可能存在多个归属时，应着重考虑输入的原始数据归类问题。同时，在我们拿到这部分信息时，应该意识到我们所设计的表结构中，一定要有数据归属字段，如所属法人、所属渠道等。

从上表，我们已知需要从哪些法人及渠道获取订单数据，同时我们还应该从需求方获取相关的信息，包括但不限于：数据提供方式、提供周期、是否有统一订单中心进行处理等。

如果需求方当前系统比较简单，没有统一的订单中心负责接入全部订单信息，我们需要直接从三方拉取订单，那么需要额外准备与三方支持沟通的方式（钉钉群、微信群、企微群等），以便在需求梳理、数据传输确认过程中及时沟通了解一些不清楚的地方。

一般来说，三方平台都会有指定的支付方式，比如京东自有的京东支付、天猫的支付宝支付、抖音自有的抖音支付或微信/支付宝支付等；所以法人B负责的三方渠道部分我们不考虑支付功能接入。

而法人A所负责的自有渠道，可能会对接多种支付方式，以上需求描述也明确的给出了对接的三方支付。

同时，明确了接入模式为直连。

直连指的是APP直接与三方支付（如微信）对接，不通过聚合支付统一处理。而通过三方聚合支付（如随心付、扫呗等）对接的一般属于间连。

直连与间连各有优劣，本文不涉及支付具体细节就不细讲了，有想了解的朋友可以自行去了解一下支付相关的知识。

回归需求拆解，我们还需要明确：对接的支付渠道通过何种方式提供账单数据、提供账单的周期等；三方平台如何提供账单数据、提供账单的周期等。

储值第一要素是合规，除了企业自身需要去申请单用途预付费卡资质之外，同步需要与银行签订监管协议，储值金额统一存入企业在该银行的监管账户中。

单用途预付费卡主要分两种，记名卡与不记名卡。两者可储值额度不同、有效期限制也不同，可以单独去了解一下。

要点：所有人都应该重视的是，消费者储值资金虽然在监管银行所设立的企业账户中，但这笔钱的所有权仍是消费者，对于企业来说，这不是收入，而是负债，在资产负债表中属于右侧，在凭证中所体现的科目主要是预付费或递延收益。

这部分资金，只有消费者在使用储值消费后，才能基于订单支付信息从监管账户划入收入账户。

在本示例需求中，用户使用储值卡金额支付时，其订单来源是法人A所属业务渠道APP，账单来源是法人A监管银行。

我们在进入4.1之前有讲，必须考虑财务属性，因此，除以上信息外，我们还需要补充财务相关信息，包括但不限于：

财年财月、税金管理、会计科目等。

同时，输入给系统的全部数据，需要区分主数据与业务数据。

主数据指的是能够辅助系统功能的数据类型，包括法人、渠道门店、支付渠道、商品类型、活动营销、财年财月、税率管理、会计科目等，后续在产品设计过程中，配置的各种属性如对账规则、凭证规则等都算主数据范畴。

业务数据指的是需基于系统规则进行对账处理的数据，在本系统中，业务数据为订单数据及账单数据。

对账完成输出的会计凭证及报表数据，也属于业务数据。

• 主数据的来源一般分为两种，从上游系统同步或在自有系统创建。
• 业务数据来源一般也分两种，从上游系统推送或通过文档导入。

本小节拆解梳理完成后，可以形成如下导图：