支付完成以后需要进行履约结算，那么如何设计一个结算系统？结算的流程是什么样的？不同场景的结算系统设计有什么区别？本文结合7个真实的案例，与大家探讨结算系统的设计方法，希望对你有所启发。

　　支付完成以后进行履约，履约完成以后就需要清算各方利益并最终进行结算；清结算体系与支付体系并行是支付范畴另一个非常庞大的体系。

　　其中的结算就是根据债权债务关系，进行最终资金交付的过程，可以将需要收客户的钱收进来，也可以将企业的钱支付给客户，结算系统就是对这个过程进行管理的系统。

　　就比如，每个月公司要给员工结算工资；陈老师在京东开了一个店铺，定期京东需要给我结算货款；你请了一个保姆，每个月要给阿姨结算服务费，企业采购了一批设备要给供货商结算货款等等，这些结算场景我们并不陌生。

　　但是怎么设计一个结算系统？结算的流程是什么样的？不同场景的结算系统设计有什么区别？在整个结算系统的设计过程中我们还要去要思考下面这些问题：

　　结算所依赖的数据的来源，就是结算系统以什么数据为依据生成结算单据，比如可以以订单数据为依据，可以以账务数据为依据，可以以人工提交的结算数据为依据，来做为应收应付的来源数据。

　　结算给谁，结算对象的基本信息以及结算收款卡信息等等，往往并不会存储在结算系统，而是存储在其他系统中，所以需要建立结算系统与其他信息系统的联系，以获得结算需要的基本信息。

　　有了结算数据以后，那么结算系统的核心单据“结算单”如何设计，有哪些结算单的类型，每种结算单的具体内容有哪些，每种结算类型的结算流程是什么。

　　结算过程还需要考虑是否需要基于结算单做税务的处理、发票的匹配、以及与内部出入库验收单等等进行核销或者匹配校验。

　　结算单最终要发起付款处理，结算单跟付款单之间的关系要规划好，另外就是结算单到付款单整个正逆向流程的设计。

　　结算了多少钱，什么时候结算的，结算到哪里了，结算了哪些债务或者债权，需要提供结算相关的账单给到客户，账单里要列明商家关。同样还需要考虑账单如何提供给客户，是否邮件、系统内自主下载还是接口接入下载。

　　下面我们将通过过几个真实案例给大家展示结算系统的设计方法，从这些不同场景下的结算系统设计案例，我相信大家可以深刻的体会到——哦，原来如此！

　　我想大家在公司都收到过一些消费券或者购物卡，有时候还指定消费场所或者平台，这就是企业的员工福利了，而企业发放福利的成本是可以用以抵扣所得税。

　　国税总局《企业所得税法》相关条例，企业福利员工薪酬的14%，工会福利员工薪酬的2%，教育经费员工薪酬的8%，可以免征企业所得税。

　　但是，企业的福利管理如果单单企业自己从采购商品、制定各种卡或者券，管理和监控员工的使用等事务是相当繁琐的，这样，针对这样的企业需求场景，企业福利平台就营运而生了。

　　企业福利平台以合规税筹为基本，在经营范围允许的基础上，以多账户支付体系为核心，为企业提供企业福利和税优解决方案，实现B2B2C业务从预算到核算的管理闭环。

　　福利平台的业务模式是这样的，企业购买平台福利产品（签采购合同），以虚拟户的方式充值到企业账户，企业以积分或额度或者卡的方式发放给员工，平台根据企业购买的福利产品给员工配置消费通路，员工在c端进行消费，平台从中赚取平台服务费或商品利润。

　　根据以上场景描述，企业福利结算中心分为企业（客户）结算和商家结算，来阐述企业结算系统（以企业集采为例）。

　　B端业务，多为销售和企业签订销售合同然后在销售系统下单，销售系统把相关信息传给结算中心，结算中心为销售系统提供收款、开票和财务入账服务。

