三端资金体系总览

所属：Paisa 运营人员指南 · 第 11 篇
上一篇：资金统计报表口径 · 导读：运营指南导读

本篇把平台里 三类账户主体——商户、代理、App用户——的资金体系一次讲清：钱从哪来、到哪去、中间会经过哪些"卡住不动"的状态、以及每一种让余额发生变化的途径。第 3 篇讲 LOCAL 代收/代付在各节点的逐笔变动，本篇做主体化的总览与对账地图；第 10 篇讲这些资金如何汇成日报表。三篇配合使用。

时区：文中所有时间均指印度时间（IST，UTC+5:30）。
币种：INR（卢比）为平台内记账币种，底层以「分（paise）」存储；USDT 仅在充值/提现的链上环节出现，入账/出金时按锁定汇率换成 INR。

1. 三类账户主体一览

三本账互相独立：

• 代理"拉人头"赚的是 佣金账户（未结算/冻结/已结算），和他本人如果也作为App用户参与时的"App用户余额"是两回事。
• 邀请返佣（拉新人得的奖励）直接进 邀请人的App用户余额，走用户账户流水，不进代理佣金账户。这两条"返钱"的线要分清（见第 4 节）。

2. App用户账户

2.1 账户构成

• 可用余额：App 里看到的、能拿来接单/提现口径的钱。
• 代收冻结登记：每笔 LOCAL 代收会登记一笔占用（详见第 3 篇），它与可用余额联动，决定"可接单总额"。
• 内部代付冻结：内部代付（平台内买卖双方对撮）时对出款方的临时占用。

展示总额（App / Telegram / 账户总览统一口径）：

展示总额 = 可用余额 + 处于「冻结中 / 延迟消费」的代收冻结登记金额

2.2 资金来源（钱怎么进App用户账户）

2.3 资金去处（钱怎么出App用户账户）

App用户没有独立"提现"：App用户不直接提现 USDT（提现主体是商户与代理）；其价值实现主要通过买卖价差与接单收益。

2.4 中间态（钱卡住、暂时不能动的状态）

延迟消费不增加可接单额度：新单派单仍要求裸可用余额 ≥ 订单金额。详见第 3 篇 2.8。

2.5 动账途径速查（用户账户流水类型）

3. 商户账户

3.1 账户构成

商户总资金 = 可用余额 + 代付冻结池。代付创单只是把钱从"可用"划到"冻结池"，总资金不变，直到代付真正成功才减少。

3.2 资金来源（钱怎么进商户账户）

3.3 资金去处（钱怎么出商户账户）

3.4 中间态

3.5 动账途径速查（商户账户流水类型）

对账要点：判断商户是否有"真实资金变动"，看流水里的真实变动金额——只有冻结/解冻的记录该值为空，真正进出账才有非空数值。

4. 代理账户（佣金账户）

4.1 账户构成

4.2 资金来源（佣金怎么计提）

计提时同时累加代理的"累计团队交易额""累计佣金"，并写代理佣金明细。计提有父/子两级：同一笔业务可同时给子代理和上级父代理各记一条。

4.3 资金去处

4.4 中间态

4.5 动账途径速查（代理佣金流水）

两条"返钱"线务必分清：

• 代理分润 → 进代理佣金账户（未结算），提现才出金；
• 邀请返佣 → 直接进邀请人的App用户余额（用户账户流水的"邀请佣金"），即时到账。 报表第 10 篇里"代理奖励"是计提口径（应计），不是当日现金流出。

5. 资金全景流转图

图为主干示意：代收/代付的各类超时、取消、补单、延迟消费等细分状态见第 3 篇。

6. 中间态总表（所有"卡住不动"的钱）

7. 对账与风控要点（客服/风控排查用）

1. 账实一致：
   • 用户侧：可用余额应对齐用户账户流水净额；
   • 商户侧：可用余额 + 冻结池，应对齐商户流水的真实变动累计；
   • 代理侧：未结算 + 冻结 + 已结算，应对齐佣金明细。
2. "钱去哪了"三步法：先分清是哪个主体 → 再看是不是在中间态（冻结/延迟消费）→ 最后查动账流水。
3. 代付/提现是"划转+出账"两段：只看到冻结增加不等于钱没了；只有"成功/审核通过"才是真正出账。
4. 重复入账/异常放大：USDT 入账、佣金计提均有幂等与唯一性保护；若发现同一笔业务重复到账，立即上报研发（历史事故见资金安全规范）。
5. 口径差异：报表净利润、工作台净利润、账户实际余额三者口径不同（是否含人工调账、USDT 差价、提现等），对外解释前先确认用的是哪套口径（见第 10 篇）。

8. 相关章节

• 第 3 篇：三端账户余额怎么变：LOCAL 代收/代付逐节点的资金变动、解冻/掉线不加回口径。
• 第 10 篇：资金统计报表口径：以上资金如何汇成按日报表、收支与净利润。

导读 → 运营指南导读