计费和结算是每个公司结算系统的关节部分，向上完成业务订单流向结算信息流的转换，向下完成由结算信息流向资金流的转换。这个系统并非向OA、ERP等内部系统一样在每个公司都能见到，但是一旦存在，就起着至关重要的作用，因为涉及到钱。一个逻辑的错误或校验的漏判，造成的损失，可能是几十块几百块，也可能是几千万上亿。如果你也负责结算系统，请仔细阅读。
计费和结算
计费
在特定节点，对符合向商家付款或扣款的订单中各类费用进行依次计算。
前置条件
订单中心会把各种业务订单的状态和订单信息分发，结算系统监听到可以进行结算的订单状态并对订单信息进行解析，根据已有信息进行计费。
订单计费和计费明细
计费的结果就是一条一条的计费明细。计费明细的颗粒度有：订单维度、SPU、SKU、SKU类型、费用维度。注意，这里是依次递进的关系，也就是越往后粒度越细，结算系统需要与之交互的上下游系统越多，结算系统自身越复杂。京东POP结算就是下沉到SKU的费用明细维度，全部费用类型近百种。
费用明细并不全是由计费系统直接计算得到，也有上游直接透传、结算系统解析、从其他系统拉取等方式。视业务场景，方式不一。
举个例子，一个只有一个SKU的POP订单，极端情况下可能需要给商家结算20几种费用，例如：货款、佣金、配送费、仓储费、京豆费、退换无忧服务费等。
结算方向
C端用户下单之后，订单状态满足结算条件就会进行正向计费和结算，扣除佣金后将货款结算给商家。需要注意，这只是订单正向部分，还有逆向退货部分也要考虑到，这个场景一般比正向要复杂，因为像阿里、京东这种量级的电商，客服系统、退货退款系统的操作可能会影响商家结算金额。另外，个别费用有逆向退款或扣款，而有些费用因为特定业务场景是没有逆向的，所以必须提前确认好。否则，结果还用我说嘛？
通用计费接口
计费系统由哪方负责因公司不同而有所差异，但是功能大同小异。但是京东POP计费系统有一个通用计费接口，能够对接各个垂直业务系统，对业务系统自己生成的计费明细进行校验和透传，生成结算单进行付款。这就形成了自有计费和通用计费的双保险。
总结
京东的POP结算中心是面向商城内部各个事业部的POP业务提供的平台型服务，它有自己的先天优势就是，京东主流交易系统平台化做的相对完善，比如单品页、购物车、结算页、优惠券系统、订单中心、OFC（订单履约系统，细分为拆分、OCS、转移、OFW、风控）等，所有新增或已有业务的订单都必须通过这个中心向下流转。如果要做订单结算，POP结算系统只需要对这个唯一出口进行过滤和处理，相对标准。而美团大部分BU是各个业务线自己做自己的计费，结算系统实现的只是下面要介绍的结算部分的职能，相对个性化。
结算
账期开始前生成、账期中进行计费明细的填充、账期结束后补充必要结算信息，并在商家确认后进行付款或收款。
结算单
计费输出的是一条一条的计费明细，要结算给商家需要有一个载体，这个载体就是结算单。结算单的形式一般是前置结算单，即在账期开始前生成，账期内接收到的计费明细就填充到这个结算单里。等到账期结束，这个结算单就停止接收计费明细，生成一个新账期的结算单：旧结算单提交付款，新结算单重新接收计费明细。周而复始。
结算单可以理解成是一张白纸，计费明细就是在一定周期内写入的一行一行的文字，当到达约定时间就不再写入文字，进行下一道程序。
发票模式
每一个结算单都需要有特定的发票模式，因为在结算单付款成功之后，需要按照对应的发票模式进行销项发票开具或进项发票核销。需要说明的是，有的公司商家的发票模式是支持修改的，这会导致一个问题：历史账期已结算订单的发票模式与当前账期的发票模式不一致，如果产生退货，处理流程比较复杂。
结算机构
电商一般有多个主体开展不同业务，当结算单提交到资金系统进行付款时，资金系统需要知道使用哪个主体的账户进行付款。这个主体即使写在结算单上的必要信息，和上面的发票模式类似。
总结
结算系统说白了是一个承“上”启“下”的环节，“上”指的是所有涉及向商家收、付款的业务，比如订单款、保证金、调整项、返利，职能就是对上面提到的各个业务生成的费用进行汇总生成完整结算单。“下”就是支付平台，因为所有公司都需要有这么一个收口，职能就是对各个业务生成的结算单进行统一付款和收款，其中也包括后面要提到的线下收款管理。