　　商家结算-应付，员工消费/兑换商品后，产生交易单，交易单匹配费用规则请求清算至商家账户，商家根据具体结算周期在商家系统发起结算，具体结算流程如下：

　　收款管理，提供收款单查询，记录外部收款流水，记录收款核销详情，是后续与外部资金系统对账、与开票数据进行对账的依据。

　　收款发票核销：由于收款和发票都是关联在结算单上，一个结算单会对应多个收款记录，也可能会对应多个发票记录，固发票和收款会是多对多的关系，为了方便财务入账（此流程可根据公司具体财务需求），建立了发票和收款核销流程。

　　提供针对结算中心的业务实绩，根据业务场景实际需要，定期与相关业务系统对账，同时可提供查询或下载相关业务交易明细，供相关方对账核对。

　　在政务服务领域中，终端机作为政务服务的重要承载体之一，被广泛运用在各个服务大厅。作为政务服务服务企业，会随项目而起定期向供应商采购终端机。

　　终端机的采购流程，先由项目经理在经营管理系统中填写采购合同，经过审批、采购、验收，最后入库，便可以批准供应商的发票支付款项。

　　有了终端机，运维那是必不可少的。对于终端机较多的区域，部分运维工作是直接外包给其他公司。但有部分地区的终端机较少或者分布较散，这种情况会将运维工作外包给个人。

　　运维工单的发起一般分3种场景：固定的定期检查工单；市民扫码填写提交的报障工单；以及终端机的运维监控系统推送的终端机异常工单。

　　当终端机采购入库并验收之后，采购订单则会更新订单状态已完成。由于这类项目的周期较长，回款较慢，因此一般以采购结束后3个月为周期对供应商款项进行结算，所以系统会根据采购订单的状态自动记录结算时间，生成结算账单。

　　维修工单由区域项目经理在工单系统审核通过后创建维修单，派单给该外包公司或者个人前去维修，验收通过后则生成结算单。

　　结算单生成由供应商开发票，在系统中发起结算生成结算单（结算单必须包括合同、发票、验收单、入库单），再推送到财务系统通过财务打款。如果是个人外包，则通过代付通道一月一结给服务方。

　　结算配置：对不同的结算对象进行不同结算规则的配置，如供应商结算、运维外包个人结算、运维外包企业结算等，以供结算单模块根据需要生成账单。

　　计算系统的主要单据是结算单，财务中心根据审核通过的结算单进行款项结算，结算完成的账单将流入账单模块。

　　对于终端机采购合同，当合同进入采购流程之日起计算，往后推三个月的日期为“原定付款日”，一般情况下，“原定付款日”与“实付日期”是一致的。当特殊情况下，如终端机审核不通过需重新验收或者在运输过程中出现延误等情况需要修改付款日期则“最新付款日”与“实收付款日”一致。

　　对于运维外包，会定期对个人或企业已通过验收的工单做周期结算，生成结算单。若外包企业或外包个人需提前作结算，可在系统中发起结算单申请，由相关人员审批通过生成结算单。同样，针对这类情况，“原定付款日”为合同中的日期，“最新付款日”与“实付款日”一致。当结算单审核成功扭转到账单模块且打款成功，接口返回“实付款日”并结算单状态变为“已完成”。

　　结算规则包括ID、结算单类型、结算对象、结算周期、结算方式、创建时间。个人与企业的结算方式不同，结算给个人一般不用发票，走代付通道。而企业则需要上传发票到系统进行审核，最后银行打款。

　　结算单与结算规则：通过结算单类型来进行匹配，再确定结算对象是个人还是企业，最后通过不同的结算方式来生成不同的结算单。

　　分销推广行业，大家听起来可能比较陌生，但或多或少都有接触过。互联网刚兴起时大学校园里和大街小巷的APP拉新见过不少吧，经久不衰的地推模式，以及现在网上五花八门各种形式的网推大讯云机场 clash，这就是分销推广行业的线上线下营销组合拳。

