第20章　収益の計算と分配の執行

第二十章　收益核算与分配执行

共同创造能否成为共同成长的资本，既取决于组织能否形成持续创造的能力，也取决于参与者能否依据清楚的制度分享成果。贡献得到确认、权益已经表达、通证可以流转，只完成了其中一部分。回报还需要经过资源确认、资格核验、金额计算和实际履行，才能进入参与者的生活与后续行动。

上一章将贡献激励、通证价格与企业价值分别讨论。本章进一步追问：组织究竟以什么资源履行回报安排，这些资源可以分配给谁，采用哪一版规则计算，又怎样证明已经完成支付。市场报价不能回答这些问题，智能合约中的余额和分配按钮也不能独立回答。

本章所说的收益核算与分配执行，涵盖利益相关者回报安排中的资源核算和履行程序，但不把所有回报都归为利润分红。报酬、费用偿付、有条件的收益分享与其他经济请求，可能具有不同依据。制度技术的任务，是让这些差别在从业务到支付的全过程中保持清楚，并使每项处理能够追溯到事实、规则与责任。

一、收益来源与可分配资源的确认

收益首先需要回答来源问题。组织通过提供产品或服务取得的收入、持有资产产生的回报、处置资源取得的款项，以及外部主体提供的资金，具有不同经济性质。来源不同，伴随的成本、义务、限制与持续性也不同。如果只把所有流入汇总为一个“收益池”，参与者就难以判断自己分享的是经营成果、资产处置所得，还是需要组织继续履行义务的资金。

核算应当从明确边界开始。哪一个主体承担回报义务，核算哪一项业务或哪一个范围，覆盖什么期间，采用什么计量单位，都需要事先说明。共同事业可以跨越多个组织，但各组织拥有的资源和承担的义务不能因此自动合并。合作方账上存在资金，并不意味着支付主体已经能够支配这些资金；组织之间发生内部划转，也不必然形成共同体系新增的经营成果。

收入确认与收款时点需要分别处理。在 IFRS 15 所适用的客户合同收入核算中，收入确认与承诺商品或服务的转移及履约义务的满足相关。因此，收到了预付款和已经完成收入确认，不能仅凭资金到账被合并为一个事实。这里引用这一原则，是为了说明核算需要业务依据，具体组织仍须使用其适用的会计制度。IFRS Foundation：IFRS 15 客户合同收入〔1〕

利润与现金流同样回答不同问题。某个期间已经确认的经营成果，可能包含尚未收回的款项；账户现金增加，也可能来自借款、出资或资产变现。IAS 7 将现金流区分为经营、投资与筹资活动，并在间接法中通过非现金事项等调整连接损益与经营现金流。核算中的这种区分，提示分配制度不能把利润、收款和账户余额当作同一个数字。IFRS Foundation：IAS 7 现金流量表〔2〕

对利益相关者资本治理而言，回报安排的性质还会影响成本与分配的边界。按约定应当支付的劳动报酬、采购款或费用偿付，不能只因领取者也是共同创造者，就全部移到利润形成之后再决定是否支付。某项回报应计入何种核算项目，需要根据其实际性质和适用制度判断。若已经作为成本或义务处理，后续计算也应避免以同一名义再次扣除或重复分配。

由此，可分配资源需要经过三方面核验：分配依据允许什么，现实资源能够支持什么，有权程序决定本期安排什么。第一方面涉及权益和用途边界，第二方面涉及资源控制与履行能力，第三方面涉及具体方案的有效形成。三者相互制约，不能让账户可见余额替代全部判断，也不能让一个分配决定凭空补足缺失的资源。

资源控制应当查明对象和限制。代为保管的资产、限定用途的资金、已为其他义务作出安排的资源，以及尚未收回的款项，都需要分别表达。即使某项资产已经在组织控制的钱包中，也需要判断其经济归属、使用约束与实际可转移状态。控制能力可以支持履行，却不是任意分配的充分依据。

