摘要

  • Steam转让保留游戏的商店页面、评论、玩家购买权益和愿望单历史；旧合作方的月度付款报表不会随应用自动移交。
  • 共享管理权不改变收款安排。共享财务数据还要单独授权，接收方用户也须具备财务查看权限。
  • 生效日、Valve批准、后台接口密钥切换和既有促销限制，决定了新发行商究竟接过哪些能力，以及何时能用。

游戏到了，财务还在等附件

设想一家发行商买下一款已经发售的游戏。商店里的评论还在，愿望单也没少，玩家照常打开作品。团队松了一口气：没有迁站，没有让老用户重新购买，也没有把积累多年的口碑清零。

财务问的第一句话却很扫兴：过去每个月究竟结算了多少钱？

这是一个假设交割场景。Steam官方转让说明给出的答案，比“游戏已经转过来”复杂。愿望单的全部历史随游戏向接收方开放；财务数据默认按各合作方获得该游戏款项的时期划分。新合作方默认看到转让之后的财务信息。原合作方的月度付款报表和付款历史，仍属于原合作方，不会自动转移。

同一款游戏可以带着完整的愿望清单搬家，却把旧账单留在上一张桌子上。对买家来说，拿到未来的生意和拿到解释过去生意的材料，是两件需要分别安排的事。

玩家看到的是连续性，买家接的是几套权利

保留原来的应用标识，有很实在的商业价值。Steam说明，转让不会中断或改变玩家的游戏购买权益，评论、论坛等社区内容也不受转让影响。新管理方接手后，可以修改商店页、发行商字段、素材、版本和价格；在主动修改以前，页面本身保持原样。

这让卖家积累的公众记录继续服务于同一款作品。买家不用重新向玩家解释“为什么你买过的东西现在成了另一个页面”。愿望单和关注者也继续附着于游戏，而不是跟着某个发行商账户消失。

不过，“所有公众入口都不变”仍然说得太满。官方文档另有一条：一旦发起转让，应用就会从原先列入的开发者或发行商主页中移除，完成后可以列入新的主页。游戏自己的页面与发行商的作品陈列柜，走的是两条不同的路。

这正是交接时容易被漂亮截图遮住的部分。游戏仍然卖着，既不能证明所有推广入口都已接好，也不能证明所有财务材料都已到齐。

销售历史能共享，付款报表不会自动变成新家的文件

Steam允许原合作方向接收方开放完整销售历史的查看权限。这给双方留下了办法，而不是把历史永久封死。但它需要明确安排，不能从“已接受应用转让”推导出来。

应用共享工具把财务查看列为可选授权。即使合作方层面的共享已经打开，接收方具体用户仍需要 View Financials 权限。公司有了入口，负责核账的人还得有钥匙。

这里还要分清两种数字。Steam的近实时销售与激活报告展示收入、销量等信息，但其中的收入数额不扣除退款、拒付和税费等项目。月度销售报告则包含更细的扣除项，反映实际应支付的金额，并可下载为CSV文件。

买家若想核对一款游戏过去的现金创造能力，只看到一条漂亮的实时收入曲线，材料仍然不够。应提前约定哪些销售视图开放、哪些历史月报交付，以及谁负责解释扣除项。平台上的数据共享与双方之间的文件交付，可以相互配合；一项完成不会替另一项签收。

官方资料没有给出缺失历史资料造成多少交割延误或估值折扣；需要实际转让、支持工单和结算记录才能量化。规则已经足够指出该提前谈什么：在旧发行商还有交接任务的时候，把旧账资料讲清楚。

能改商店页的人，未必能改价格

应用管理共享允许另一家合作方一起管理游戏，例如上传版本、编辑商店资料。它不改变付款规则。Steam把定价和折扣交给拥有该游戏收款权的合作方；具体操作用户还需要相应定价与折扣权限。

这使一种看似顺利的交接不那么完整：新团队已经可以更新宣传图，却还不能用自己的收款身份安排销售。双方可以先共享管理权，为过渡做准备；真正改变哪个合作方获得款项，需要应用转让。

共享本身由双方完成确认，不需要Valve批准；应用转让则包含平台审核。发起方提交接收人、生效日和理由，接收方接受，发起方再次确认，随后由Valve审查。双方操作的人都要具备相应的 Actual Authority 权限，接收方账户必须完成验证和入驻。

这不是在给一个用户多勾几个编辑权限。平台正在更换它承认的经营和收款主体。

生效日不是银行到账日

Steam将转让生效日定义为开始向新合作方分配付款的日期，系统默认设在发起转让七天之后。管理权在生效日移交；如果审批晚于这个日期，则在审批通过后立即移交。官方给出的通常审核时间，是双方全部批准后两个至七个工作日，不能拿来当整场交割的固定工期。

收款主体的分界日也不是现金当场进入银行的承诺。Steam付款说明用二月销售、三月底付款作例子。拿到下一阶段的收款权，与拿到已经结算的现金，隔着报表和付款周期。

因此，交割日、平台批准日、管理权实际到手的时间和款项对应的销售期间，都值得分别写清楚。否则，一句“月底过户”可以让商务、技术和财务各自理解出一个不同的月底。

新发行商不能给游戏洗掉旧日历

转让还有一些不会陪着新名字一起重置的东西。

现有捆绑包的管理权不随游戏转让。需要移出的游戏可以由原方提前处理，或者把原捆绑包改成协作捆绑包；转让后也有联系支持移出的路径。新发行商接到一款游戏，未必就接到了所有包含它的销售组合。

折扣冷却期同样保留。通常折扣之间有三十天间隔，四次全站季节促销有特定豁免，但发售和涨价带来的三十天限制仍适用于季节促销。转让本身不会重置或缩短这些时间。新东家想办一场“接手庆典”，日历可能已经被旧东家用过。

如果游戏后台使用发行商API密钥处理微交易或权益验证，密钥也不会随应用过去。官方过渡流程要求保留必要的临时管理共享，由接收方建立自己的新密钥，切换服务器并验证功能后，再结束旧方的共享访问。这里没有要求一并开放财务数据；运行连续性与账目可见性仍然是两种授权。

玩家最好感受不到这场搬家。发行商恰恰要把搬家的每一项看清楚。商店页接过来了，旧报表交付了吗；版本能更新了，收款方换了吗；钥匙换好了，旧门还开着吗。游戏可以平稳过户，前提是双方别让“转让完成”替整张交接清单回答问题。

原始资料

Steam应用转让说明、应用管理共享与财务查看授权、销售报告与付款说明、折扣权限与冷却期规则。