开发向专区
合伙人的账，怎么记到不用靠人品
五个机件，让任何一位合伙人不问人就能看出账是对的。
合伙人之间的账，常见的坏法不是有人做假账，而是没人能证明自己没做：一张谁都能改的表，一个人记的账，口头对过的数——三样凑在一起，信任只能靠人品撑。我们把「怎么让合伙人互信」做成了一套跑在系统里的机制，一共五个机件，每一个上线时都撞过实际问题。这一页讲的不是账，是账本本身怎么设计，才配得上被信。
这套机制只在一家公司、一套系统上跑过；哪些跑通了、哪些还在路上，末尾如实写。
一、难的不是防谁作恶，是没人能自证清白
机制只回答一个问题
合伙人之间对账，人的直觉是「防谁」。但真正把信任耗光的，往往不是谁动了手脚，而是三样很平常的东西：可以改的表、一个人记的账、口头对过的数。它们各自都不算错，凑在一起的结果是——出了差错，谁也说不清；没出差错，谁也证不了。
所以机制要回答的只有一个问题：任何一位合伙人，在任何时刻，能不能不问人、自己看出账是对的。 能，信任就不用靠人品；不能，再好的人品也只是暂时没出事。
下面五个机件，全部围绕这一句。它们分别管：账能不能改、账有没有被动过、每天的账有没有人看过、钱是谁付的、分的是不是真钱。
二、账本只增不改，更正走红冲
「能改」本身就是不可信的来源
头一个机件：账本只能往后加，不能改、不能删。写错了怎么办——不改那一笔，另起一笔反向的分录，指向原来那条，两笔都留在账上。这叫红冲。红冲必须填理由；替别人冲的，系统会通知原来记账的人。
读者要拿到的判断是：「能改」本身就是不可信的来源，哪怕改的人是对的。 一张能改的表，你看到的是它现在的样子，看不到它经过了什么；一张只能往后加的账，翻旧账的成本对所有人相等——谁都翻得到，谁也藏不住。
这条规矩在系统里是硬的，不是靠自觉：账本那张表不接受修改和删除的动作，更正只有红冲一条路。
三、每笔带上一笔的指纹，谁都能一键校验
动过任何一条，后面全部对不上
第二个机件：每一条分录写入时，都记下上一条的摘要。于是整本账连成一条链——中间任何一条被动过，从那一条起往后全部对不上。每天封账时，那一天的块再算一次整块的摘要，块和块之间同样相连。
只有链还不够，还要让人能查。系统里有一个「校验账本完整性」的按钮，合伙人在自己的账号里就能点，结果只有两种：完整，或者第几条断了。「不可篡改」不是一句口头承诺，是人人可以自己按一下的能力。
这两处设计不是新发明，借的是公开账本系统里几个成熟的做法：逐条相连防篡改、多方签核出块、规则变更要共识。本页只取机制，不展开那套东西本身。
四、每天两个人分别签一次
机制在册，不等于机制在用
第三个机件：一天的账是一块。当天经手的人交班时签一次——签的是当日汇总的快照；另一个人接班时再签一次，签完这一天就封了，进入前面说的那条链。系统硬校验两次签名不能是同一个人；接班的人签之前，要把当天的分录逐笔核过、勾上「已逐笔核对」才签得动。看不懂或对不上，不签，改为提出异议——这一天的块进入「争议」状态，由裁决角色处理，裁决签的名会被特殊标记，谁都看得出这一块不是正常封的。
这一件的教训必须写：机制上线后两个月里，从没有人真签过。 表、状态、校验全在系统里，但没人知道该谁交、该谁接、几点签，于是每天的块都停在「未封」。直到把「当天经手的人晚上交，另一个人次日中午前接；没块不用签，缺位有人顶」写成一张日常的流程单，头一块账才封上。机制在册，不等于机制在用——这和本站讲「给成员装脑」「判据要实跑」那几页撞的是同一个根。
头一块封账当天，还暴露了三处界面缺陷：交班的人签字之前看不到当天的实时数，分录明细没有按日期筛选，收入分录缺收款路径。当天转成小单，当天上线。机制头一次真跑，本身就是一次验收。
还有一条后来才立的细则：两签之间要隔开时间。同一台电脑切个账号连着签两次，形式上是双签，实际上是一个人核了一遍；两签之间的时间差，本身就是「两个人各自核过」的证据。
五、付款只走一个窄口，超限是系统拒的
限额不是不信任经办人，是让经办人不必自证
第四个机件管钱是谁付的。对外付款只走一个池、一个窄角色：经手的人在那个池里按定额干活，定额之内不用请示，定额之外没有能力操作。其他人——包括只读的合伙人角色——连写入的按钮都没有。
上限分三层：单笔、个人当日、整个池当日。超了任何一层，系统直接拒，并把是哪一层超了写在提示里。池级的上限要改，得合伙人双确认，再走代码评审——它是写在代码里的常量，不是界面上一个能随手拖的数。加人、减人，只翻开关、不删记录，谁曾经能付款，账上一直查得到。
付款和记账是同一个动作的两半：付完即录，录必带凭证。这一点在实际里比想的更硬——付款那一头拦不住的，记账这一头当天就会暴露：付了却录不进，跨日没录，就是异常。付款池的流水对合伙人始终互相可见。
读者要拿到的判断是：限额不是不信任经办人，是让经办人不必自证。 超限是系统拒的，不是他拒的；没超限的每一笔，也不需要他向谁解释。
六、分红看账户里真有多少钱，不看账面算出多少
宁可分不了，不分账上有、账户里没有的钱
第五个机件管分的是不是真钱。账本上收入减成本得出的净利，和账户里真能动的钱，经常不是一个数——长期订阅的收入记在成交那天，成本却按月发生；有些款收了但还没交付，那笔钱不是你的。
所以可分配的基数不从账本算，从账户算：上一次录入的几个账户真实余额合计，减去录入那一刻冻结下来的待交付成本，再减去一笔运营底金。没有余额快照的时候，基数就是零——宁可分不了，也不分账上有、账户里没有的钱。账本口径的净利退为核对参考：两个口径之差，就是漏记和时点错位的信号量，月结的时候解释这个差。
余额快照本身也是只增不改的：录错了，新起一行、指向旧的那行，旧行不动。分红的参数——比例、系数、底金——要改，先在账本里写一条金额为零的「留痕分录」，写清谁确认的、为什么改，然后才生效。参数怎么改、谁点的头，和每一笔交易一样翻得到。
七、看得见一切、改不了任何东西的那个人，才是可以放心的人
只读不是降权，是免责
把前面五个机件按角色摆一遍，就是一张一句话版的可见性矩阵：
- 合伙人角色：账本、日块、付款池流水、看板，全部看得到、全部只读；任何写入的动作一律拒。
- 经办人：只看得到自己经手的分录，只在自己的池里、自己的限额内付款和记账。
- 裁决角色：可以红冲，可以裁决争议，但同样不能改任何一条已经写下的东西。
读者要拿到的判断是：只读不是降权，是免责。 看得见一切、改不了任何东西的那个人，恰恰是账上可以放心的人——他出不了差错，也不用证明自己没出。
八、边界如实
已实跑：账本只增不改与逐条相连，自上线起就在跑；日结双签按流程单日常封块，交班、接班各归其人；付款窄口与三层上限在生产环境里用着；分红看资金口径的看板已上线。
在途：月结按新口径的头一次实跑还没到；账户里有一笔替别人代管的钱要不要从基数里扣，口径还没定；没有发票的成本在税务上怎么定性，等一个月的数据攒出来再和会计定；两条判据要等业务自然发生才验得到——超定额被拦一次、创始人拨款时红线还在不在。写这一页的时候这几件还没跑完，所以这里写「在途」，不写「已完成」。
未实跑：这套机制只在一家公司、一套系统上跑过。它能不能迁到别的合伙结构、别的账上，我们没有第二次证据。