　　别看这个行业好像挺少见，专业分销推广玩家赚的真不少，现在市面上就有许多聚合推广平台，左手引项目，右手拉代理，年收入百万不成问题。

　　假设我方是一个叫“推光光”的聚合推广平台，对接引入了高速ETC、POS机、信用卡、养老金账户4个项目可供推广，平台有3位拓展专员负责发展、培训种子代理，再由种子代理去帮平台推广项目或者发展下级让下级去推广。

　　对拓展专员结算：抛开工资，我们跟拓展专员要结算的主要是绩效，而绩效的多少则与他所服务的种子代理质量挂钩。

　　种子代理的质量如何评估，单纯地按业绩粗暴地计算太过简单了，不利于平台的可持续发展。为了激励拓展专员更好地培养和扶持种子代理，除了看代理的业绩总数外，可以从这几个维度去评判，如新增团队人员数量、团队出单总数、团队人均出单数、团队有效代理数等。

　　对种子代理结算：种子代理的合作模式主要有2种，一种是直接拿一个底价假设100元，然后放给下级更低的价格90元，中间吃差价10元。此外就是跟平台对赌，100元直接平放给下级，然后达到某个条件平台给额外奖励，反之惩罚，具体看商务合作模式。

　　由此延伸出种子代理的结算款项也分2种，一种是下级们做单出业绩种子代理的差价分润，另一种则是基于某个条件平台给予的奖励。

　　对普通下级代理结算：对于普通下级代理，最主要结算的钱就是出单的佣金，而且结算到账要快，让他们“有实感有快感”。

　　像ETC和POS机这一类项目的推广，是离不开硬件设备的，因此有些代理为了现场推广，或是对库存和发货有一套标注要求，往往会从平台交押金“拿货”。

　　业务起始于拓展专员发展出种子代理，并为其配置对应的产品权限之后，种子代理即可去发展下级和进行营销推广。

　　代理营销推广之前如要拿硬件设备，则先交纳对应的押金，获取拿货额度，然后提交拿货申请，则扣减拿货额度。

　　拿到货之后正式开始展业，根据产品不同，每成交一单，则会给佣金账户结算入账一单的钱，对应上级也会收到差价分润。代理所属的拓展专员也相应新增一单业绩记录。但是这里有一个特殊场景，既有时候这个结算是会增加某些限制条件，比如你需要保证高速ETC推广的车辆的真实性，因此对订单可能有一个审核机制，审核通过才会结算入账。

　　结算的时效也有不同，有的代理走个人结算，因此秒结算到佣金账户，随时可以提现到个人银行卡，走代付通道。而有的代理是走企业开票结算，就不能自主提现了。

　　结算模块本身不是很复杂，主要是约束好结算的规则和生成对应的结算账单。但是他依赖的上游系统比较多，数据也比较杂。

　　根据不同的角色要结算的内容不同，结算单据的设计也有所不同，但还是能抽离出部分公共字段，如结算单号，结算对象、结算时间、结算类型和结算金额。

　　再根据不同的结算类型，定义所需的不同结算内容，最终根据结算对象和内容结算., 到虚拟户后自行提现或者是进行打款。

　　由于代理数量众多，实际运营不可能每新增一个代理就多一条结算规则，几千上万个代理会让运营人员崩溃，因此结算规则的设计最好把”结算对象”转移至渠道代理系统，由代理系统的每一个代理来关联结算规则。

　　这样做的好处是我只需要配置一条通用的规则，代理注册进来的时候默认关联该规则。此后如有特殊代理，再由市场端提申请给运营端进行修改配置即可。

　　银行收单业务大家都不陌生，就是待商户收款，并结算给商户。那么这个过程中有一个非常重要的环节，就是商户结算。

　　结算，顾名思义是指收单系统对前一个结算周期内商户产生的交易的轧差汇总，进而产生一笔结算单，最终通过银行核心系统或者人行二代支付系统等渠道将款项打款给商家。

