一、先把问题改写成可以找证据的问题
“游戏分成怎么纳税”通常同时混合了主体、权利、履约和收入记录四个问题。研究建议先问：是哪一主体、哪一期间、哪份合同下的交易；对方取得什么权利；谁实际完成开发、发行或运营；账单中的金额分别对应什么事项。这样才能确定美国规则是否与本案相关，避免看到海外平台就套用美国分类。
美国相关国际税收规则在其适用范围内，区分数字内容的版权权利转让、内容副本转让、开发或修改服务，以及开发专有技术提供。具体交易仍须结合合同和事实判断，不能把所有游戏分成都定为许可收入。【GAMES-US-CLASSIFICATION｜26 CFR §1.861-18(b)(1)；该节点适用于 2025 年 1 月 14 日或之后开始的纳税年度；纳税人可在满足该条规定条件时选择提前适用于 2019 年 8 月 14 日起的年度】
这四类是分析入口，不是见到某个合同标题便得出结论的快捷菜单。合同叫“联运”，并没有替我们回答对方能否复制、修改或再许可；账单写“分成”，也没有替我们回答收入归属和税务处理。研究工作的第一项交付，应是能够支持分类的事实清单及证据索引，而不是先给一个确定税目。
二、把发行关系拆为权利、履约和结算三张图
权利图记录源代码、美术、商标等材料由谁控制，合同授予什么地域、期限及权限。资料可以包括主合同、补充协议、外包成果归属文件和源代码管理权限摘要。记录已有文件说了什么，同时保留文件与实际活动不一致的地方。
履约图记录谁研发、谁发布版本、谁运营服务器、谁处理玩家支持、谁决定更新。研究人员应区分“有权做”和“实际做”，不要将合同权限直接等同于真实活动。这里采用事实整理方法，尚未据此作任何国家的税收居民、常设机构或关联交易结论。
结算图从平台原始账单逐项连接至总账及银行入账，分别列出渠道扣费、退款调整、税项和净额。这个过程旨在解释差异，不预设会计收入应按总额还是净额列示，也不以净入账直接判断所得类型。
| 待决策事项 | 关键材料 | 本轮能够做什么 | 必须保留的边界 |
|---|---|---|---|
| 研发服务还是 IP 相关交易 | 委托范围、成果归属、权利清单、实际开发记录 | 在美国规则相关时组织分类证据 | 不按合同标题直接定性 |
| 自营、发行或代理安排 | 玩家条款、发行合同、履约和风险分工 | 重建交易关系，列出后续分析问题 | 不直接决定收入总净额口径 |
| 多种内容组合的合同 | 各项权利及履约内容、合同整体目的 | 识别需要进一步分析的组合事项 | 不强行拆成单一简单类别 |
| 平台结算与账务不同 | 原始账单、调整说明、总账、入账记录 | 形成可复核的差异桥接 | 对账完成不等于税务结论完成 |
上表中的分类入口来自美国数字内容规则；其余是组织证据的研究方法。混合交易仍需按同一规则相应条款进一步判断主导性质，不能把四类入口误读为自动拆分义务。【GAMES-US-CLASSIFICATION｜26 CFR §1.861-18(b)(1)，混合交易适用限定见 (b)(2)–(3)】
三、欧盟数据问题要另开一条事实链
未在欧盟设立机构的企业，相关个人数据处理如涉及向欧盟境内个人提供商品或服务，或监测其在欧盟境内的行为，也可能落入 GDPR 的适用范围。因此，不能仅凭企业注册地或玩家国籍判断是否适用。【GAMES-EU-SCOPE｜Article 3(2)】
建议以具体处理活动为单位整理资料，而不是只制作一张服务器分布图。每项活动至少记录面向何地玩家、获取哪些字段、何时触发、用于什么目的、由谁决定用途、交给哪些主体、保存安排和可用证据。服务器位置是事实之一，不能替代目标市场与行为事实。
适用 GDPR 时，直接向玩家取得个人数据，应在取得时说明处理目的与法律依据；处理活动本身还须满足相应合法性条件。目的与依据只是告知内容的一部分，不能把这两项写进文案就称为已完成全部隐私要求。【GAMES-EU-NOTICE｜Article 13(1)(c)，合法性条件见 Article 6(1)】
这里需要分开检查“实际做什么”和“对玩家说什么”。如果 SDK 实际用途不明确，先补数据字段、触发条件和供应商使用说明；不要用一段笼统文案覆盖未知活动。对于是否适用、可用何种依据等问题，底稿应记录尚缺事实及负责确认的人，不用默认勾选代替判断。
四、供应商角色不能只看合同名称
适用 GDPR 且供应商作为处理者代控制者处理个人数据时，相关处理应由有约束力的合同或法律文件规范，并列明处理对象、期限、性质、目的、数据类型及双方权利义务。该要求具有角色前提，不能把所有 SDK、平台或发行商一律认定为处理者。【GAMES-EU-PROCESSOR｜Article 28(3)】
研究建议先对每个供应商做事实访谈：它是否仅执行约定用途，是否另外决定使用方式或目的，产品配置能否关闭相关功能，实际资料流向与合同是否相同。底稿可以提出角色疑问，但本篇未逐一核对共同控制者等完整规则，不能据这些疑问直接给出全部角色义务结论。
SDK 底稿字段建议为：组件名称与版本、触发页面、字段类别、处理目的、目标玩家地区、决定用途的主体、接收方、角色判断及理由、合同条款、界面告知位置、未解问题、责任人、证据文件。制作底稿时使用字段说明与模拟记录，不写入真实玩家标识。
五、儿童路径需要先满足条件，再看年龄
适用 GDPR、以同意为依据且直接向儿童提供信息社会服务时，儿童自行同意的基准年龄为16岁；成员国可以降低该年龄，但不得低于13岁。低于适用年龄时，须由监护责任持有人作出或授权同意。这不是全球统一游戏年龄限制，也不替代成员国合同法和其他儿童保护规则。【GAMES-EU-CHILD｜Article 8(1)】
因此，设计儿童路径之前，至少先确定目标成员国、相关处理目的与所用依据，再核验该国适用年龄原文。当前未完成逐国原文核对，不提供成员国年龄表，也不建议把基准年龄直接写成所有市场相同的注册规则。界面设计是判断之后的执行环节。
将两条研究线画成决策树，可以避免问题串线：
- 收入线：本笔交易是否涉及相应美国规则？若未知，补主体、期间和交易联系事实；若相关，再整理权利与履约，对照分类入口；遇到组合内容，转入更细分析。
- 数据线：具体活动是否可能落入 GDPR 范围？若相关，逐项明确目的与依据；供应商是否属于处理者，决定是否检查相应合同要求；如涉及以同意为依据的儿童服务，再核成员国年龄及流程。
上述顺序用于管理研究任务，不能替代法律适用分析。【GAMES-US-CLASSIFICATION｜26 CFR §1.861-18(b)(1)；GAMES-EU-SCOPE｜Article 3(2)；GAMES-EU-NOTICE｜Articles 13(1)(c)、6(1)；GAMES-EU-PROCESSOR｜Article 28(3)；GAMES-EU-CHILD｜Article 8(1)】
六、可执行资料包与验收方法
第一包是合同与 IP：发行、研发外包、许可及补充文件，另附权利表。第二包是结算：一笔脱敏账单、对应调整、总账和入账样本。第三包是数据：目标地区、SDK、字段、用途、供应商条款、现有玩家说明及儿童路径。每份文件标记版本、适用期间和提供者，避免把旧合同和新业务拼成一个事实模型。
验收不以资料数量为标准。可请未参与整理的人抽取一项收入和一项 SDK 活动，沿底稿返回原始证据，复述哪些已经证实、哪些仍未知。再用历史合同或 SDK 版本变化回放，观察新底稿能否在上线前发现后来才暴露的缺口。没有历史样本时，应将效果标为尚未验证。
七、练习与阶段结论
示例：某研发团队收到海外发行商分成账单，同时拟为欧盟市场接入分析 SDK。团队认为“账单叫分成，所以都是许可收入；SDK 合同写处理者，所以只需统一勾选同意”。请分别给收入线和数据线列出三个最先补充的问题，并为每个问题指定一份原始材料。
判断边界：收入线需权利清单、实际履约及美国规则关联事实；数据线需目标地区、字段用途、真实角色与所用依据。不能直接确定所得类型、全球统一年龄或 SDK 完整角色义务。分类入口、地域适用和处理者合同要求均有条件，表面名称不能代替相应事实。【GAMES-US-CLASSIFICATION｜26 CFR §1.861-18(b)(1)；GAMES-EU-SCOPE｜Article 3(2)；GAMES-EU-NOTICE｜Articles 13(1)(c)、6(1)；GAMES-EU-PROCESSOR｜Article 28(3)】
本篇不涉及游戏内容许可、分级、广告、随机道具与完整消费者规则，也不据此得出“可以上线”的结论。
官方原文索引
- 美国财政部 T.D.10022：数字内容和云交易分类：https://www.irs.gov/irb/2025-08_IRB；定位：26 CFR §1.861-18(b)(1)。
- 欧盟 GDPR 合并文本 02016R0679—04.05.2016：https://op.europa.eu/o/opportal-service/download-handler?identifier=5f2552c2-cc45-11e6-ad7c-01aa75ed71a1&format=pdf&language=en&productionSystem=cellar&part=；定位：Article 3(2)；Article 13(1)(c)；Article 28(3)；Article 8(1)。
本文法源核对时点：2026-11-02。本文为研究说明，不构成对任何具体交易或主体的税务或法律意见；适用时须以最新原文与完整事实为准。