一笔钱只有一个付款人的时候，记账很简单。麻烦的是这几种：
- 民宿房费太贵，一张卡刷不下，三个人各刷了一部分
- 包车费两个人凑的
- 给朋友的生日礼物，大家分头出了钱
- 你先付了，朋友当场把他那份转给了你
一笔钱，好几个付款人。这时候最常见的两种「省事」记法，都会在最后结算时出问题。
一个例子：四个人，三笔账
A、B、C、D 四个人出去玩。
| 账目 | 谁付的 | 金额 | 算谁的 |
|---|---|---|---|
| 民宿 | A 1200 + B 800 + C 400 | 2400 | 四人均摊，各 600 |
| 包车 | D | 1000 | 四人均摊，各 250 |
| 一顿饭 | C | 600 | B 没去，ACD 各 200 |
民宿那一行就是多人合付：一笔账，三个付款人。
正确的算法：付款和分摊各算各的
每个人的净额 = 他垫付的总额 − 他该摊的总额。
| 垫付 | 该摊 | 净额 | |
|---|---|---|---|
| A | 1200 | 1050 | +150 |
| B | 800 | 850 | −50 |
| C | 400 + 600 = 1000 | 1050 | −50 |
| D | 1000 | 1050 | −50 |
净额加起来：+150 − 50 − 50 − 50 = 0，对得上。
结算：B、C、D 各转 A 50 元，三笔，结清。
合付那一笔在算法里没有任何特殊之处：付款一侧把三个人的钱分别加到各自的垫付里，分摊一侧照常按参与人摊。
错误记法一：先私下转一轮，再记成一个人付
这是现实中最常见的做法：
「房费我先全刷了，B 你把 800 转我，C 转 400，然后账本上就记我付了 2400。」
问题在于：B 和 C 转给 A 的那 1200 块，发生在账本之外。账本看到的是：
| 垫付（账本里） | 该摊 | 净额 | |
|---|---|---|---|
| A | 2400 | 1050 | +1350 |
| B | 0 | 850 | −850 |
| C | 600 | 1050 | −450 |
| D | 1000 | 1050 | −50 |
按这个结算，B 还要再转 850。可 B 其实已经私下转过 800 了——同一笔钱他付了两遍。
这种错误特别难发现，因为每一步看起来都合理：转账是真的，记账也是真的，只是两边没对上。要么就把它记成合付（A 1200、B 800、C 400），要么把那两笔私下转账也作为「已结清」登进账本。不能只留在聊天记录里。
错误记法二：拆成三笔
另一种做法是把民宿拆成三笔：A 付 1200、B 付 800、C 付 400，每笔都是四人均摊。
数学上，这和合成一笔的结果完全相同。但它脆弱：
- 统计失真。 回头看「住宿花了多少」，出现三条民宿记录，看着像住了三家。
- 改一处要改三处。 如果 D 最后没住，三笔的参与人都要把 D 去掉，漏改一笔，账就不平了。
- 参与人一不同就容易错。 三笔必须保持完全一样的参与人，这件事靠人手维护，迟早出岔子。
一笔账就记一笔。付款人有几个，就填几个。
合付还是代付，看钱从谁口袋出去
| 情况 | 记法 |
|---|---|
| 一个人全额付，其他人之后再还 | 代付：付款人只记他 |
| 几个人当场各付一部分 | 合付：付款人记这几个人，各写实际金额 |
| 大家事先把钱交给一个人，由他去付 | 合付：付款人是交钱的这几个人 |
| 一个人先付，别人事后转给他 | 代付 + 登记那几笔转账 |
判断标准只有一个：付款那一刻，钱实际是从谁的口袋里出去的。
两个容易漏的细节
付款金额必须等于总额。 有人用了优惠券、积分抵扣，按实际扣款记，总额也改成实际总额。手续费归刷卡的人自己，不进这笔账。
零头只在分摊一侧处理。 合付金额是真实发生的扣款，不会有零头；三个人分摊 1000 元才会出现 333.33 × 3 = 999.99 的问题。约定好让某个人多摊 1 分，别去改付款金额——那是事实，改了就和支付记录对不上了。
什么时候需要工具
偶尔一次合付，手算没问题。但旅行、合租这类场景里，合付往往和代付、不同参与人混在一起，好几十笔账。这时用一个支持一笔多个付款人的分账工具会省很多事：付款一侧和分摊一侧它会分开处理，最后直接给出净额和转账方案。挑工具时注意这一点——不少记账工具一笔只能填一个付款人，逼着你去拆账。