　　结算是收单过程中最后一环，也是最重要的一环。结算的金额不准确或到账时间不及时，轻者会给商家带来不必要的麻烦，重者可能会引起客户投诉，影响到银行声誉。

　　商户基本户：该账户是虚拟账户，在银行核心系统中不存在，仅仅是收单系统的登记簿，在商户入网成功后自动生成的。收单系统除了商户基本户外，还有商户待清算、待结算、已结算账户，这类账户从属于收单系统，用于支付、退款等场景的清分记账。

　　商户结算账户：商户携带个人或者企业相关证件去银行柜面开立的银行账户。当商户类型是个体工商户时，结算账户一般是指个人的银行卡，当商户类型是企业时，结算账户是指企业的对公账户。

　　商户入网时一般要求开立本行结算账户。如果商户选择打款至结算账户，收单系统会调用本行核心系统进行打款。当结算单比较多的情况下，一般会调用核心批量打款接口，待核心系统处理完毕后再根据核心处理结果更新收单系统结算单状态。

　　由于某些场景需要会选择打款至商户基本户，再通过提现方式提款。一般对接外部平台时，银行为了资金沉淀，获取低成本的存款，同时平台为了获取协议存款利率，要选择该种结算方式。

　　根据结算单通过调用核心系统将结算金额打款至银行监管账户（银行内部户），此时每个商户可以看到自己的基本户有相应的余额，所有商户的余额总和与银行监管账户余额一致。最后系统通过自动提现或者商户手动提现的方式将余额里的钱从监管账户提出。

　　银行开展收单业务，为了获取低成本的存款，一般要求商户使用本行的银行账户进行入网。为了满足不同的场景需求，收单系统一般支持两种结算方式，一种是直接结算到商户的银行账户，另外一种是结算至商户的基本户，再通过自动提现或者商户手动提现的方式将基本户余额提现至绑定的银行账户。无论哪种结算方式，都需要先生成结算单。

　　收单系统中的结算设置主要是提供给运营人员配置商户结算规则的。结算规则包括商户收款开户行的相关信息、结算周期信息、结算类型信息、结算打款方式、最小/最大结算金额、留存金额等内容。

　　结算周期设置，系统支持T+0、T+1、T+N、D+0、D+1，支持节假日结算。每种结算周期对应不同的应用场景，为了留住优质商户一般会采取T+0或者D+0，为了平台型商户的资金留存，一般采用T+N的结算周期。

　　结算打款方式设置，支持打款至商户结算账户或打款至商户基本户，后再通过提现方式将基本户里的余额再提现至商户结算账户。

　　最小/最大结算金额设置，当商户当日的结算金额小于设定的最小结算金额时，当日系统不自动生成结算单，金额累计至下一日，当某日累计金额达到最小结算金额时才参与结算。当商户当日的结算金额大于设定的最大结算金额时，当日系统生成的结算单会标记为红色对结算人员进行提醒。

　　在到达设定的商户结算周期时，系统会自动生成商户的汇总结算单，运营人员可根据商户、单号、时间等信息进行结算单查询，可查看汇总结算单中的结算明细数据，如果发现结算的明细数据中存在有疑问的订单，可将订单设置为存疑状态，存疑状态的订单将不参与本期结算。

　　对于生成的结算单如果不存在其他问题，则由运营人员进行审核，结算单审核后系统根据商户结算规则设置中的结算方式打款。

　　项目为平台型的积分电商系统，商家可入驻到平台进行线上线下同步商品销售，用户可以通过到店自取、第三方本地配送和物流配送等方式完成商品购买。

　　商家在平台填写入网信息审核成功后，将会在第三方支付平台和自有系统内开通结算账户，订单支付成功账户将记录冻结金额，当订单确认收货时，订单履约系统将会请求清算系统将本笔订单的实际支付金额和积分抵扣部分扣除退款金额分摊计算，并生成清算账单，账单内将会记录商家现金结算账户金额、营销补贴账户金额和平台抽佣金额。

