商家结算业务中三个重要产品 ：账单、付款与发票

在平台向商家结算的业务中，有三个重要的产出物，本文主要说明的就是他们归并 的原因、归并 办法 ，以及归并 关系的逻辑实现，希望对你有所启发。

在平台向商家结算的业务中，最终会有三个异常 重要的产出物——账单、付款、发票。

商家需要知道一个结算周期内，自己的账单、付款、发票，三者有着紧密的联系，商家对账也是要核对清楚“账、款、票”的一致性。

一、账单、付款、发票

账单就是提供给  商家的本结算周期的交易记录，买了若干 货、收了若干 钱、退了若干 款，以及平台抽了若干 佣金，代扣代缴了若干 税，本期应结若干 钱等等。

付款就是依据 账单结算的最终资金，把钱打到商家签约的结算银行账户中，商家就会拿着自己的账单来核对自己的收款，账单里告诉 商家要结算20万，那就应该收到20万的付款。

然后就是发票，这里的发票可以是广义的票据，比如  消费的小票、增值税发票等，所以不合  的款项可能要开不合  的发票，不合  的对象可能要开的发票也不合  ，而不合  的国度 需要的发票种类也不合  ，这要看这个国度 此类活动需要什么税种。

税种也不是一成不变的，如下图就是在某国依据 其司法 要求进行的按期税改，从图中可以看出开票跟账是分不开的，同时开票跟付款也分不开。

开票就需要接外部的开票渠道，这个在不合  国度 也有不合  的办事 商，按其标准  去接入即可，如智利、墨西哥等可以接入gosoket、vender等发票办事 商。

其中有一个特其余 税，就是增值税，平台收了商家的佣金，佣金是平台的收入，所以这部分  是需要平台缴纳增值税vat，然则 这部分  平台可以转嫁给商家，这时候就需要赞助 商家代扣代缴，并且  赞助 其开vat增值税发票。

二、有拆有合，需求多样化

上面介绍的是一条结算产出物的主线“账单、付款、发票。

那么拆开看，账单、付款、发票还有更精细的属性，比如  一个自力 的小商号 和一个全国数千家连锁的麦当劳对“账单、付款、发票”的模式诉求年夜 为不合  。

也就是普通商家和连锁商家有不合  的需求，所以我们将商家分成三个品级 “KA、CKA、普通商家”。

KA就是年夜 型连锁商家，无论是连锁酒店、连锁超市、还是连锁餐饮，普通商家就是一个自力 的小商家，就一个门店；而cka就是介于二者之间，例如有十几个门店，但并非年夜 型连锁。

还有品牌一说，一个KA下可能有多个品牌，一个品牌也可可能有多个连锁业务等等，有很庞杂 的关系。

同样，还有法人主体一说，有的多门店共用一个法人主体，有的每个门店是一个零丁 的法人主体，那么这样的话，就有了更庞杂 的组织关系，也会造成结算关系的庞杂 ，对平台来说，账单生成、付款处理  、发票开具的模式就庞杂 了。

比如  ，对于年夜 型连锁来说，就存在总部和门店的关系，比如  有的KA要归并 付款到总部，总部统一收款，那么账单、发票要进行归并 ，然则 每个门店又要统计自己的经营，所以每个门店又要零丁 的账单信息；而有的KA可能需要零丁 付款给每个实际经营的门店，然则 要给总部归并 账单。

三、简历关系，灵活归并

上述的账单生成，结算付款，发票开具都有自力 完整的主模块。

而如何生成账单、如何进行付款、如何开具发票，就需要考虑是不是需要归并 ，归并 那一块业务。

此时就需要一套规矩 的配置，来促成这一“是合是分”的实现。

其实在归并 上有很多归并 逻辑，主要是要抽象出“归并 维度”，我能实现以谁为归并 维度，或者依照 司法 律例 我必须  以谁为维度，或者依照 司法 律例 我不克不及 突破什么维度而归并 ，例如我能不克不及 突破法人主体而归并 付款给总集团？这些都需要财税法团队的支持以满足本地 的司法 律例 和商户的诉求。

假如，我们归并 的上限是法人主体，只能针对同一法人主体下的门店归并 其付款和发票，也就是多个门店的营收可以一笔付款，和开一张票；然则 账单我可以任意归并 出具；当然其他依照 品牌归并 或者更多维度也可以实现，方法 类似。

这样的假设之下就需要构建一个门店归并 关系。

我们通过配置化实现这层归并 关系，在账单生成、付款单生成、发票数据处理  时，挪用 这个关系，去判断该门店是否在一个归并 关系中，该业务是否需要与其他门店进行归并 。

这里的归并 关系，是建立一个主体下的多个门店之间在“账单、付款、发票”三个业务之间“是否归并 ”的关系，如下图中的归并 关系，仅仅是归并 了3家门店的付款，而发票和账单并没有归并 关系所以还是按单门店执行。

那么为什么会存在一个法人主体下仅部分  门店归并 了付款呢？这里的归并 诉求要看商家具体经营情况，可能是这3家门店是同一个运营团队在运作，而该企业是以运营团队为单位  进行核算的。

如下图的配置关系规矩 ，明确了哪些门店进行了归并 ，在什么场景上归并 了，这里的场景主要是3个，就是“账单场景、付款场景、开票场景”。

在新增归并 关系时，必须  选择一个法人主体，该法人主体下的门店可以自由组合。

这时，一个法人主体下就可以配置多条归并 规矩 ，一条归并 规矩 可以约定了这些门店是归并 了什么场景。

账单、付款、发票都是自力 的业务，他们未来都邑 有自力 的文章零丁 介绍，各自的详细业务介绍本文就不过  多说明了。

本文主要说明的就是他们归并 的原因，归并 办法 ，以及归并 关系的逻辑实现。

专栏作家

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

本文原创宣布 于人人都是产品  经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文不雅 点仅代表作者本人，人人都是产品  经理平台仅提供信息存储空间办事 。