solo 最小财务驾驶舱：MRR/COGS/Runway 的跟踪方案

B 方向·OPC 最佳实践（财务可见性维度）。opc-china-money-repatriation 解决了钱怎么回来，本篇解决「看得清」。

背景与问题

多产品+多通道（Paddle/电汇/Payoneer）的 solo，最小可行的财务跟踪是什么？什么时候从表格升级到工具？

发现

• indie 阶段的共识做法：Google Sheets 手搭指标面板（MRR/新增 vs 流失/COGS/runway），有公式级教程（ModelMonkey 指南）与现成模板（Taskade 5 模板、Coupler.io）；社区里 DIY 派用 Sheets/HTML 面板跑 base/乐观/悲观三情景 runway（r/SaaS 讨论）。
• 阶段化指标：pre-revenue 只盯 burn/runway，有收入后加 MRR 明细与 churn，规模化才上 CAC/LTV（FutureProof 分阶段指南）。
• 工具升级路径：Sheets → 自动化现金流工具（如 Trezy 类，实时 MRR/churn/runway，Trezy）——多数 indie 的判断是月账单复杂到 Sheets 维护 >1 小时/月时才升级【推测：社区共识倾向】。

结论

可行动启发：

1. 一张 Sheet 六格起步：月度净现金流 / MRR（按产品分行）/ 通道成本（Paddle 5%+$0.5+提现费）/ COGS（LLM+LINE 额度+POD）/ runway 月数 / 产品级毛利率——每月 1 日更新一次 30 分钟，先售后砍检查序（opc-exit-microacquisition）直接引用此表。
2. 产品级 COGS 分摊是本管线的特殊需求：共享基建（LINE OA/Paddle）按用户数分摊到各产品，否则单品毛利率失真——组合决策（opc-product-portfolio-strategy）依赖这个数字。
3. 数据源自动化按最小化原则：Paddle 有报表导出，先手动粘贴月度汇总；API 自动化只在「手动 >30 分钟/月」时才做（避免为工具而工具）。
4. 与税务申报同源：这张表就是年度汇算清缴（opc-china-money-repatriation）的收入底稿——一套数据两用。

待办 / 下次继续

• Sheets 模板初建（首个产品上线时激活，含产品级 COGS 分摊公式）。
  
• ModelMonkey 教程细读，抄公式结构。
  

关联

• 数据下游：opc-exit-microacquisition（可售性评估）、opc-product-portfolio-strategy（组合取舍）、opc-china-money-repatriation（报税底稿）。