准备本期分配时，还要识别与履行有关的必要支出、既有义务和资源需求。这里不能使用一条脱离核算口径的通用减法：某项支出若已反映在所采用的净额中，再次扣除就会压低结果；某项资源若同时被多个分配池引用，又会夸大支付能力。每一项调整都应说明进入哪一个口径、是否已经计算，以及对哪些安排产生影响。

组织保留资源用于维护、研发和长期能力建设，可以服务于共同成长，但保留安排也需要接受治理。其依据、用途、期限与效果应当可解释，不能长期依靠一个没有边界的“发展需要”压缩所有回报。反过来，分配比例不断提高也不自动意味着治理改善；若由此损害必要维护和持续履行能力，当期领取者的收益可能以未来参与者承担成本为代价。

对于现金以外的分配，还需要明确交付对象。支付某种数字资产、提供使用额度和支付约定货币，是不同履行内容。计量价格可以帮助比较，却不能自行将一种对象替换成另一种对象。兑换时点、费用承担、价格来源和差额处理，应当与原有权利安排衔接；有无被认可的替代履行依据，比系统是否支持兑换更重要。

组织自行发行的单位尤其需要单独说明。增加单位数量可以完成一种奖励或资格配置，但不能仅以参考价格乘以数量证明形成了等额可分配经营资源。若单位对应未来请求，还应继续记录其条件与相关义务；若其回报依赖外部买方接手，也应保持这一来源区别。

资源确认最后应形成可复核的核算说明。它应连接业务证据、核算调整、资源清单与分配授权，并保留尚待确认的事项。记录摘要或核验结果可以进入共享账本，明细则依据必要性与权限保存。账本使各方更容易识别共同采用了哪份结果，结果是否完整、真实和适当，仍需要业务核验与独立复核支持。

确认资源的意义，是为承诺建立可履行的基础。如果本期尚无满足条件的新增分配资源，就应如实表达；对于此前已经成立而尚未支付的义务，则继续记录其金额、期限和处理状态。没有新的分配能力，与没有既有支付责任，是两个需要同时看清的问题。

二、分配资格、规则版本与计算周期

资源确认之后，需要识别谁有资格参与哪一项分配。贡献事实、资本记录、收益资格与应付金额之间虽然可以建立联系，却不能省略中间的制度条件。完成贡献可能取得某种计量结果；该结果是否进入资本安排，以及何时形成经济请求，需要分别适用对应规则。钱包持有量也只有在特定制度明确赋予相关效果时，才能成为分配依据。

资格应当对应具体安排，而不是一个永久通用的“成员”标签。同一主体可能在不同业务、期间和角色下拥有不同资格。曾经参与合作不必然意味着无限期分享一切新增成果，当前退出某项角色也不必然使已经形成的请求消失。核验需要把主体身份、权利来源、有效期间、附加条件与适用范围联系起来。

本书主张将资格名单、计算结果和履行清单分别保留。资格名单回答谁可以进入某项计算；计算结果回答依规定口径得到多少；履行清单则在请求已经成立、支付安排已经有效且操作条件具备时，说明接下来应完成什么。三者可以由同一系统连接，但不宜用一个“待领取余额”覆盖全部状态。

规则版本决定这些连接怎样发生。一个完整版本至少应能指向资格条件、资源口径、权重或比例、期间定义、调整办法、舍入规则和必要的例外程序，并说明制定权限及生效时间。程序版本与制度版本也应对应：计算程序经过修改，不当然意味着有权改变参与者的回报条件；制度修订生效，也需要确认执行系统已经准确承接。

分配中的时间不是一个日期。贡献发生期间、成果核算期间、资格确定时点、决定生效时间、可申请时间和实际支付时间，可能分别存在。某月支付上季度已经成立的请求，并不会因此将贡献或经营成果改归本月。区分这些时间，才能解释跨期变化以及为什么同一参与者在不同清单中呈现不同状态。

对于可流转权益，需要说明收益资格怎样随时间划分。如果采用某个时点的持有状态，就应明确该时点与所属期间的关系，转移前已经独立成立的请求是否随同转移，以及怎样防止转出方与转入方重复领取。如果采用期间内的有效持有量或其他连续条件，也应说明计算范围与中断处理。没有哪一种时间设计天然适合全部权益。

