打开 App Store Connect 或 Google Play Console，你会看到一个感觉像是你的收入的数字。上个月它显示为10,000美元。你的银行账户收到了7,000美元。这两个数字都没有错——但只有一个应该作为“收入”出现在你的损益表上，而弄反了这个决定可能会悄悄扭曲你的毛利率、错误陈述你的增长率，并向贷款人或投资者提供一幅不真实的业务状况。
这就是主要责任方与代理人问题，根据美国公认会计准则（GAAP）的ASC 606收入确认标准，这并非可有可无的文书工作——而是一项规则，决定了你是报告10,000美元的收入和3,000美元的销售成本，还是只报告7,000美元的收入，别无其他。对于通过苹果App Store或Google Play Store销售的独立开发者来说，答案通常令人惊讶。
每个应用开发者最终都会问的问题
触发点几乎总是相同的：一位创始人在制作融资演示文稿、申请小企业贷款，或者只是想回答“我这季度实际赚了多少”时，意识到他们一直将银行账户收到的任何款项都记录为“销售额”。这个数字是扣除苹果或谷歌佣金后的净额——也就是说，平台的抽成已经被减去。
问题在于，将收入与平台费用抵消并非风格选择。ASC 606对此情况有专门的测试，其核心在于一个问题：在商品与客户交易之前，谁控制着所售商品？
通俗解释ASC 606控制测试
ASC 606的五步收入模型要求你识别合同中的履约义务，并确定谁在履行这些义务。当市场或平台介于你和终端客户之间——苹果、谷歌、Etsy、DoorDash、Uber——会计准则称此为主要责任方与代理人评估，普华永道的收入指南指出，应用商店销售是需要仔细审视这种安排的典型例子。
- 主要责任方：你在商品或服务转移给客户之前控制它。你应将客户支付的全部总额确认为收入，平台的佣金则成为销售成本（一项费用），而非收入的减少。
- 代理人：平台控制着所提供的产品，你只是代表他人安排销售。你只应确认你保留的净额作为你的费用。
根据德勤和普华永道框架，有三项指标决定你是哪一方：
- 履约责任——如果应用无法运行、订阅未交付或客户投诉，谁来负责？通常是你，开发者，而不是苹果。
- 转移前的风险——谁承担“库存”（你的应用、内容、订阅层级）卖不出去或无法满足客户的风险？同样，通常是你。
- 定价决定权——谁决定客户实际支付的价格？你选择应用的价格层级；平台不会逐笔与你协商。
由于大多数独立开发者控制产品体验、拥有客户关系（包括支持和更新）并自行定价，他们在测试中落在主要责任方一侧——这意味着正确的会计处理是记录客户支付的总金额为收入，并将苹果或谷歌的抽成视为收入成本项目，而不是一笔隐形的削减。
抽成背后的数字
知道你是主要责任方只有在你了解实际被扣除的金额时才有意义。过去几年，平台费用结构发生了重大变化，而大多数开发者仍在基于过时的假设进行预算：
| 平台 | 标准费率 | 降低费率 | 符合条件者 |
|---|---|---|---|
| 苹果App Store | 30% | 15%（App Store小企业计划） | 年应用商店收入≤100万美元的开发者 |
| 苹果订阅服务 | 30%（第一年） | 15%（第二年及以后） | 超过首12个月的任何订阅 |
| Google Play | 30% | 第一笔年收入100万美元的15% | 所有开发者，自动分级 |
| Google Play订阅 | 15%固定 | — | 所有订阅收入 |
| 苹果欧盟（数字市场法案条款） | 约17% + 核心技术费 | 合计最高约20% | 选择加入欧盟替代商业条款的开发者 |
此外，还有大多数人忘记分配的年固定费用：苹果每年99美元的开发者计划费，以及谷歌一次性25美元的注册费。金额虽小，但也应归入你的会计科目中的某个位置——通常作为一般运营费用，而非销售成本。
正确记录：一个示例
假设一位客户通过苹果购买了一笔9.99美元的应用内订阅，而你处于标准30%费率下。苹果从客户处收取9.99美元，保留3.00美元，最终向你的银行账户存入6.99美元。将6.99美元记录为“收入”会使你的营收被低估30%——这在以下情况下至关重要：你将增长率与直接销售的竞争对手进行比较，或向贷款人解释你的利润率。
正确的分录应确认全部销售额，然后单独将佣金记为费用：
2026-07-18 * "苹果" "iOS订阅——销售总额"
Assets:Receivable:AppStore 9.99 USD
Income:AppSales -9.99 USD
2026-07-18 * "苹果" "30% App Store佣金"
Expenses:CostOfRevenue:PlatformFees 3.00 USD
Assets:Receivable:AppStore -3.00 USD
2026-07-20 * "苹果" "收到付款"
Assets:Checking 6.99 USD
Assets:Receivable:AppStore -6.99 USD注意，一旦付款结清，应收账款账户净额归零，但你的损益表仍显示9.99美元的收入和3.00美元的收入成本——该笔销售的毛利率为70%，而非神秘消失的30%。这正是纯文本、版本控制的分类账擅长处理的交易类型：销售总额、平台费用和付款是三个独立、可审计的事件，而非一笔模糊的银行存款。
为什么仪表盘上的数字不够
即使你知道了规则，手动应用它也比听起来困难。标准的App Store Connect和Play Console报告显示汇总总数，而非ASC 606技术层面要求的用户级别、交易级别明细——收入、退款和货币兑换通常在实际销售数天或数周后以单笔总额形式呈现。这种差距正是越来越多的订阅应用企业使用平台API或RevenueCat等工具重建逐笔交易明细，而非试图从月度摘要PDF中反向推导的原因。
跳过这一步会产生实际成本。一个广泛引用的例子：一位开发者看到仪表盘当月显示3,400美元，但在扣除佣金、税款和其他平台扣费后，实际可支配金额仅为1,294美元——他们以为的“收入”与企业实际保留的金额之间存在超过60%的差距。那些依赖仪表盘数字而非对账后数字做出招聘或支出决策的开发者，是在针对一个从未真实存在的数字进行预算。
扭曲账簿的常见错误
- 仅将净存入资金记录为收入。 这是最常见的错误，也是本文讨论的问题——它会同时低估收入和销售成本，使你的毛利率状况变得毫无意义。
- 忽略退款和退单。 苹果和谷歌都会代表你处理客户退款，有时在原销售数周后——如果你不按交易对账，已退款的收入可能无限期留在你的账簿上。
- 将99美元的苹果开发者费或25美元的谷歌注册费混入销售成本。 这些是固定运营成本，而非交易级别佣金——它们应完全属于不同的费用类别。
- 忘记欧盟的单独费用表。 如果你的任何部分用户群在欧盟且你已选择苹果的替代条款，则该收入的佣金结构与其他业务不同，需要单独的账户。
随着业务扩展保持财务有序
无论你是拥有一个应用上架的独立开发者，还是运营拥有少量订阅产品的小工作室，总收入与净收入的决策每个月都会因你记录错误而累积——到你需要融资或申请融资时，被低估的营收线是难以解释的。Beancount.io为开发者提供了纯文本、版本控制的分类账，专为这种多步骤交易而构建——销售总额、平台佣金和付款作为三个独立、可审计的条目，而非一笔模糊的银行存款。立即免费开始，看看那些已经用代码思考的开发者为何更喜欢以同样方式运作的会计。