在Saas类产品中，对账功能是一个拓展比较多的设计，不同企业有着不同的要求。这篇文章，我们看看作者的总结。
需求场景：
- 不同企业针对对账单的表单字段有不同的要求，如何满足不同企业用户对于对账的个性化字段诉求，包含核对本账期内发生的企业支付明细、本账期可开票结账明细、本期及往期待开票结账明细。不同的企业针对对账单字段要求不一样，全量字段提供给企业将对较多，看起来过度冗余。
- 企业不同的用途以及核对方式对账单调整、账单文件格式、账单表头、账单内容有不同的需求；
- 企业不同的核对方式和核对详细程度，关注内容不同，对账单表头要求不同。
- 账单数据准确性无法保证，导致已出账单存在字段明显错误的情况，产生客户质疑和投诉。
- 账单记账没有针对核心字段进行拦截校验，比如入账时间为空，结算金额为0等，无法保障出账数据准确；
- 账单的详情数据，在计费时持久化后，后续没有机制更新数据，但是存在部分账单字段会在计费后发生变化，比如酒店订单状态，导致离线账单字段错误，影响出账数据准确性。
解决手段：
建设表达式引擎能力，对背景进行分析，可以提取出共同点：在固定流程中，执行配置化的表达式/脚本，基于执行结果进行业务处理。
举个栗子：针对记账拦截的场景，配置拦截表达式，执行结果为校验不通过的具体错误信息，空则通过校验。
基于上述分析，我们需要建设配置化表达式引擎能力，整体能力如下图：
面临挑战：
1）账单准确率问题比如上游消息丢失、上游数据更新延迟、三费不齐问题等等；
2）账单详情数据未同步后续没有机制更新数据，存在部分账单字段会在账单落库后发生变化，比如酒店订单状态，导致离线账单字段错误，影响出账数据准确性；
3）企业个性化诉求，不同的企业针对账单要求不一样，全量账单字段提供给企业展示较多，看起来过度冗余。
- 企业不同的用途以及核对方式对账单调整、账单文件格式、账单表头、账单内容有不同的需求；
- 企业不同的核对方式和核对详细程度，关注内容不同，对账单表头要求不同。
全链路系统监控
1 背景
账单准确性存在如下情况：
1）存在接受供应链消息丢失的场景，导致订单未收单未出账；
2）账单系统存在重复计费、记账问题，导致订单无法出账，影响账单准确性；
3）新老系统切换，针对老系统已经存在预订单，其他赔付、退款等奇普无法系统化支持出账。
2 解决手段
从账单全链路监控，可以解决因为系统异步导致链路数据丢失，或者数据拆单/合单不一致的场景。
- 增加MAC监控，核对机票未入账数据、入账失败监控及计费记账金额核对监控；
- 增加pcb监控，实时监控订单、交易、人费数据；
- T+1 比对供应链订单表、账单收单表的增量订单，按照交易类型分析，对消息丢失的订单监控告警，触发补偿任务，自动重试；
- 业务上也会针对离线账单和出账数据核对、计费/记账异常数据核对，保证账单准确性100%。
我们分别从类目终态出账、账单全链路监控考虑，配合账票一致性校验来保障出账和开票链路，提供系统平账能力，针对无法自动平账的异常数据提供人工修复工具，保证账单准确性100%。
3 清结算扩展-账单数据表达式引擎
提供核心链路的扩展能力，计费/记账提供扩展能力，可以定义费用项拆分、配置费用记账规则；针对账单数据可以配置表达式引擎，针对账单字段进行校验和动态更新。
账单表达式引擎配置，解决账单数据准确性问题；
如自动化平账工具，解决账单三费不齐，账单不平的异常情况
解决手段
提供自定义表头能力，基于企业自定义表头和顺序，可以实现企业账单按照配置展示对应的字段、顺序、样式。
差错处理（平账）
差错处理主要是针对数据核对过程中发现的异常数据进行处理。我们会建立一个统一结构的差错记录，将数据核对发现的问题进行统一存储。针对自动化平常处理未通过的数据会进行二次核对，避免由于日切等原因造成的问题错报。
对于那些真实存在问题的数据我们会提供两种解决方式，如果是常见的问题，形成一套标准的解决方案，会把它系统化，采取系统修复&二次核对的方式；如果系统修复异常，那么会进行系统报警，并进行人工处理，基于此能够很大程度的降低人工修账的成本。
如何评估对账体系是否完整：
账单准确率&一次性出账率：逐步提升，已达到100%。
账单工单数：逐步收敛，降低了工单投入，提升了人效。
对账核心拓展功能设计较为复杂，本文只做了精炼概述！