身份与地址之间的对应也须采用正确的历史状态。地址更换、代理关系终止、托管转出或组织名称变更，可能只改变支付路径或经办主体。核验应根据有关资格与请求的归属处理，避免一个主体通过多个账户重复取得同一份额，也避免因更换工具而丢失既有请求。

在仅按有效权重分配一个已获授权、非负且确定的资源池时，可以用一个简单关系说明计算：某主体本期份额，等于该资源池乘以该主体有效权重占全部合格主体有效权重的比例。这一关系成立的前提，是权重口径一致、总权重大于零，并且该池不存在需要另行处理的优先安排、上限或其他条件。它描述一种方案，并不证明这种方案公平，更不适用于所有固定支付请求。

若工资、合同款等请求已经依其依据独立成立，就不能未经有效依据，把它们与有条件的剩余分享资格一起按池内余额同比缩减。若制度选择对不同类别分别配置资源，则需要先说明类别之间的安排，再在各类别内部计算。公式能够保证输入相同得到相同结果，不能替代对分类、权重与顺序的授权。

计算还包括对精度与边界的处理。最小支付单位、舍入方向、尾差归属、零权重、负向调整和金额上限，都可能影响结果。小额请求若因支付成本暂时合并，也应保留其归属和累计记录；是否设定处理期限及到期效果，需要有明确依据。技术上的最低转账额度不应悄然成为取消小额权利的规则。

为了使结果可以复算，每一批计算需要固定所使用的资源数据、资格数据、规则版本与必要参数，并记录生成和复核结果。这种固定是保留计算依据，不是禁止后续纠错。组织应当能够重现“当时为什么得出这一金额”，再解释新的证据导致哪些差异。

发现迟到证据、遗漏贡献或计算错误时，可以依既定程序进行补充计算、冲正或跨期调整。已经支付的部分、尚未支付的部分与仍有争议的部分应分别处理。不能为了让新结果看起来连续，直接覆盖旧版本；也不能把修正事实错误当作随意追溯改变分配政策的理由。

每期分配因此应形成一条可以跟随的关系：资源确认指向有效方案，方案指向适用资格与计算依据，计算结果再指向成立的请求和支付安排。参与者无需看到全部程序细节，但应能查明自己的资格、金额、期间、限制及提出异议的途径。可解释的结果，是制度执行获得持续认可的重要条件。

三、链上分配与链下支付的对账

分配执行可能全部发生在链上，也可能通过银行账户、支付服务或其他链下方式完成，还可能由多个环节共同构成。无论采用哪一种路径，对账都需要回答同样的问题：原来应向谁履行什么，实际发生了哪些操作，这些操作完成了多少义务，还剩下什么。技术路径可以不同，制度中的对象和责任必须能够对应。

首先应当区分分配结果的登记与资源转移。系统把某个金额记入参与者账户，可以表示计算完成、请求成立或额度可申请，具体含义取决于制度定义。只有在相应履行确实发生时，才能继续确认已付状态。将内部余额命名为“到账”，并不能消除领取限制、资金缺口或外部支付尚未完成的事实。

链上执行也存在多个阶段。交易提交、被区块收录、执行成功以及达到适用的最终性条件，需要分别观察。以太坊的接口文档分别提供交易回执中的执行状态，以及用于查询已最终确定区块的标识。这些信息支持技术核验，但它们并不直接说明某一现实经济请求已经得到完整履行。Ethereum：交易回执与区块状态查询〔3〕

具体支付还要检查正确的网络、资产标识、接收地址、数量和业务对象。合约调用成功可能只完成授权或更新某个记录；即使发生转移，也需要核验其是否对应约定资产与请求。存在转移费用、特殊余额机制或中间合约时，实际到达结果还须根据具体机制确认。一个交易编号不能替代这些对应检查。

当制度约定以某种链上资产向有效指定的地址履行，且相应转移满足既定条件时，该转移可以作为完成有关支付的证据。若原来约定的是链下货币到账、兑换后交付或其他结果，则应继续核验后续环节。协议中的最终性与义务是否履行完毕，具有不同判断对象，二者需要通过明确的履行条款连接。

