一、背景

接手账单不到1年的时间，就谈谈我从一个门外汉到账单系统搭建过程中对于账单系统架构设计的理解。

账单基于上游供应链交易数据，需要上游数据准确可信，建立资金、交易、订单及账单核对体系必不可少；其次需要建立账单数据、票据维度数据，保证对客数据准确，这里的复杂性在于不同的企业需要提供不同维度的聚合数据、账单汇总数据、账单差异明细（商旅火车票票状态、出差事由等），账期日要求全部企业系统自动完成对账出账，系统需要支持的复杂性、扩展性较大，系统的高度复杂性也给对账出账的准确、及时造成了极大的困难，很难保证一次出账率100%和账单准确率100%。

二、无处不在的账单

对账、账单在我们生活中到处可见的，可能自己没有察觉已经完成了一次对账过程，生活中对账场景比比皆是，我们来看看：

2.1 生活中的对账场景

举个例子：早上上班途中，小周看到路边有个杂粮煎饼，于是过去买个煎饼，老板指着玻璃上的二维码说「12块」。

小周扫码支付12元后，和老板说「12块，转过去啦」，紧接着老板煎饼递给小周，听到自己手机提醒说「支付宝收款：12元。」

老板心里知道这笔钱到账了，小周知道「已付12元」，老板收款确认「已收12元」，这就是生活中的对账。

2.2 对账的基本形式

对账定义：为了确保同一个事务的数据描述在不同场景，记录是否一致而进行的一致性比对。

举个例子：对于面馆老板，顾客吃了一碗面，点菜小票就是原始凭【证】，付了10元钱是【账】，老板电脑点菜记录小票10元是【账】，老板账户中余额增加10元是【实物】。

• 账实对账：是指我们记录的账与实物资产的实际数量进行对账。

• 账证对账：是指将自己的账本与记账凭证进行核对。一般记账凭证由与业务合作的第三方公司提供，在面馆的例子里，记账凭证由支付宝提供（交易记录）。

• 账账对账：是指在上下游相互关联的账本之间进行对账。在整个交易过程中，一般会涉及上下游多套账，上游比如外部采购、对外销售，下游比如快递发货账、第三方服务费等。这些账和总账之间有非常多的关联性，所以一般账账核对，通常用于确认及修正内部账之前的数据不一致。

三、账单系统设计

账单清结算做为核心账单系统，上游对接了机票、酒店、用车、火车、赔付等多个外部系统，下游又承担了对接支付、财务、发票系统的职责，不仅“承上启下”，而且涉及业务复杂。系统内部又有收单、计费、记账、汇总账单、付款等多个环节，如图：

为了账单系统更加专业化的实现对账、做好对账出账，我对支付、清结算等资金领域进行了体系化的调研和学习，并结合商旅业务自身的特点，总结了一些账单系统构建的思路方法，并基于该思路进行了较完整的系统化实现，主要从体系化建设出发一起来看看账单系统架构设计。

• 收单：监听供应链订单消息，创建账单清结算系统收单消息；

• 计费：针对机票、酒店、火车票、用车类目收单消息，拆分最细粒度费用项（预定/退款、改签/退款、保险/退保、服务费、赔付等等）费用明细，便于后期账单数据加工；

• 记账：按照当前业务规则合并账单明细，支持to b差异化配置；

• 入账：核对供应链数据、资金数据一致性，配置入账拦截；

• 出账：账期日企业账单出账，允许企业自定义账单出账，满足企业差异化、个性化账单；

• 对账&还款：企业根据对账单核对明细，根据账单进行还款；

3.1 收单

在账单收单时，我们可以针对不同的业务接入方提供两种不同的数据收单模式：

拉模式：我们主动调用获取数据，并通过数据适配的方式，将数据进行存储。

针对性强，能满足客户端的个性化、差异化需求；

推模式：根据业务需要，接入方将账单数据信息主动发送，数据格式按照账单标准模型进行适配。

及时性好，及时地向账单推送数据动态信息，吞吐量大；

目前我们采用的是第二种方式，由业务方推送这种模式接入，按照账单标准模型构造，无需感知业务的数据格式和业务逻辑。

3.2 计费&记账

我们需要将各个类目的交易记录统一定义，按照账单记账的标准规则记录。

系统使用计费拆分项为起点，拆分最细粒度费用项（预定/退款、改签/退款、保险/退保、服务费、赔付等等）费用明细，便于后期账单数据加工；记账按照业务规则进行计费项合并。对于冗余和暂时用不到的字段可直接设置账单暂不进行展示。未来扩展时，账单允许企业自定义，按照企业诉求展示账单字段和数据展示。（自定义账单，后文会介绍到）

3.3 对账

企业对账作为企业差旅管理的一个重要环节和基础能力，账单准确性是基本的要求。