　　在出账单后商家可以选择账单发起提现或等待系统自动推送至结算系统，结算系统内会进行一次对账，核对账单金额是否有误；审核成功后系统将账单所对应的订单号分别请求第三方平台分账和代付接口，扣除佣金后金额分别结算商家，在T+1日最终金额结算至商家银行卡/对公账户。

　　系统生成账单后即可发起结算，第三方每日下午15:00推送央行结算，系统需要在每日下午14:00前分批推送订单至第三方，金额将在T+1日到达商家银行卡/对公账户，第三方返回结算成功后，平台将结算单和账单执行变更状态为已结算。

　　结算单根据商家主动发起账单提现或系统自动执行账单提现而生成，结算单内包含结算方式（实付-分账，积分抵扣-代付），实付部分的佣金结算至平台账户，积分抵扣部分为平台营销补差，佣金平台记录为虚拟金额，扣除该部分剩余为需要补贴商家金额，通过代付结算至商家账户。

　　自1996年首都机场高速公路进行ETC试验以来，高速ETC在我国已有27年历史了。早期推广的时候ETC卡还是先充值后通行的储值卡，就像地铁卡公交卡一样，不够钱无法通行ETC。现在比较常见的大部分都是先通行后扣款的记账卡了，除了历史遗留的储值卡和广东还有少部分针对港澳车辆办理的储值卡。

　　那么对于主推记账卡的发行企业来说，主要结算的大款项就是ETC通行费用，结算的规则也因合作而异。

　　结算周期不同：有的要求D0结算，当天的通行文件当天结算并打款，有的D1甚至可以T1结算，当天的通行文件可以第二天甚至第二个工作日结算并打款。

　　垫资模式不同：常规的合作方都要求全量通行账单结算回款，无论发行企业是否能正常扣到用户的款，少部分合作方愿意按实际扣款成功后再结算通行费用，但是也有一定的时间限制以及需要有兜底方案。

　　结算方式不同：因为ETC通行费用是存在“ETC退费”情况（ETC退费，指的是由于各种原因如优惠政策，需要给用户退钱），因此除了通行账单，还有退费账单。这种情况一般都是进行净额结算，即通行费用和退费费用轧差之后再结算给合作方。但也有的合作方追求“收支分离”，因此需要全额结算，退费部分再单独结算。

　　结算业务不同：有的合作方需要不同的项目组（如客车、货车；停车、高速、轮渡等）分开结算，有些则一笔结算即可。

　　用户ETC通行之后，每日通行账单模块会定时去合作方的FTP获取ETC账单，获取到账单后解析关联匹配对应的车辆，创建账单向用户发起路费扣款，扣款失败或有特殊费用，则请求清算计费入账到对应账户。

　　接着高速ETC结算系统会根据不同合作方配置的结算规则，统计生成对应的通行结算账单，并把结算账单推送给打款中心，由打款中心负责完成最终的出款。由于通行费账单金额比较高，不建议采用高自动化打款，采用人为发起打款申请，再复核审批后打款为宜。

　　ETC结算配置：提供针对不同合作方，进行不同结算规则的配置的能力，如结算周期、是否区分业务线、净额结算还是全额结算等，以供结算账单模块根据需要生成通行对账单。

　　ETC结算账单：有了不同的结算规则之后，定时任务按照配置的规则进行统计，生成ETC通行应付账单和退费应收账单。退费应收账单是针对于全额结算的合作方当发生ETC退费的时候，由对方来付款给我方。

　　上文我们提及到该结算单的原始数据是来源于“通行账单模块去合作方取的ETC账单数据”，然后根据结算规则生成结算单。

　　基于上述情况，账单数据来源各种原因（如网络波动我方漏取、他方漏发、解析故障）有那么一点儿不稳定，而通行账单有一个“账单日期的概念，也叫请款日期”，打比方1月1号0点-23点59分合作方原定会发100笔ETC账单给我们，那么这100笔ETC账单的账单日期旧是1月1号。