链下支付同样不能只凭发起记录关闭请求。付款文件已生成、支付机构已受理、付款账户已扣款和收款结果已经确认，可能分别发生。回执的证明范围应当根据支付渠道判断；只表明提交或处理中，就只能支持相应状态。退款、退票、拒收或后续更正也应进入持续对账。

共享账本可以保存链下回执的摘要、来源和确认记录，但回执上传者仍承担相应的信息输入责任。摘要能够帮助核对文件是否为同一版本，不能证明回执内容必然真实。重要支付需要能够回到可信来源查验，并说明谁负责处理来源矛盾或状态更新。

这张表表达的是履行关系，不要求全部系统采用同一套界面状态。关键在于每种状态都具有明确证据门槛，不能由经办者仅凭主观判断推进，也不能因为某个外部系统暂时没有返回结果，就自动将请求视为已失败或已完成。

为连接多条记录，每项支付请求应具有稳定的业务识别号，每次执行尝试另有操作识别信息。一次请求可以分次支付，也可以因失败而多次尝试；一次批量操作又可能对应多个请求。因此，对账需要保存请求、操作与实际结果之间的映射，逐项分摊金额，不能简单假定一笔交易就等于一个完整请求。

防止重复付款尤其依赖这种分工。同一请求同时允许链上领取和链下支付时，应有共同的领取或支付控制，并将已经进入执行、结果仍待查明的部分单独保留。发生超时后，先查询原操作结果，再决定是否重试；只有确认不会形成重复履行，或已通过适当机制协调后续处理，才能重新发起。单个区块链拒绝重复支出，并不自动阻止另一个系统再次向同一主体付款。

跨系统操作通常不能被假定为同时完成。链上已经更新，银行支付却尚未完成；银行已经扣款，链上确认又暂时中断，都可能使两边处于不同阶段。此时应建立差异处理记录，指定核验责任并限制冲突操作。恢复后的任务是把实际结果准确接回原请求，而不是把所有记录强行改成同一种状态。

对账还需要统一金额解释。原请求采用何种单位，实际支付使用何种资产，换算依据是什么，手续费及适用扣缴由谁承担，都应在结果中明确。组织支出的总额、向收款人支付的净额以及依法或依约另行处理的款项可能不同；相关扣减必须有依据和去向，不能仅以总扣款与应付金额接近作为已经足额履行的证明。

在同一计量口径下，期初未履行请求、本期新增请求、有效调整、实际履行与期末未履行结果应当能够衔接。资源账户的变动则另行与资金或资产流水核对。两套衔接需要相互支持：支付流水真实存在，不证明全部应付对象已经覆盖；应付清单被标记完成，也不证明资源确已交付。总额相符之后，仍需逐项检查漏付、错付和重复支付。

已核验支付之后发生退回或错误确认，应通过有依据的更正反映结果，并保留原操作历史。多付部分的追索、抵扣或其他处理，需要相应依据和程序；不能因为系统能够从下一期余额扣除，就跳过有关主体的权利和异议处理。纠正记录与完成补偿也应分别呈现。

主动批量支付与参与者自行领取，都需要匹配实际使用条件。批量支付应追踪每个对象的结果；自行领取应说明申请条件、资源准备、操作成本和无法操作时的替代路径。已经取得资格的人长期无法领取，仍然是履行问题，不能用合约界面保持开放证明安排已经实现。

对账的透明性可以分层提供。参与者可以核验自己的请求、计算和支付记录，授权复核者可以检查总体勾稽关系，其他主体则在适当范围内了解分配总量与差异处理。个人收款账户和全部收入明细没有必要因此向所有人公开。可核验性应当扩大监督能力，同时保留合理的信息边界。

四、亏损、延期、退出与争议的处理

分配制度的完整性，体现于条件变化时仍然能够解释责任。经营亏损、现金不足、系统故障、资格争议和主体退出，影响的对象与后果各不相同。如果系统只设计顺利分配的路径，异常发生时就容易把不同问题统一处理为余额归零、暂停领取或等待通知，使原来承诺的边界变得模糊。

