App Store Connect 显示你上月卖出了 3,108。你加起来，对 6,580，Google 汇来 $2,210。没人偷你的钱。每一分不见的钱都有名字：增值税、佣金、退款、预扣税、货币兑换，最后还有所得税。问题不在于差额本身——而在于大多数独立开发者没有一本能解释差异的账本，所以他们无法回答三个真正重要的问题：我的定价对吗？我的佣金率是否正确？我的现金流预测靠谱吗？
本指南带你走一遍从标价到实际到手的完整流程，解释为什么付款永远不等于报告数字，并给你一个每月约30分钟的对账流程，一旦设置好就能持续运行。
三个数字，三个不同答案
每个应用业务都有三个收入数字，混淆它们就是混乱的开始：
- 总销售额 —— 客户支付的钱，显示在分析仪表盘中。这是面子数字。它包含商店代收的税费，而且通常是一个估算值，之后会调整。
- 开发者收益 —— 商店说你赚的钱，来自月度财务报告（Apple）和收益报告（Google）。这是扣除佣金、商店代收代缴的税费、退款和拒付后的净额。你的会计应该建立在这个数字上。
- 付款 —— 银行入账。收益减去任何预扣税，经货币兑换调整，并受最低支付门槛和商店支付日历的约束。
如果你的账本只记录银行入账，你的收入就会在不知不觉中被低估，并且延迟一个月或更久。如果记录总销售额，收入则被高估30–50%，而且与你实际收到的任何钱都对不上。App Store 记账的全部艺术在于把这三个数字串联起来，让每个月在报告收益和实收现金之间零差异地结账。
从标价到实际到手的流程
以一个在增值税20%的国家、按标准30%佣金售出的 €9.99 订阅为例。以下是诚实的版本：
| 步骤 | 计算 | 剩余 | 占标价百分比 |
|---|---|---|---|
| 标价 | — | €9.99 | 100% |
| 商店代收代缴的增值税 | €9.99 ÷ 6 | €8.33 | 83% |
| 商店佣金（标准费率） | 30% × €8.33 | €5.83 | 58% |
| 退款与拒付（假设3%） | 3% × €5.83 | €5.65 | 57% |
| 有效30%的所得税 | 30% × €5.65 | €3.96 | 40% |
大约60%的标价永远到不了你的口袋。在没有数字商品税的美国州销售会从更高的基数开始，而享受降低佣金率的开发者能保留更多（同样的增值税地区销售按15%佣金计算，退款前净得 €7.08——约为标价的71%）。具体百分比取决于你的销售组合，但结构性教训在任何地方都成立：总收入不是你的钱。它是商店的钱经过你的仪表盘。
这些都不隐蔽。Apple 和 Google 的项目条款写明了每项扣除。大多数独立业务缺少的是追踪——一个让流程的每一层成为记录在案、可审计的事实，而不是每月意外的地方。
你实际支付的佣金率
这个领域中最昂贵的记账相关错误之一就是佣金率不对。两家商店都为较小的开发者将佣金减半，而且并非所有地方的注册都是自动的：
Apple 的 App Store 小型企业计划将付费应用、应用内购买和订阅的佣金从30%降至15%。资格以收益衡量——即扣除 Apple 佣金和某些税费及调整后的销售额，而非总额——要求你上一日历年在整个账户以及所有关联开发者账户（你拥有、控制，或由你或他人拥有或控制的任何账户）中赚取不超过 1 百万。有两个细节常让开发者踩坑：
- 如果你在年中跨过 $1 百万，标准30%费率适用于未来销售——已经按15%售出的销售不会被追回，并且如果次年收益回落到门槛以下，你可以重新获得资格。
- 费率变更在你注册获批后财政月结束15天后生效，所以延迟注册会浪费你待办清单中每一周的真金白银。
Google Play 的降低档位对你每个日历年赚取的前 $1 百万适用15%费率，超过部分的收益按30%计算——你通过在 Play Console 中分组关联账户并接受条款来注册。一个值得知道的结构性差异：在 Google 上，所有自动续订订阅从第一天起就按15%服务费收取，无论是否注册该计划。在 Apple 的标准费率下，订户在第一年支付30%费率，从第二年起降至15%——这是一个支持留存率的隐性论点，只有当你毕业离开降低计划后才真正重要。
如果你低于 $1 百万且未注册 Apple 的计划，修复这一点可能是你一年中 ROI 最高的十分钟：注册流程在 App Store Connect 的“协议、税务和银行”下。
为什么入账永远不等于报告
即使费率正确，收益和付款也会因各种机械原因而不同——每一项都应该在你的账本中有一行：
支付日历不是月度的。 Apple 在每个财政月结束后45天内付款，而且其财政月与日立月不对齐——一个财政月可能于12月27日结束，付款在1月29日到达。实际上差距约为33天。Google 在次月15日付款（如果15日是周末则顺延到下一个工作日）。如果你采用权责发生制，12月的收入是1月或2月中旬的现金，你的账本需要一个付款清算账户来桥接两者。
最低门槛会延迟小额付款。 Apple 只在你收益超过最低支付门槛后才付款，该门槛因银行所在国家和货币而异。淡月可能完全没有入账，余额会滚动结转——如果你不追踪，这看起来就像丢了 $30。
退款和拒付在收益前扣除。 商店追回全部交易金额，而你的退款率会因产品和地区而悄然变化。正确记账的话，这应该是退款出现在报告月份的冲减收入，而不是入账中的神秘扣除。
税费通过两扇门流动。 对于增值税和许多销售税，商店在税务上充当记录商户——例如在欧盟，Google 收取、代收和代缴增值税，所以你的收益按不含税基数计算，你通常不需要在这些国家申报增值税。另外，非美国开发者面临的美国预扣税适用于任何美国来源金额，如果你未在 App Store Connect 中提交 W-8BEN 或 W-8BEN-E（或 Play Console 中的对应表格），预扣率可能高达30%的固定费率。条约税率——或者仅仅因为付款通常来自商店的国际实体——可以将此降至零。无论哪种方式，预扣税都会表现为报告收益和入账之间的差额，而且通常可以作为抵免收回——如果你记录了它。
货币兑换是真实成本。 商店以你银行安排的货币付款，并沿途转换各地区的收益。外汇价差是一项没有发票的费用，所以唯一能看到它的方式是比较各货币的报告收益与入账金额。
大多数独立开发者搞错的会计问题
你的收入行应该显示总销售额还是净收益？对于绝大多数独立开发者，答案是净额。在适用于美国 GAAP（ASC 606）和 IFRS 15 的收入确认框架下，测试在于你是否是销售中的主要责任人——你是否在商品或服务转移给客户前控制它——还是代理人，其履约义务在商店完成销售时履行。当商店是记录商户、代收税费、设置支付通道、承担退款机制并按每笔交易向你支付净额时，商店是主要责任人，你的收入就是你的收益。记总销售额并将佣金作为费用会夸大收入，扭曲你计算的任何利润率，而且在有人查看时会误报税务。
第二个错误是时间：将银行入账记为当月的收入。入账结算的是上月（或上财政月）的收益。正确的模式是：
- 收入在销售发生时计提，使用商店的估算（如果实际数据尚未发布）。
- 在月度财务报告发布时调整到实际值，过账估算与实际的差异（几乎总是存在差异——货币、退款和延迟调整会保证这一点）。
- 付款到达时清算应收账款，任何剩余部分归入预扣税、外汇或门槛滚动结转——各入各账。
最后一点是核心：当每个剩余都有命名的账户时，非零差异就不可能被忽略，而且几分钟就能解释清楚。
每月30分钟的对账工作流程
- 下载实际数据。 从 App Store Connect 拉取月度财务报告（覆盖所有地区、带结算日期的详细版本）。从 Play Console 拉取收益报告。这些——而非分析仪表盘——才是你的源文件。
- 按地区和货币记录收益。 每个商店一条收入行，地区和货币在下面追踪。审计线索就在这里：当某天你需要回答“为什么3月欧盟收益下降了12%”时，你会希望增值税、佣金和退款分开列示，而不是一个混合数字。
- 过账估算与实际的调整。 仪表盘预测与报告之间的差异：通常是退款、货币和大额付款调整。
- 将退款和拒付记为冲减收入，在报告月份记录，并随时间观察比率——退款率上升是一个穿着会计外衣的产品信号。
- 将付款与应收账款对账。 入账到达时，将其与报告匹配。预扣税进入税收应收账户（通常可抵免）；外汇差异进入货币费用；低于最低门槛的短款留在清算账户直到下个月。
- 每季度核验你的佣金率。 在 App Store Connect 中检查你的小型企业计划注册和 Play Console 中的档位——特别是当你接近 $1 百万收益时，两家商店都会在未来的销售上改变费率。在发生之前模拟毕业：跨过门槛可能在年中重新定价你的整个利润率结构。
六步，一个月一次。回报不仅仅是干净的账本——而是定价决策、费率注册和现金预测都开始基于收益而非面子数字运行。
用纯文本追踪整个流程
这正是多层对账中纯文本记账大放异彩的地方。一个 beancount 账本为流程的每一层提供独立账户——income:appstore:ios、income:playstore:android、expenses:refunds、assets:receivable:payouts:apple、assets:tax-withheld——所以每月分录就是解释，每个数字都能追溯到一份可以多年后重新推导的下载报告。因为账本是文本，商店报告可以放在版本控制中，对账变成一次差异对比，而不是电子表格考古项目。如果你想要导入银行对账单和商店数据的机制，文档深入介绍了导入管道。
简化你的财务管理
App Store 收入是大多数开发者会遇到的最被针对你的对账收入：佣金、税费、退款和支付日历都在钱到达你之前从中扣除。保持一本反映这个流程的账本——而不是单一的“应用收入”行——是将混乱的付款变成透明、可审计系统的关键。Beancount.io 提供透明、版本控制且 AI 就绪的纯文本记账，让每份商店报告、调整和入账都保持可追踪。免费开始 让你的实际到手像你的代码一样清晰。