Summary

  • Steam app transfers preserve the game’s customer ownership, community and wishlist history. The former partner’s monthly payment reports do not travel with it.
  • Shared management access leaves payment arrangements unchanged. Historical sales visibility, individual financial permissions and delivery of old reports require separate attention.
  • The effective date starts the new partner’s payment entitlement; it is not a bank-payment date. API keys, bundles and existing discount restrictions have their own handover rules.

The audience has arrived. Accounts is still waiting

Imagine a publisher acquiring an established game. The store page looks reassuringly familiar. The reviews are there, the community is there, and the wishlist history reaches back before the deal. Then the finance team asks for the old monthly payment reports. Those are still attached to the previous partner.

That scene is hypothetical. The separation is written into Steam’s transfer documentation. A buyer can inherit the public history that helps sell a game without automatically receiving the documents that explain what its previous publisher was paid. The applause moves more easily than the accounting.

It is an awkward distinction precisely because so much else continues to work. The game keeps its application identifier. Customers retain ownership. Reviews, forums and other community material stay with the application. The new partner can change the store page, update the publisher listing and upload new content. Steam hands over a working commercial surface, complete with its accumulated public reputation.

But a commercial surface has several custodians. The account that can change a screenshot, the partner entitled to payment and the person allowed to inspect financial information need not all change at once. Treating the transfer as one large switch gives the prettiest part of the handover too much credit.

A sales curve is not a payment report

By default, a partner sees financial information for the periods in which it was entitled to receive payment for the application. The new partner’s view begins with the transfer. The transferor can grant access to the full sales history through application sharing. Its monthly payment reports and payment history, however, belong to the former partner and do not transfer with the game.

Those are different kinds of evidence. Steam’s near-real-time Sales & Activations report provides revenue and unit information. The revenue figure is before deductions for refunds, chargebacks and taxes. The monthly report includes the more detailed deductions and reflects the amount payable. It can be downloaded as a CSV file.

A buyer trying to reconcile earlier receipts therefore has two requests to make: access to historical sales data, and delivery of the relevant earlier payment reports with whatever explanations are needed to reconcile them. Granting one does not supply the other. A handsome curve in a dashboard cannot answer a question whose missing terms sit in a monthly statement.

Financial access also has an internal gate. When a partner shares an application, it can separately enable access to financial data. Users at the receiving partner still need the View Financials permission. Company-to-company cooperation is only half the journey if the employee doing the reconciliation cannot open the figures.

The public documents give no count of transfers delayed by missing reports or any resulting acquisition-price discount; matched transfer, support and settlement records would be needed to measure that. The practical order is already clear. Agree on the evidence before the seller’s incentive to explain its old numbers has dwindled to a polite favour.

The person editing the shop may not control the till

Steam’s application-sharing mechanism lets partners cooperate on management without changing who gets paid. It requires agreement between the parties rather than Valve’s transfer approval. A new publisher can consequently have useful access before becoming the payment recipient.

Pricing exposes the distinction. Only the partner receiving payment can set prices and discounts. The individual making the change must also hold the relevant pricing permission. Someone able to replace a trailer may still be unable to launch the celebratory sale.

The formal transfer changes the partner relationship. Both sides need a user with Actual Authority, and the recipient must be fully onboarded and verified. The initiating partner chooses the recipient, reason and effective date. The recipient accepts; the initiator confirms again; Valve reviews the request.

Valve says its review normally takes two to seven business days after both parties have fully approved. The days spent finding the authorised person or completing the recipient’s setup come earlier. A calendar invitation titled “handover” cannot persuade those prerequisites to disappear.

Three clocks on the same desk

The default effective date is seven days after initiation. It marks when payment entitlement begins for the new partner. Management rights move on that date, or immediately after approval if approval arrives later. Only the initiating partner can choose the date.

Payment entitlement has a different clock from bank receipts. Steam’s payment guidance uses the example of February sales being paid at the end of March. A transfer date allocates the earnings between partners; it does not promise cash in the new partner’s bank account that day. Planning a transition around a single “money moves” date confuses an allocation rule with a payment cycle.

A third clock may already be running in the discount system. An application transfer does not reset or shorten existing cooldowns. The standard interval between discounts is thirty days, with an exception for the four seasonal sales. Release-related and price-increase cooldowns still apply to those seasonal sales. Raising a price in any currency can start the applicable price-increase cooldown.

So a transferred game may be perfectly operable while the intended promotion remains unavailable. The transfer has not imposed a fresh universal thirty-day wait. It has preserved the consequences of earlier pricing decisions. The new publisher inherits a calendar as well as a catalogue entry.

Some connections need a deliberate changeover

Publisher API keys do not transfer. Where a game’s backend uses them for functions such as microtransactions, authentication or entitlements, the receiving partner needs its own keys. Valve’s documented transition can retain the necessary temporary management sharing, allow the new partner to create keys after approval, update the server, verify the change and then end the old sharing. Financial access is unnecessary for that technical bridge.

That sequence matters to games using those functions. It gives a reason to keep a bounded overlap between old and new operators until the replacement connection works. Ending every old permission on the ceremonial transfer date can fight the very handover it is supposed to complete.

Bundles are another surviving connection. Management of existing bundles does not automatically transfer with the application. The parties may need removal from an old bundle, a collaborative arrangement or assistance from Steam support after the transfer. The application has changed partners; every surrounding commercial arrangement has not thereby rewritten itself.

Even the public surface has a small, specific discontinuity. Although the store page and community persist, initiation of a transfer removes the application from Developer and Publisher Homepages. The new partner can list it on its own homepage after completion. “The audience stays” is a useful description of the core continuity. It still leaves a discoverability task for the incoming publisher.

Buy the history while somebody still remembers it

Steam’s design preserves something a game buyer has reason to value: a recognisable product with customers, conversation and accumulated demand. It also keeps partner-level payment records attached to the partner that received the payments. Each rule is understandable on its own. Together they create work that a clean-looking store page conceals.

The sensible handover therefore includes an unglamorous delivery: historical reports, agreed sales visibility and a person who can explain the reconciliation. Operational access, replacement keys and the promotion calendar can then be scheduled around their actual dependencies.

The buyer’s worst moment to discover the difference is after the transfer has been celebrated and the seller’s staff have moved to their next project. Steam can preserve years of players’ opinions. It cannot make the former publisher’s finance team remain interested in yours.

Sources: Steamworks’ official guidance on application transfers, sharing application management, payments and sales reporting, and discounting.