The Cash in the Wallet Is Not Revenue Yet: Deferred Revenue on Virtual Currency, Battle-Pass and Subscriptions in Games (2026)

Regulatory note: As of 2026-07-25, this article relies on the periodicity and valuation provisions of the Tax Procedure Law No. 213 (in particular Art. 283 and Art. 287), the Uniform Chart of Accounts Communiqué No. 1 governing the chart of accounts (26.12.1992, Official Gazette No. 21447 bis), Article 10 of the VAT Law No. 3065 (the event triggering the tax) together with the Series No. 49 amendment to the VAT General Application Communiqué on the sale of cards/passwords/codes (18.01.2024, Official Gazette No. 32433), TFRS 15 (Revenue from Contracts with Customers) for entities subject to independent audit, and the relevant Revenue Administration rulings. The VAT character of a coin/code sale can vary with the specific facts and contract wording; for a critical transaction, consider requesting a private ruling for your own situation.

Your game is live. A player buys the 100-unit coin pack and the cash lands in the account. The instinct is simple: money is in, book the revenue. The most common — and most expensive — mistake in the field starts right here.

Because the cash in the wallet is not revenue yet. The player paid you against a promise: “when I spend this coin later, you will give me something.” Until you fulfill that promise, the cash in your hands is not revenue but a liability. Both the tax and the correct accounting are built on this distinction.

The 60-Second Answer

First separate the three products, because each has a different revenue clock:

• Virtual currency (coin/gem): If, by its legal and factual character, the coin is a “wallet” (purchasing power) used for products/services to be delivered later, and the entity’s performance continues up to the moment of use, then revenue arises as the coin is spent in the game. The unspent balance is recorded, at the moment of collection, in “deferred income” (account 380) and waits there. (If the coin is locked to a single specific service, the table changes — I address that below.)
• Battle-pass / season ticket: It covers a defined season (usually 1–3 months). The amount is recognized as revenue over the season’s duration, spread across periods.
• Subscription: The prepaid annual/monthly package is transferred to revenue at the end of each period, ratably over the subscription term.

There is one more layer: VAT runs on a different clock. On a wallet (purchasing-power) coin, no VAT arises at the sale; VAT arises when the coin is spent and turns into a concrete virtual good.

Battle-pass and subscription, by providing “access to a specific service”, are subject to VAT at the moment the access right is delivered/performed; if an invoice is issued before that, VAT arises then, limited to the invoiced amount, under VAT Law Art. 10/b. So in the same transaction, revenue can accrue on one clock and VAT on another.

The cost of using the wrong clock, in one sentence: if you book the whole collection as revenue up front, you pull your tax base forward — you pay corporate tax and advance tax while the cash is not yet profit.

Why is collection not revenue?

There are two core principles in commercial income: accrual and periodicity. Accrual asks that income be fixed in nature and amount; periodicity asks that this income be booked in the period it belongs to. Together they say: having collected in advance does not require you to book the revenue this period. The consideration for a service you have not yet performed is held back until the performance period.

The Tax Procedure Law builds this on the valuation side too. TPL Art. 287 requires income collected in advance that relates to future accounting periods to be valued by carrying it as a liability (the symmetric case for expenses is in Art. 283). In the Uniform Chart of Accounts this principle runs through two accounts:

• 380 — Deferred Income (current): the part of prepaid income relating to less than one year from the balance-sheet date.
• 480 — Deferred Income (non-current): the part relating to more than one year. At period end, the amount that falls under one year is transferred to 380.

How these accounts work is written plainly in the Uniform Chart of Accounts Communiqué No. 1: “Income collected in advance is recorded to the credit of this account. It is transferred to the relevant income accounts in the period it belongs to.”

The Revenue Administration likewise defines these accounts as “the accounts tracking income collected in advance that relates to a future accounting period” (ruling No. E-11395140-105[VUK-3-4192]-554230 dated 02.05.2025 — that ruling confirms the nature of accounts 380/480, not the timing of revenue for a game transaction; it is not a direct administrative opinion on game coins).

There is a further distinction: if the amount is an advance whose condition has not yet occurred and which is refundable, account 340 Advances Received on Orders is used; if it is income that is now definitively attributable to a future period, 380/480 is used.

Which one fits — and at which moment performance is rendered — is determined by the entitlement and refund terms in the contract. The “contract liability” of TFRS 15 does not automatically mean account 380 in the tax records.

In short, the mechanism is: cash comes in → (recorded to 340 or 380/480 by its character) → as the entity’s performance is rendered, the relevant amount is transferred to a 600-series revenue account. Revenue arises not with cash but with performance.

In most structures spending the coin is the moment that performance occurs; but this is not automatic — if the coin, once spent, buys timed access, hosting, or content to be delivered later, the revenue may spread to a further period. So “spending” is not the final trigger of revenue but the first step of the performance analysis.

A numeric comparison: the 100-unit coin pack

Assume a studio sells 100 units of coins (VAT excluded) in a month, and players spend 60 units of it that month. We leave cost and other base items outside for simplicity. Two accounting paths:

Item	(A) All as revenue at collection	(B) Revenue as spent (with the example’s wallet assumption)
At collection	100 units booked as revenue	100 units to 380 (liability)
That period’s revenue	100 units	The spent 60 units transferred from 380 to revenue
Period-end 380 balance	0	40 units (not yet spent)
Effect on taxable revenue base	100 units	60 units
Result	Early tax on 40 units of revenue not yet earned	The turnover follows actual performance

Path (A) taxes you this period on the 40 units the player has not yet spent. Some of the part players refund may genuinely never turn into revenue; the unused balance remaining with the entity may become revenue in a later period under the breakage policy (I address this separately below). In any case, path (A) makes you pay tax on that amount now.

Path (B) ties the turnover to performance; in terms of the periodicity of revenue, it reduces the early corporate/advance-tax effect. But note: periodicity is not a groundless deferral — in a structure where the coin’s performance is in fact completed at the moment of sale/activation, deferring the revenue also creates a penalty-assessment risk. The correct period is not a tactic; it is the real time of the performance in the contract.

Two technical warnings. First, principal-agent: when we say “the store collected 100 for you”, the store/platform may be either principal or agent under the contract. Whether the turnover is recorded gross (100) or net of the platform commission — and how refunds and chargebacks are treated — depends on this distinction; the figure is not fixed until the platform statement and the user agreement are examined (store commission’s gross/net and VAT-base dimension is a separate axis).

Second, inflation adjustment: the balances in 380/480 are non-monetary items; for taxpayers within the scope of inflation adjustment, whether these balances are subject to adjustment must be separately checked in the relevant accounting period.

For battle-pass the picture is similar: if a 90-day season ticket is sold for 900 units, the amount is spread over the season by the method that best reflects the nature of the performance in the contract (time-based if it is a matter of being available for access, or by a progress measure suited to phased delivery of content); if the season spans two tax periods, the portion falling in each period is booked as revenue separately.

For a subscription, the split is made by looking at the time remaining from the balance-sheet date: the part that will turn into revenue within one year is tracked in 380, the part with a term longer than one year from the balance-sheet date in 480; at each month-end that month’s share is transferred to revenue.

The decision matrix: which clock for which product?

Ask the right question and you will find the right period: “When do I render the performance for which this amount is the consideration?” The answer varies by product — and the revenue clock and the VAT clock need not be the same.

Product	Revenue-recognition trigger (TPL/periodicity)	VAT trigger (VAT Law Art. 10)	Note
Virtual currency (coin/gem) — wallet character	As the player spends (transfer from 380)	No VAT at the sale; arises when the coin is spent and turns into a good	Series No. 49 amendment: a code of “purchasing power/means of payment” character is outside the scope of VAT at the sale
Battle-pass / season	Spread over the season term	At the sale (access to a specific service)	If the season crosses the calendar year, split across periods
Subscription	Ratably over the term (monthly transfer)	At the sale/invoice (access to a specific service)	Annual prepaid: split across 380 + 480
Code/e-pin for access to a specific game	When the relevant entity’s contractual performance is completed	VAT at the sale (consideration for a specific service)	The seller/issuer/intermediary and principal-agent distinction affect the amount and timing; do not confuse with a wallet code
Unspent balance (breakage)	Revenue when the right actually lapses / the term ends	On a wallet balance no VAT arose at the sale anyway; on a specific-service right where VAT was charged at the sale, no additional VAT arises	Separate the two scenarios; addressed below

The basis for the VAT distinction is the section added to the VAT General Application Communiqué by the Series No. 49 amendment (18.01.2024, Official Gazette No. 32433) on the sale of cards/passwords/codes: a code representing a specific product/service is subject to VAT at the sale; a wallet code of a means-of-payment/purchasing-power character triggers VAT not at the sale but when it is used.

In-game coins usually fall into the second group (wallet). But this depends on the specific facts and the contract wording: if you lock the coin to a single specific service, the administration may treat it as “access to a specific service” and pull VAT to the sale. In disputed cases, requesting a private ruling is the cleanest route.

Gökay GÜL’s Note

Gökay GÜL’s Note: The most common trap I see in the field is booking the collection from the store account statement straight into the income statement. The store collecting 100 for you does not make that 100 this month’s revenue — part of it is unspent coins, part is a subscription share that carries into next month. At month-end I reconcile three things: (1) coin sales during the period, (2) coin spending during the period, (3) the wallet balance at period end. The difference lands in account 380. This single discipline both protects you from early tax and lets you answer, with telemetry data, the question “why did you defer the revenue?” in a tax audit. Set up periodicity not as a “book the revenue late” tactic but as a recording discipline that follows performance.

Field Case

(Illustrative example — an anonymized composite distilled from real taxpayer experience.)

A mobile studio in Istanbul, in its first full year of operations, booked all store collections directly to “domestic/foreign sales”. The year-end statement showed an inflated profit; corporate and advance tax were paid accordingly. Yet a considerable part of the coins players bought that year had not yet been spent — meaning the service had not yet been rendered.

With no tracking system in place, the following year, when the same balance was spent, a risk of double recognition (duplicate entry) arose and the reconciliation got tangled; once refunds/balance updates entered the picture, the statement blurred further.