商旅账单是企业还款、开票核对的重要依据。账单准确性差，可能会导致商旅在结算、开票环节产生资损，以及影响企业对商旅的专业度的信任，因此要求账单信息完整、准确、真实。账单准确性至关重要，我们需要保证给企业的账单真实准确，所以系统对账的设计重要性无庸置疑。

以下我们通过对账的一些手段、方法来看看系统性的解决账单对账问题。

对账方式主要分为三种，单向对账、双向对账和多向对账。

3.3.1 对账方式

• 单向对账：以一方数据为基准进行对账。比如交易订单跟资金记录，以资金结算数据为基准和交易订单核对，用来发现资金数据为支付成功，订单数据失败等异常情况。

• 双向对账：以双方的数据互为基准对账。既要保证资金数据为成功的，交易记录也要成功，又要保证交易记录为成功的，资金数据也要成功。

• 多向对账：让更多参与方两两对账，比如交易订单、资金记录、账单等两两对账，保证交易记录成功的，资金也要成功，账单数据也正常。

显而易见，多向对账更能够全面的发现问题。因此在条件允许的情况下，我们会优先选择多向对账。

3.3.2 对账粒度

对账粒度分为两种，分别是总数对账和明细对账。

• 总数对账：选择一个维度，进行总数级别的对账。比如账期账单消费总数和账期资金记录总数对比，总数级别的对账好处是对账口径的设计比较简单，可以快速实现，不易出错。缺点就是无法定位问题数据，一旦对账发现问题。还需要进一步寻找问题数据。

• 明细对账：对双方的每条数据按照业务规则依次进行比对。它的优点是可以准确定位问题数据。缺点是对账口径的设计比较复杂，效率比较低。因为我们需要同时针对漏、重、错三种错误类别设计出较为全面的对账口径，同时还要考虑到业务的边缘场景。稍有不慎，就会影响对账的准确性。

  

  因此，推荐的做法应该是以总数对账为主，首先确认是否存在问题。以明细对账为辅，对具体问题进行定位。

3.3.3 对账模型

我们会提供常用的对账模型，供不同的对账场景选取。如果某些特殊场景对账模型不能覆盖，也可以采用自定义核对的方式进行对账。经过总结我们发现，对账的方式主要就是业务通用规则、多方对比和账单规则。业务通用规则，比如交易对账、资金对账、采销对账等多个常用维度。多方比对又可以细分为一对一、多对一、多对多。账单规则就是常用的计费项核对、记账核对和允许自定义核对等方式。我们尽可能把这些通用的对账逻辑模型化，减少重复的开发工作。工作。

3.3.4 对账节点

数据核对的最后一步就是对账节点的选择。可以分为离线对账和实时对账。离线对账主要是通过固定的周期进行对账，周期可以为Ｔ＋n，也可以通过出账日对账，它的好处是适用性较强，基本可以覆盖所有的对账场景。系统目前都是针对一定时间之前的订单进行核对，保证交易、资金、账单数据准确一致；在出账日出账时也会针对企业维度核对当前账期所有交易记录数据和账单数据一致性。对账节点核对目前有每日核对、账期日前一天核对、出账日核对。

实时对账又分为实时对账和准实时对账。实时对账和准实时对账的区别主要是实时对账针对结算链路中，可以第一时间发现问题数据，对结算流程进行实时监控，而准实时对账是具有一定的延后，因为交易链路存在较长的情况，上下游数据无法做到实时一致，有些场景只能做到最终一致性，这些场景目前只能基于准实时进行对账，也可以有效的针对业务问题和账单异常进行告警。

3.3.5 差错处理（平账）

差错处理主要是针对数据核对过程中发现的异常数据进行处理。我们会建立一个统一结构的差错记录，将数据核对发现的问题进行统一存储。针对自动化平常处理未通过的数据会进行二次核对，避免由于日切等原因造成的问题错报。对于那些真实存在问题的数据我们会提供两种解决方式，如果是常见的问题，形成一套标准的解决方案，会把它系统化，采取系统修复&二次核对的方式；如果系统修复异常，那么会进行系统报警，并进行人工处理，基于此能够很大程度的降低人工修账的成本。

四、系统设计关键点

4.1 面临的挑战

• 账单准确率问题，比如上游消息丢失、上游数据更新延迟、三费不齐问题等等；

• 账单详情数据未同步，后续没有机制更新数据，存在部分账单字段会在账单落库后发生变化，比如酒店订单状态，导致离线账单字段错误，影响出账数据准确性；

• 企业个性化诉求，不同的企业针对账单要求不一样，全量账单字段提供给企业展示较多，看起来过度冗余；

  • 企业不同的用途以及核对方式对账单调整、账单文件格式、账单表头、账单内容有不同的需求；

  • 企业不同的核对方式和核对详细程度，关注内容不同，对账单表头要求不同。

