FMS财务管理系统:对账平台
人工进行对账工作是非常繁杂的,此时,就非常有必要建设一个对账平台。笔者在本文介绍了对账平台的相关内容,分享给大家。
前面介绍过应收对账、财务应付结算两部分内容;应收对账主要是调用第三方支付的接口获取支付流水信息与我司的财务应收进行勾对,达到核对的目的,这部分工作是每天都需要进行的。
应付结算对于财务结算组来说工作量是非常大的,它包括结算原始单据的核对、预付款、质保金、费用单据确认、结算单数据核对、审批、发票的审核与录入。
如果全部工作都依赖财务组同事进行,效率非常低下。所以,有必要搭建一个对账平台,将财务数据推送到核对平台由供应商或商户来进行核对后再由财务组进行复审,利用系统提升工作效率与数据的准确,本篇简单介绍下对账平台的相关内容。
一、对账内容
对账主要包括三部分内容:基础信息、业务往来单据及财务账单。
- 基础信息:包括供应商或商家的基础信息如开户行、税务登记账号等;合同信息包括正在执行的合同与已经结束的合同,涉及财务结算的相关合同条款应该展示出来。
- 业务单据:主要包括采购单据、采购退货单据、销售订单(正常订单、换货出库、补发订单)、销售退货订单(正常退货、换货入库);这两部分对应着经销结算、代销结算或联营结算等财务对账单据,方便供应商或商家进行原始数据的查看核对;业务单据还包括质保金、预付款等有关金额的信息。
- 财务账单:主要包括财务结算单、付款单、费用单据、发票信息,此部分是每月核对的重点,每个公司都会有自己的内部系统,我们提供的对账信息是对账的基础,系统建设较好的公司会获取我们的对账信息到其内部系统中采取系统对账。
二、财务对账过程
对账包括三个过程即:对账数据的准备阶段、数据核对阶段、差异处理阶段。
1. 数据准备阶段
基础数据和业务单据都是业务系统实时生成的,FMS系统会根据单据的状态将这部分信息推送到对账平台。
对账平台只是商家管理平台的一部分,所以对账部分只是推送了已入库、已出库的业务单据数据到财务对账模块。对于在履单过程中的各个状态,需要结合供应链的采购流程、订单流程进行设计,在这里简单说明一下采购和销售的相关数据。
1)采购单据流程
上面的流程加入了采购PO单创建后,需要商家进行确认采购的数量与采购价格,然后经过采购部的复核单据才能生效,此时单据会推送到WMS等待收货。
对于更完善的供应链系统,PO单的创建是根据采购计划单或自动补货单创建后,由采购业务根据系统建货的补货建议单进行修改确认最终的采购数量与采购价。这部分业务通过内部系统与商家管理平台实现。
在下图中的结算单生成是根据经销合同生成的,其余模式的采购单与采购返厂单不会生成结算单,此部分在应付结算部分也有描述。
2)销售单据流程
销售订单是电商系统的核心,它包括自营的销售订单(公司发货)与商家的销售订单(商家发货)。
下面的图上是针对由我司发货的销售订单的简化流程,所以当销售订单在仓库发货后或拒收订单与销售退货订单入库后会进入到对账管理平台中,按销售结算的订单会生成结算单(合作模式为代销、联营)。
如果是商家发货的订单商家管理平台,需要管理整个订单的生成周期(订单发货、物流公司选择、快递信息、退货退款等),同时如果是商家佣金合作模式财务FMS系统中需要根据销售订单生成结算单据(代收款返还、佣金扣款等),具体的需要根据详细需求进行设计。
2. 数据核对阶段
此部分是对账平台的重要部分,它包括数据核对与确认。
由于我们的对账平台是单向核对的,即我司提供已经生成的业务单据与结算单数据,由供应商或商家进行单据的核对与确认。
供应商如何去对账是一个大问题,所以个人觉得要做到两部分:
- 对账单数据,要尽量详细,显示的过程是由汇总到明细的过程来层层展示,即把我们后端的结算单汇总信息、商品信息、单据信息全部展示出来,以便第三方进行核对确认。
- 对账接口,即提供对账单的导出与数据接口,便于第三方人员导出后进行处理以及技术部进行系统对接;确定通用的数据模板及数据的颗粒度。
这里虽然说的比较少,但在对账系统中需要考虑账单的下载。如果通过接口核对则需要确定数据模板格式,以及内部对账的逻辑,每种账单可能都需要针对不同的数据进行对账,并显示对账的结果。
3. 差异处理阶段
对账的过程由于是以我司的数据为依据进行单向对账,出现差异后的处理就比较简单粗暴了。问题属于我司的数据问题,可以填写差异说明,然后提交由我司进行核对处理。
- 重新生成结算单推送至对账平台,进行对账核对;
- 通过红冲单据方式调整,保证本期的应付金额没有问题。
当商家很多、对账非常频繁时,我们首先要完善此对账前的数据准备与核对,尽可能减少我们推送到对账平台数据的错误率,此时前期我们讨论的数据核对平台的重要性就体现出来了。
对于出现的差异可能有很多,可以采用红冲单据的方式进行处理,可以增加一种对账差异调整单进行处理。对账差异调整单应该包括差异单号、差异类型、差异原因描述、差异金额、原始单据号、调整后金额等字段,这部分可以考虑与费用单据方式进行(单号与结算单号相关联)减少结算逻辑的修改。
这里需要注意的是,差异红冲单是财务对账过程新增的一种单据,对于账务上如何处理需要综合考虑,尤其是凭证集成时此部分归属哪个科目需要在设计时兼顾。
三、发票管理与核对
发票管理在应付结算流程中,当对账完成后需要供应商给我司开具增值税发票,财务应付确认是见票付款的,所以发票的管理在对账平台中是非常重要的一部分。
1. 发票金额
开票的基本信息,可以通过供应商基本信息及我司的信息提供(纳税人识别号、单位名称等),开票金额是要根据结算单(对账单)信息确定的。
发票开具的规则是,一张发票可以对应多个结算单,同时一个结算单也可以开具多张发票,这里把原来的发票与结算单的对应关系再列一下。
开票信息导出:对账平台提供开票信息导出功能,即将一个或多个结算单的开票信息(按商品汇总)导出,主要字段包括:商品编码、商品名称、商品分类、商品数量、商品金额、进项税率等关键字段。
2. 发票录入与编辑
根据发票金额在系统中录入发票信息,对应关系如上面的关系图,录入完毕后数据推送到FMS系统由财务同事审核确认。
对于发票如何开票,开票的规则是什么样,还要根据具体的财务要求进行设计。如:是否不同税率的商品可以开在同一张发票上,多个结算单是否需要按进项税率区分等等;规则不同,系统的复杂度也不同。
四、对账平台报表
以上介绍的主要是针对商家或供应商的应付对账,是围绕结算单进行的核对、差异处理、发票维护最终收款确认等。
现在商业模式很多种,像加盟店的店长分佣、社区团购中团长这种数据实时性要求比较高且金额小、用户多的场景越来越多。为了刺激销售热情,实时的销售数据和佣金提成展示是非常必要的。
汇总类数据可以在APP中进行展示,但是对于详细的数据还应该在对账平台中显示,提供给合作用户进行查看,核对。
APP中显示的实时数据主要是一种参考,不作为最终的结算依据,对账平台中的明细数据报表应该至少做到以天为维度的数据。
1. 实时汇总数据
在技术上要通过大数据的计算进行处理,原则上首先保证APP数据的生成;有数据比没有数据强,有少量异常数据不影响分析,但是要避免大的差异。
现在,很多公司都在做数据罗盘,此部分可以与其结合。
2. 对账平台的数据
要通过财务库进行汇总计算,逻辑口径与实时显示的保持一致,可以实时抽取计算;但必须保证每日零点后进行固化,此部分数据是后续财务结算数据的来源。
五、总结
财务对账平台是提供给第三方进行对账与核算的基础平台,与业务系统与财务FMS系统都相关联,对账只是其中一部分,更多的功能是将供应链的功能搭建在此平台上,使得与第三方的对接更顺畅高效。
第三方与我们的技术对接,可以通过开放平台来实现(对外开放平台是技术接口对接的开发平台,可以参考如京东的宙斯开放平台等),感谢您的阅读。
作者:倔强的大萝卜;公众号:倔强的大萝卜
本文由 @倔强的大萝卜 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议
楼主你们做的这个是开放式的嘛 可否发点资料出来看看(界面或者接口)? 我的微信wx865590195
这个目前没有对外开放,仅限于公司对应的供应商使用,对账平台可以做成SaaS,供应商结算时可以通过系统API进行系统对接,也可以导出账单自行对账,这个根据你们需求设计应该就可以。
嗯 好的 最近我们也是在计划做对账平台 所以想着参考下
🙂
应付场景的 结算对账之前,在交易层面,比如以天为单位,是不是应该还有一层对账比较好,主要是对收入账
设置一层比较好,这个可以通过数据核对平台进行内部数据的核对,相互报表间数据的验证。
感谢,要是有页面原型图片什么的就更好了,这样纯文字还是不太好理解呢
哎,我不会画原型,但我接触的后端系统更多的都是查询搜索条件+表格+操作等,好像都差不多。