亏损首先需要在核算上说明来源、期间和影响范围。某项业务的损失是否影响另一项业务的分配，是否与共同承担的风险相关，应依据已经确定的组织和权益安排判断。不能仅因为全部账户位于同一平台，就默认任何局部损失均由所有参与者共同承担。

对于取决于未来可分配成果的资格，亏损可能导致本期不满足新增分配条件；对于已经独立成立的支付义务，亏损则意味着履行能力可能受到影响，需要进一步处理。二者不能混写为“本期无收益，所以全部请求取消”。本书强调的风险承担，是识别各类主体依据什么承担哪些后果，而不是把组织困难转化为所有参与者无差别承担的责任。

制度若设置亏损结转、资源补足或后续收益先行弥补的机制，应事先说明适用范围、计算口径和时间条件，并接受相应授权约束。这类安排可能影响不同期间参与者之间的负担分配，因此还需解释新加入者、已退出者和持续参与者各自承担什么。不能在结果已经出现之后，仅因某一群体缺少技术控制权就把损失移到其账户。

经营损失与贡献事实也应分别记录。已经完成并获得确认的贡献，不因企业后来亏损而自动成为未发生；贡献所支持的资本能力却可能发生减损，相关权益的经济实现也可能受到影响。保留这种区别，才能同时承认历史行动、评价现实能力，并诚实说明回报的不确定性。

正常经营风险、事实造假、越权分配和操作过失，则需要不同的责任判断。发生损失并不当然证明某个经办者违规；存在违规证据，也不应仅用“共同承担风险”代替调查。技术记录可以支持重建事实，责任认定仍需要证据审查、利益冲突处理与有权程序。

延期处理应当明确延后的是哪个环节。核算尚未完成、资格仍在复核、支付已经到期但资金不足，以及支付渠道暂时中断，不能统一显示为“未解锁”。通知应说明影响对象、当前状态、原因、负责主体、预计处理时间及下一次复核安排。暂时无法确定最终时间，也应提供持续更新的责任和节点。

当已经成立的请求需要改变履行时间或方式时，应依据适用的权利安排和必要程序处理。技术管理员能够修改锁定时间，并不意味着已经获得修改支付期限的权力。对于可以分阶段履行的安排，应当保留原请求、已履行部分和后续安排，防止一次小额支付被误写为全部解决。

资源紧张时，支付顺序也需要有依据。适用法律、合同和有效制度对有关请求的约束，应进入方案判断，不能由界面排队顺序或管理者临时偏好替代。若已经进入需要专门清偿或重整程序的情形，内部算法也不能自行定义全部请求的地位。对资源不足的承认，应当促成有权处理，而不是使自动化执行越过其适用范围。

退出则应当拆分关系终止与请求结算。停止承担未来任务、失去某项持续资格、转让特定权益和领取已经形成的应付款，可以分别发生。退出账户的关闭时间不应决定全部历史权益是否存在。系统需要保留必要的身份联系、送达方式和后续结算渠道，使已经离开日常协作的人仍能处理未了事项。

退出条件还应说明未完成任务、条件尚未满足的奖励、有效锁定和后续证据修订如何处理。若存在结算准备或暂缓支付安排，需要明确依据、范围、期限及复核途径。已经满足条件的部分与尚待满足条件的部分应分别列明，避免用一个没有明细的“退出折扣”覆盖不同性质的调整。

争议处理可以从明确争议对象开始。参与者可能争议贡献事实、资格认定、规则适用、计算金额或支付结果，每一类需要不同证据和复核能力。账本上的共同确认可以证明系统曾采用某份记录，却不能排除该记录所依据的事实或授权存在问题。程序应让提出异议的人能够指向具体事项，而不必重新证明整个制度是否有效。

有效的处理需要受理渠道、提交依据、回应期限、回避安排和可说明理由的结果。涉及共同资源的事项可以接受相应监督，但个人明细仍应在必要范围内使用。无争议部分若能够依制度独立履行，应继续处理；确需保留争议资源时，也应记录范围和解除条件，避免局部争议成为无限期冻结全部回报的理由。