4.2 全链路系统监控

4.2.1 背景

账单准确性存在如下情况：

1. 存在接受供应链消息丢失的场景，导致订单未收单未出账；

2. 账单系统存在重复计费、记账问题，导致订单无法出账，影响账单准确性；

3. 新老系统切换，针对老系统已经存在预订单，其他赔付、退款等奇普无法系统化支持出账。

4.2.2 解决手段

从账单全链路监控，可以解决因为系统异步导致链路数据丢失，或者数据拆单/合单不一致的场景。

• 增加MAC监控，核对机票未入账数据、入账失败监控及计费记账金额核对监控；

• 增加pcb监控，实时监控订单、交易、人费数据；

• T+1 比对供应链订单表、账单收单表的增量订单，按照交易类型分析，对消息丢失的订单监控告警，触发补偿任务，自动重试；

• 业务上也会针对离线账单和出账数据核对、计费/记账异常数据核对，保证账单准确性100%。

  

  我们分别从类目终态出账、账单全链路监控考虑，配合账票一致性校验来保障出账和开票链路，提供系统平账能力，针对无法自动平账的异常数据提供人工修复工具，保证账单准确性100%。

  

  4.3 清结算扩展-账单数据表达式引擎

提供核心链路的扩展能力，计费/记账提供扩展能力，可以定义费用项拆分、配置费用记账规则；针对账单数据可以配置表达式引擎，针对账单字段进行校验和动态更新。

4.3.1 背景

账单数据准确性无法保证，导致已出账单存在字段明显错误的情况，产生客户质疑和投诉。

• 账单记账没有针对核心字段进行拦截校验，比如入账时间为空，结算金额为0等，无法保障出账数据准确。

• 账单的详情数据，在计费时持久化后，后续没有机制更新数据，但是存在部分账单字段会在计费后发生变化，比如酒店订单状态，导致离线账单字段错误，影响出账数据准确性。

4.3.2 解决手段

建设表达式引擎能力，对背景进行分析，可以提取出共同点：在固定流程中，执行配置化的表达式/脚本，基于执行结果进行业务处理；

举个栗子：针对记账拦截的场景，配置拦截表达式，执行结果为校验不通过的具体错误信息，空则通过校验；

基于上述分析，我们需要建设配置化表达式引擎能力，整体能力如下图：

4.4 自定义账单

4.4.1 背景

对账单是阿里商旅提供给企业客户对账用的，用于企业与阿里商旅核对企业支付的账单，包含核对本账期内发生的企业支付明细、本账期可开票结账明细、本期及往期待开票结账明细。不同的企业针对对账单字段要求不一样，全量字段提供给企业将对较多，看起来过度冗余。

• 企业不同的用途以及核对方式对账单调整、账单文件格式、账单表头、账单内容有不同的需求。

• 企业不同的核对方式和核对详细程度，关注内容不同，对账单表头要求不同。

4.4.2 解决手段

提供自定义表头能力，基于企业自定义表头和顺序，可以实现企业账单按照配置展示对应的字段、顺序、样式。

• 拆分处理器

根据拆分设置，分为Excel拆分处理器、sheet页处理器、行处理器。

拆分处理器可以定义拆多少个Excel，PDF和每个Excel中需要有哪几个sheet页，每个sheet页种每一列的样式。每一种处理器都有默认的实现方式，且允许自定义扩展实现。针对常用的样式提供了账单模板，审批单模板等常用的模板，方便快捷接入。

五、建设下一代账单系统

商旅账单系统重构已有半年多时间(业务流程改造和架构升级)，很多技术优化也是在业务发展过程中尝试扩展能力，如账单表达式引擎配置，解决账单数据准确性问题；如自动化平账工具，解决账单三费不齐，账单不平的异常情况。目前账单针对账单核心清结算主要是夯实底层能力，基于计费&记账进行扩展，允许企业自定义账单，接下来是针对账票核对能力建设，更多的针对账票易用性能力进行升级。

5.1 业务结果

随着账单稳定和底层夯实，目前已经实现了系统一次性出账率100%，账单准确率100%，账单工单问题大幅收敛。

账单准确率&一次性出账率：逐步提升，已达到100%。

账单工单数：逐步收敛，降低了工单投入，提升了人效。

5.2 未来展望

账单一目了然，客户对账高效方便，让客户的商旅服务更加专业化。

• 建设账票核对能力：行业独有的账票核对功能，完善实物票据与账单核对、增值税发票与账单核对，保证提供给客户的实物票据真实准确。目前没有一家在行业内实现此能力，并解决客户账票不一致的核对问题；

• 提升账票易用性：通过易用性在商旅行业内达到服务效率第一，并可将部分能力专利化甚至商业化。