　　但是由于某种原因我方取到账单的时间推迟了2天，那么这100笔账单的“账单日期”并不会由此变为1月3号，他依然属于1月1日的，只不过我们的结算日期会相应推迟而已。

　　因为这种情况往往不能被第一时间被发现，为了应对这种特殊情况，我们将“通行账单”和“通行账单结算单”进行了解耦，正常的流程正常发起，而当发现有过往日期 “漏账单”的情况，则启动补偿机制，将漏掉的账单重新生成结算单，并再次补付款。

　　虽不想面对，但是有少付就可能有多付，那如何处理这种情况呢，请看下图，在合作方不愿意手动配合退款的情况下，我们在结算单模块新增一个类型“多付应收账单”，由系统与“通行应付账单”进行轧差。

　　结算规则配置，无非就是定义好几个W。WHAT结算什么；WHO，对谁结算；WHEN，按什么时间或者周期；HOW，怎么结算。

　　沿着这个思路，看以下规则，就包含了要结算哪条业务线什么类型的账单，向哪个合作方，结算周期D0还是D1， 怎么结算，垫资还是不用垫资，净额还是全额。

　　新增结算规则不用拘泥于一定要有什么配置项，可根据业务来定义有什么类型的账单需要结算，然后再抽象出类似结算周期，结算对象这种公共参数出来后，根据实际业务的不同结算需求去规划额外的的、特有的配置参数，以撑起我们规则的灵活性。

　　每一笔结算账单对应的付款状态和记录需要展示出来，让财务人员有迹可循，不至于想核查的时候都没记录看。

　　付款记录需要明确展示出对应哪笔结算账单，金额是多少，以及从哪个账户付，付到哪个收款账户，还有通过什么方式（通道）付款的。

　　消费金融大家可能比较陌生，但是在购物付款时一定接触过是否选择分期付款，或使用花呗或京东白条，其实这些都属于消费金融的一种展业场景。

　　一般指机构或企业为个人提供以日常消费为主要目的的小额贷款产品和金融服务，单笔授信额度小、服务方式灵活、贷款期限短（一般在1-12个月）等特点，流程简便、申请材料要求简单、到款迅速。本质是为了提前满足有消费需求，但短期无法全额付款的消费者的物质需求。用一句很流行的话来形容，就是：花明天的钱，圆今天的梦。

　　其中消费金融平台业务模式是利用自有资金或与银行、信托联合出资、同业拆借等形式获取资金，通过自营渠道（APP、公众号、小程序等）、B端合作渠道（借呗、金条等）、其他引流渠道（微信系、抖音系）等获得客户，为信贷用户和资金方搭建平台并引入增信方促成交易。

　　消费金融公司结算业务主要为信贷业务中参与的资金方、增信方、渠道方、服务机构、其他方通过账务记账分账和计费系统进行收益分配后资金结算，覆盖放还款、保费、理赔、追偿款、佣金、服务费等业务场景。

　　资金方：贷款出资人，根据不同的模式一笔贷款的资金方有可能是单独消费金融、银行、信托，或者消费金融+信托、消费金融+银行组合模式放款。主要涉及结算承贷资金，用户还款分配，逾期后触发理赔款和追偿款，以及项目利润的服务费等。 增信方：为客户贷款行为进行增信的机构，如保险公司、担保公司。主要涉及结算保费、服务费、理赔款、追偿款、保证金等。 渠道方：为消费金融平台提供客户的机构，如各大互联网提供消费分期和现金分期业务的平台。主要涉及结算放款、还款、佣金、贴息、营销费用等。 服务机构：为信贷业务整体过程中提供营销、投放流量和征信查询等服务的机构。主要涉及结算营销推广费、征信查询费等 其他方：为保险公司销售保险产品提供保险经纪服务或者为担保公司提供保证金拆借服务的机构。主要涉及结算保险经纪费、拆借利息和拆借资金还回等。7.2 结算核心业务流程

