财务报表及信息化管理知识分析1.ppt
王静峥
摘 要：在信息化变革深入到各行各业的过程中，许多商业或服务业企业都开始在线上开通交易入口。大中型企业交易平台建设中，往往出现业务信息流与财务信息流不一致、业务与财务功能割裂的问题，直接导致财务部门进行交易对账、资金清算时候出现各种困难，应当以产品化思维解决相关问题。
关键词：财务; 结算; 信息化
在信息化变革深入到各行各业的过程中，许多商业或服务业企业都开始在线上开通交易入口。小企业更多选择与天猫、京东等平台商户签约，而许多大中型企业会额外搭建一套本单位的线上交易平台，承载销售、服务功能。而大中型企业交易平台建设中，往往出现业务信息流与财务信息流不一致、业务与财务功能割裂的问题，直接导致财务部门进行交易对账、资金清算时候出现各种困难。究其原因，往往是因为技术人员不熟悉财务知识、无法理解财务需求，业务部门信息处理流向单一，财务部门缺少产品部门的设计思路。
为解决信息化交易平台构建中财务模块薄弱的问题，既需要财务部门具备产品思维、有效梳理信息与资金的关系，也需要财务部门积极沟通、争取在交易平台当中融入专门的财务报表。笔者结合自身工作经验与思考，就产品思维指导下信息化交易平台的财务报表开发规范提出一系列建议。
1.定义财务信息流向
从末端的结果呈现方面分析，财务部门无非需要获取库存流转、收入、成本、资金收付、发票开收、税费核算几个方面信息，而业务交易平台在处理过程中，是按照消费、支付、退款、退换货等口径设置业务流程，与财务口径区别极大。因此，必须首先确保业务信息流规范，进而将业务信息流转换为财务信息流。
业务系统设计过程中，有一种相对简便的订单处理机制，即以流线型模式，固定生成订单的金额、商品信息、支付状态和订单处理状态，订单处理状态分为消费、退款退货等，一旦客户发起退款退货等请求，实时修改订单状态。但这种模式虽然便于交易处理，但会造成财务模块取数的巨大困难：（1）财务部门的核算是要求收入的正数发生金额与负数发生金额分别记录，避免收入确认与纳税义务混乱，而直接修改订单状态的业务处理模式会导致财务部门无法追踪收入发生与红字信息，导致收入确认与开票无合理依据;（2）交易系统如设计了主订单（一级订单）与子订单（二级订单）的模式，财务部门必须花费极大的时间成本定位资金流向与停留节点。
因此，财务部门为实现交易数据取数准确的目的，应当要求交易处理采用日志型记录模式，具体设计如下：
订单ID是交易系统自动生成的订单串号（流水号），其中同一主订单下的不同子订单共享同一主订单ID;商户类型分为自营与外接商户，通常是考虑到一些大型公司可能在搭建交易平台的时候考虑自营之外会接入第三方商户入场经营，因此会导致自营款项为平台收入、外接商户款项为平台代收代付款的情形，在业务口径可以共同作为平台交易流量，但在税法与会计口径适用不同的规定;定价与折扣金额是交易平台面向客户展示的金额，并不能作为财务结算或确认金额的依据;商品ID应当与企业自建的ERP及交易系统中SKU管理模块的信息一致;商品结算金额是并根据交易平台设置的算法确认的特定商户名下单一品类商品在订单中的总结算金额;子订单结算金额是根据子订单汇总同一商户下不同商品汇总的结算金额，作为多方分账依据;主订单结算金额是同一主订单下所有子订单结算金额，作为客户付款的依据;交易类型分为消费与退款退货，当用户消费时创建订单并标记消费，当用户退款时以SKU为基础分别标记退款退货信息，消费与退款退货作为不同的交易类型滚动发生、不得直接改写原有订单状态下交易类型记录，避免无法追溯交易转换过程。除非平台规定固定的手续费金额，否则通常在交易平台不考虑手续费，因为支付机构确认的手续费算法与平台算法不尽相同，无法完全事先确认。
需要特别注意的是，折扣金额在本质上是面向客户进行展示的金额，客户付款、订单最终价格的生成机制，可能是基于订单总金额的满减、单个商品的折扣或客户使用代金券，以上均为业务处理系统应当负责的工作，财务模块只需要要求业务处理系统根据自身算法将具体折扣金额分摊到单个SKU上即可。财务模块不应参加对折扣金额的计算、只需要获取结果，原因在于加载复杂算法将导致财务信息与业务信息混同，无法最终在多重优惠算法下核定各项优惠情况并还原为财务信息。
2.对账结算的信息流
2.1.构建交易平台与支付机构的信息流
为交易平台在完成正常的交易后结算准确，必须在订单与资金方面构建可靠的勾稽关系，主要方式是构建准确的报文机制。
交易过程中，在客户创建交易并支付时对交易平台生成的子订单不会产生感知;支付过程中也是以主订单为单位进行一次支付、不会分商户逐一付款。支付机构在受理付款请求的时候也随之以交易平台上行的支付请求信息为依据生成支付订单。
对账过程中，以银行（包括广义的第三方支付机构）为起点，分别发布对账文件、结算文件，最终送达交易平台。
交易平台在接入支付机构的同时，会根据支付机构的标准接口规范设置报文格式，此时必须要求交易平台以主订单ID为支付订单上行報文的必要字段，同时要求交易平台在实时交易结果响应的下行报文中回传主订单ID、在对账文件中同样包含主订单ID。因此，整个勾稽链条的核心是主订单ID。
2.2.对账基础数据的抓取与生成
2.2.1.数据来源
交易平台应当在接入支付机构时分析不同机构的对账文件特征。目前市场普及度最高的机构是支付宝、财付通、中国银联等机构，标准化的对账文件通常包括日期、时间戳、支付流水号、对账流水号、交易金额、手续费金额等。交易平台流水号通常不是支付机构对账文件必要的字段，但交易平台方应当作为必要字段并在接口规范中进行相应开发。
2.2.2.数据解析
不同机构的对账文件虽然核心字段类似，但具体格式千差万别，需要进行专门的数据解析，因此需要系统开发相应的功能自动清洗数据。
首先应解决对账文件的格式问题。不同的机构可能选择TXT、CSV、XLS等文件类型，在抓取数据的过程中应当注意不同的文件格式，并转化为本公司统一的文件类型。此外，文本标识符、字段精度等格式问题也应纳入考虑范围，避免汇总过程中出现异常。
其次应解决金额记录问题。支付机构的资金结算通常采取轧差结算的方式，但不同机构对账文件的记录和展示方式也不尽相同。有的机构直接以轧差后的金额作为对账文件中的结算金额（实际上类似于结算文件），有的机构在同一条记录中分别设置支付订单金额、手续费金额、结算金额对应字段，有的机构分两条记录显示同一笔支付订单对应的支付金额与手续费金额、不直接显示轧差后结算金额。
再次应解决不同的支付类型记录问题。支付机构的交易类型通常分为正常支付、冲正、退款，交易平台应当根据不同机构的对账文件格式识别支付交易的类型并进行标记。
2.2.3.数据汇总与整理
数据清理后，应当进行汇总及整理。
首先，应将不同机构的对账文件信息整理为统一格式，核心字段包括
其次，补足信息缺口。必要的对账文件要素应包括日期、时间、交易流水号、支付流水号、对账流水号、支付订单金额、手续费金额、轧差结算金额。信息缺口主要在金额字段，需要将要素不全的对账文件信息进行还原，可以提取交易日志的支付请求金额补足支付订单金额字段，轧差结算金额字段可能可以从对账文件直接提取、也可能通过支付订单金额与手續费金额添加算法进行计算。
再次，标记对账文件来源。交易平台在接入多个支付机构的情况下，应当分别为每条记录标记交易的对手机构。
3.对账机制及结果呈现
因为支付机构的对账结果代表了最终的资金流向，是对账的总体原则是以对账文件为准、以支付机构为对账起点。
交易平台应提供日期、主订单ID、支付请求金额，对账文件应提供支付机构名称、日期、时间、交易流水号、支付流水号、对账流水号、支付订单金额、手续费金额、轧差结算金额。最终形成的对账文件应包括对账通过、银行多账、银行少账三部分。
银行多账通常表明交易平台因出现掉单、支付机构成功响应超时或其他原因漏记交易，导致交易平台未生成成功交易订单、但客户资金已成功划扣并将参加结算，因此需要在交易平台后台查询原始记录，为客户办理退款或补发货。针对银行多账交易，应当为财务部门展示为预收款项。
银行少账是另一种单边账形式，通常是支付机构失败响应超时、实时冲正交易失败等原因导致支付失败，而交易平台错误记录支付结果、标记交易成功，进而向客户办理发货。这种情况下应当及时联系客户办理补缴款或收回商品。针对银行少账交易，应当为财务部门展示为应收款项和发出商品。
4.资金结算
4.1.支付机构结算
支付机构的资金结算严格按照对账文件的数据进行，对企业而言包括对账通过部分的资金以及银行多账部分的资金。通常的结算周期为T+1工作日，即第二个工作日结算前一日或多日（节假日）发生的交易款项。财务人员应当及时根据报表数据与银行到账金额进行核对，确认收款信息。
4.2.分账机制及结算资金流
交易平台在完成与支付机构的对账后，即应进行平台商户间的分账及结算。分账机制以订单SKU记录的商品结算金额为基础，对对账通过及银行多账且客户认可补发货的订单进行清算。
具体原则是：（1）以交易平台生成的数据为准、按商户（平台自营作为自营商户）进行清算;（2）不考虑对客户的展示价格及折扣，以客户付款金额进行结算;（3）交易平台不得轧差结算资金、避免坐扣平台手续费。
交易平台向商户出具账单后，经平台与商户对账确认后即可进行资金结算;商户应向交易平台支付手续费、由交易平台方向商户开具手续费发票。
5.财务口径下的报表展示
5.1.对账结算表
对账结算表用于交易平台面向支付机构、商户进行对账和结算。
5.2.应收汇总表与应付清分表
汇总表通常在宏观层面汇总企业在特定期间向支付机构应收的金额，可作为财务部门汇总记账凭证的依据。
5.3.收入、成本展示
针对交易平台方自营的商品或服务，可以以适当形式汇总收入、库存结转成本、退货等信息，并作为财务部门核算的基础。但应注意与企业ERP系统保持一致、定期核对。
6.特殊情况分析
6.1.实时交易的中间状态
在客户提交交易订单并发起支付后，支付机构与交易平台直接可能因单方系统内部超时或系统间交互超时，导致交易平台没有收到支付机构对支付结果的响应，交易平台无法确认支付结果是成功或失败。
此时，交易系统应设置针对响应超时的应对机制，及时挂起中间状态交易，并告知客户等待处理结果。通常在次日支付机构发布的对账文件中会确认该笔交易对应的支付订单对账结果，以对账文件为准，如果对账文件包含该笔支付记录、明确资金参加结算，则应告知客户补发货，否则该笔交易订单标记失败，财务系统中不对其进行任何处理。
6.2.支付冲正交易
支付冲正交易是支付机构在成功通知客户划扣成功后，实时回退扣款、将资金退回客户账户的操作。与退款交易不同，退款交易通常是交易方发起、支付机构被动受理将款项退回客户账户的操作，发生在原交易成功完成、资金参加结算的情况下。冲正交易不会发生真实的资金往来，仅仅是在成功交易之后由支付机构主动发起一笔撤销交易。在对账文件中，有可能原始交易与撤销交易同时记录，也可能完全不记录两笔交易，交易平台在解析对账文件的过程中应当予以特别注意。
6.3.系统日切时间差异
国内的银行机构系统日切时间为每日23时，而大部分普通企业的系统日切时间为每日24时。在每日23时至24时之间发生的交易会被交易平台记录为当日、被银行系统记录为次日，因此可能导致跨日单边账，交易系统对账结果显示为前一日银行少账、后一日银行多账。交易平台应当在接入支付机构时关注对方的日切时间，针对日切差异期间发生的交易进行特殊处置或短时间暂停交易。
目前，第三方支付机构通常采取正常交易机构垫资、非正常交易一概退回的形式，将日切时间强制调整为每日24时，故此交易平台不需要进行特殊处理。
6.4.客户扣款但机构未退款
在某些极端情况下，有可能实时交易过程中已经成功扣款，但次日对账文件并未包含相关交易、资金未正常结算的情况。出现这种情况的原因是客户作为持卡人，在支付过程中发卡机构、转接机构、收单机构分别为不同机构，交易过程中发卡机构成功扣款的结果因通讯故障或系统时间差异等原因，导致支付参与方记录出现错误，最终资金流与信息流出现差异。
这是一种比较极端的情况，无法通过常规渠道处理，除非相关机构查询磁盘信息并进行对账。因此当客户明确提供支付凭证后，交易平台应当发货，但因无法正常收款，因此财务上通常需要确认损失。