决定更正后，系统应把结果落实为补付、恢复资格、调整未付金额或其他有依据的行动，并与原记录相连。已经最终确认的链上交易未必能够被技术撤回，但组织仍可根据实际条件，通过新的操作、补偿或其他适当途径纠正其制度后果。历史不可轻易改写，并不意味着错误不再需要处理。

面向未来，本书提出一个需要检验的方向：让分配系统持续维护从资源来源到未履行请求的证据联系，使参与者能够在权限范围内核验承诺获得了多少资源支持、哪些履行已经发生、哪些差异仍待解决。这样的系统能否改善协作，需要观察遗漏和重复支付是否减少、争议处理是否及时、维护成本是否合理，以及参与者是否更容易理解并行使自己的权利。共享记录的规模，本身不是制度成效。

至此，从贡献确认、资本形成到权益配置与收益执行，形成了一条相互衔接又不能省略判断的制度过程。共同创造能够支持资本延续，资本运用可能形成经济成果，有效权益安排决定参与者可以提出何种请求，核算与支付则使有关请求得到实际处理。每一步都需要明确条件，也都需要有人承担决定、核验和纠错的责任。

下一篇将转向协同治理。谁有权确认分配方案、谁代表受到影响的主体、谁监督执行并修订规则，已经无法仅靠账本状态一致来回答。第二十一章将从技术共识与多方治理的分别配置出发，进一步讨论共同账本之上的组织权力与参与秩序。

定稿补强：可分配资源瀑布、税费与亏损

分配必须沿一条可解释的资源瀑布进行：先确认收入或其他资源来源，再扣除成本费用、税费与到期义务，检查法定或合同限制与必要储备，确认现金或其他支付资源可用，取得治理批准，最后计算个体应付。收入、利润、现金、通证价格和可分配资源不是同一个数值；任何一步尚未成立，都不能由后续公式补足。

分配批次还应记录税费类型、代扣主体、汇率来源与时点、手续费承担、支付失败和重新支付。发生错误或后续损失时，准备金、负余额、追回、抵扣、时效和争议规则必须在分配前有效存在，不得事后任意转嫁。组织应向参与者披露流动性和长期投入约束，使公式正确与组织持续经营同时接受审查。

本章工具与图表

本章的制度关系可结合附录七使用。附录用于形成可填写、可核对的工作成果，不能把模板中的默认项视为已经生效的组织规则。

图14-1　从承诺、贡献到权益与回报。 每个箭头都是独立判断关口，不允许用一条记录跨越全部制度门槛

本章注释

1. [SRC-054] 国际财务报告准则基金会（IFRS Foundation）：IFRS 15 客户合同收入。原文或官方页面

   • 本章引证：IFRS Foundation：IFRS 15 客户合同收入。
   • 支持范围：用于确认财务、审计、内部控制或公司治理中的规范口径，本书引用主题包括：IFRS Foundation：IFRS 15 客户合同收入。
   • 使用边界：规范口径需要结合适用主体、报告目的和具体交易事实，不宜机械移用于链上权益。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

2. [SRC-053] 国际财务报告准则基金会（IFRS Foundation）：IAS 7 现金流量表。原文或官方页面

   • 本章引证：IFRS Foundation：IAS 7 现金流量表。
   • 支持范围：用于确认财务、审计、内部控制或公司治理中的规范口径，本书引用主题包括：IFRS Foundation：IAS 7 现金流量表。
   • 使用边界：规范口径需要结合适用主体、报告目的和具体交易事实，不宜机械移用于链上权益。
   • 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。

3. [SRC-029] Ethereum.org：交易回执与区块状态查询。原文或官方页面

   • 本章引证：Ethereum：交易回执与区块状态查询。
   • 支持范围：用于说明特定协议或项目在当前文档中的运行机制与工程约束，本书引用主题包括：Ethereum：交易回执与区块状态查询。
   • 使用边界：项目文档描述特定系统，版本、参数与实现可能变化，不能直接外推为所有区块链的一般性质。
   • 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。