　　如下图消金业务，客户向渠道申请借款，渠道会将客户信息上送消费金融平台，平台会联合资金方进行放款，增信方进行承保，用户还款会拆分成各方账进行分配结算。

　　用户逾期时增信方会将理赔款支付资金方，债权转移，催收追偿款付给增信方，同时还会涉及到各方利润的分配。

　　所以，结算系统的核心业务就是根据结算规则将上游推送的计费数据严格按照协议合规前提下进行收款和付款结算，实现资金转移。

　　既然要进行结算就需要知道向谁付款或收款，通过什么路径和形式，收付款时间、周期规则以及协议依据。

　　对接商户系统获取收付款账号信息等进行开户，对接计费系统获取核心分账数据，对接客户系统获取客户身份信息等进行清分中注册、登账、清分等功能

　　对接内部户在商户下开设虚拟户和实户映射关系实现资金管控，对接支付查询收付流水实现付款和收款自动核销匹配。

　　由此结算系统的核心功能主要包含账户管理、路径管理、收付规则管理、项目协议管理、交易管理等。7.4.结算流程和模式

　　结算系统需为结算商户进行开户管理，维护合作方收款户、付款户、过渡户等信息，并关联结算项目，标记业务权限和用途。

　　配置结算费项的收付规则和路径信息，提现、扣款、上下帐、收款时读取规则进行自动触发。详情参考页面原型5.2路径管理和5.3收付规则管理部分。

　　结算需要的基础单据主要来源于计费系统，计费系统将关联商户的结算数据按照资金类型维度推送至结算系统。如下图是计费系统推送的计费数据。

　　充值模式：手动充值、自动充值、识别码收款充值。其中手动充值时，结算单和银行流水金额必须完全相等，按照下图流程进行充值

　　通常结算系统收到收款订单后，出纳拉取银行收款流水，通过打款账户、备注、摘要和收款金额等进行人工识别，匹配收款结算单，进行核销。

　　03处理：对应结算单/银行流水设置为已支付，进行相关帐号下账处理（轧差及下账）。7.5系统页面及原型

　　与合作方结算，发生收付款交易，在项目各场景下维护对应的合作方收付款账户信息、结算方式生成对应的结算账号信息。

　　在路径管理中进行维护项目中每一个结算场景的收付路径，有几个付款步骤，每个步骤付款账户是什么，收款账户是什么，哪些需要代为操作，哪些由合作方自己操作，权限配置，路径生效期有无特殊限制，满足财务多步骤付款的诉求。

　　在实际业务中，需要给合作方付款也会收款，合作方会提出形形色色的收付款要求。例如有的要求按日付，有的要求按周付，有的要求收款费项和付款费项轧差后按净额付，有的担保公司对接不同资金方项目产生的费用分别支付，有的要求所有项目汇总支付，基于上述业务场景收付规则管理统一进行维护。

　　主要维护：收付款频率、轧差模式、汇总收付维度、特定摘要、付款额度规则（保费池额度）、规则有效期、是否走清分、截留模式等。

　　按日结算：帐户打开自动提现时，每日10：00-16：00，每小时提现一次。（需要打开自动提现、支付开关）多个结算单

　　每日：帐户打开自动提现时，每日10：00-16：00，每小时提现一次。（需要打开自动提现、支付开关）按结算单逐步结算。

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

　　所有结算依据都是用印协议，运营对账核算、财务审批都需要严格按照协议内容规定进行审核。当协议内容进行变更时，系统中维护的对应内容应及时更新，避免结算和付款错误，造成资金风险。因此此功能主要将协议标记项目信息关联资金方、增信方、资金类型等信息，并根据协议内容复核系统配置参数，确保收付信息正确。

　　主要提供查询结算交易相关信息：包含支付流水、收款流水、收款认账、账户交易和余额等查询。支持线下充值和收款匹配等操作，实现资金上下帐操作。

　　陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！