The correction applicable to such a picture is simple but effective: the wallet balance is tied to the accounting through telemetry, unspent coins are moved to 340/380 by their character, and battle-pass and subscription revenues are spread over their term. Commercial volume does not change; but the base begins to follow real performance and cash-tax alignment improves.

For the prior period — to the extent the conditions are met — a correction return and the related procedures (correction-and-complaint, statute of limitations, proof) may be assessed; filing a correction return does not guarantee the automatic refund of tax deemed paid early. The real change is turning the reflex “money in = revenue” into the discipline “money in = liability, performance = revenue”.

Frequently Asked Questions

I sold coins; when do I book the revenue? Because a coin sells the player a “purchasing power” to spend later, at the moment of collection it is a liability, not revenue: it is recorded to account 380 (Deferred Income). Revenue arises as the player spends the coin in the game — that is, as you give them a virtual good/service — with that amount transferred from 380 to the relevant period’s income account. At period end, the unspent balance waits in 380.

What about unspent balances (breakage) and expired battle-passes? The two frameworks work differently. In an entity applying TFRS 15, if you can reliably estimate from past data the portion that will go unspent, you may recognize that amount as revenue in proportion to players’ usage rate; if you cannot estimate it, you recognize revenue when the likelihood of the right being used effectively disappears (for example, when the season closes) (TFRS 15, the “breakage” provisions). On the TPL/uniform-chart side there is no specific provision directly governing breakage; amounts that expire and remain with the entity are taken to revenue in the period they belong to. I could not reach a dated, numbered regulation that fits an unspent game prepayment exactly; so the item should be handled within the accrual and periodicity principles, and in doubtful cases a private ruling should be requested before the transaction.

What if the battle-pass season crosses the calendar year? You spread the amount over the season; if the season carries into two tax periods, you book the portion falling in each period as that period’s revenue. The part of the prepaid amount exceeding one year is tracked in 480, the part under one year in 380.

I received the annual subscription in advance; is it all this year’s revenue? No. The advance collection belongs to the months in which the service will be provided. The amount of a 12-month subscription is spread ratably over the term: at each month-end that month’s share is transferred from 380 to revenue. The 380/480 split is not by calendar year but by the remaining term from the balance-sheet date; the part with a term longer than one year waits in 480. Note: I could not reach a dated, numbered Revenue Administration ruling specifically titled “subscription”; so I build the principle (that advance collections are recognized as revenue spread over their term) from the accrual and periodicity basis — the administration’s opinion on prepaid usufruct/rent income supports the same principle.

Do I compute VAT at the coin sale or at the spend? If the coin has a wallet/purchasing-power character, no VAT arises at the sale; VAT arises when the coin is spent and turns into a concrete virtual good (Series No. 49 amendment to the VAT Communiqué). Battle-pass and subscription, providing “access to a specific service”, are subject to VAT at the sale. Deferring revenue does not defer VAT; the two accruals can run on separate clocks. Also, if you issue an invoice before the delivery/service, VAT limited to the invoiced amount arises then under VAT Law Art. 10/b.

What You Should Do

1. Build a product taxonomy. Split every monetization item into three: wallet-character coins/gems, access to a specific service (battle-pass/subscription), and durable content delivered in a single sale. This classification sets both the VAT trigger and the revenue period; keep it consistent with the terms of use (EULA).
2. Tie the wallet to the accounting. Reconcile coin sales, spending and period-end balance through telemetry; keep the unspent balance waiting in 380/480.
3. Manage VAT and revenue separately. If the coin’s legal and factual character is purchasing power/means of payment, do not raise VAT at the sale, compute it at the spend; for battle-pass/subscription giving access to a specific service, subject it to VAT at the performance of access (with Art. 10/b if an invoice is issued earlier). For codes procured from abroad, separately examine the reverse-charge VAT (No. 2 return) duty according to the nature of the transaction and the condition of benefiting in Turkey.
4. Write your breakage policy. If you are subject to audit, document the TFRS 15 proportional/likelihood-lapsed methods; if not, book the expired balance to revenue in the period it belongs to. Request a private ruling on disputed items.
5. Watch the thresholds. If you are within the scope of TFRS application (or apply TFRS optionally), the contract-liability and performance-obligation provisions of TFRS 15 come into play; other entities subject to independent audit apply the financial reporting framework to which they are subject (e.g., BOBİ FRS). The timing difference between TPL and TFRS creates deferred tax (TMS 12). Check the Digital Services Tax thresholds annually, on a taxpayer and, where relevant, group basis.

Sources: TPL (Law No. 213) Art. 283, 287; Uniform Chart of Accounts Communiqué No. 1 (26.12.1992, Official Gazette No. 21447 bis); VAT Law (Law No. 3065) Art. 10; Series No. 49 amendment to the VAT General Application Communiqué (18.01.2024, Official Gazette No. 32433); TFRS 15 Revenue from Contracts with Customers (9.9.2016, Official Gazette No. 29826); Revenue Administration ruling E-11395140-105[VUK-3-4192]-554230 (02.05.2025). This article is for general information; consult your accountant for your specific situation before any transaction.