You shipped your game. Steam shows 27,400. If you don't know exactly where the other $14,600 went, you're not alone — and you're also not actually looking at your business's financial statements, you're looking at a storefront dashboard that was never designed to be one.
Steam's revenue share is often summarized as "Valve takes 30%," and for the overwhelming majority of indie developers, that's directionally true. But the 30% line item is just one of five separate deductions standing between the price a player pays and the dollar amount that lands in your business checking account: platform commission, refunds, currency conversion, VAT/sales tax, and — if you're not a U.S. taxpayer — federal withholding. Each one needs its own line in your books, because each one behaves differently for tax purposes, and lumping them together is how developers end up either overpaying quarterly estimated taxes or getting an unpleasant surprise from their accountant in April.
Here's how the money actually moves, and how to record it so your books match reality instead of your Steamworks dashboard.
Steam's Tiered Revenue Share, and Why It Barely Matters for Most Developers
Valve's current structure is tiered by lifetime revenue per title:
- 30% platform fee on the first $10 million in gross revenue (you keep 70%)
- 25% platform fee on revenue between 50 million (you keep 75%)
- 20% platform fee above $50 million (you keep 80%)
The tiers were added under pressure from large publishers threatening to move big-budget titles to competing storefronts, not as an indie-friendly gesture. And the numbers back that up: the median indie game earns somewhere between 15,000 in lifetime revenue, and even a title in the top 5% by sales rarely clears $1 million. Unless you're building the next breakout hit, plan your books around a flat 30% commission — the tiers are a rounding error for a game that never crosses eight figures.
That said, if you do have a title approaching $10 million, this is exactly the kind of threshold your bookkeeping needs to watch for in real time, not discover three months later when you reconcile a payout statement. A chart of accounts that tracks revenue per title (not just one lump "Steam Revenue" account) lets you see the tier crossing coming.
Net Revenue: What Steam Actually Pays You On
This is the part that trips up developers coming from a simpler retail or subscription business: Steam's commission isn't calculated on the sticker price. It's calculated on Net Revenue, which is Gross Revenue minus Applicable Adjustments.
Gross Revenue includes VAT and sales tax collected at checkout. Applicable Adjustments include:
- Refunds and chargebacks — the full purchase price of any refunded copy is backed out
- VAT/sales tax — Steam prices are tax-inclusive in most countries, and Valve remits that tax directly to the relevant authority; it never touches your revenue share calculation
- Currency conversion — international sales settle in USD at Valve's conversion rate, which moves with FX markets between the sale date and the payout date
Only after all of that is netted out does the 70/75/80% revenue share get applied. In practical terms: you don't pay Steam's commission on a refunded sale (good), but you also don't get to book the sticker price as your revenue in the first place (important, because it means your "gross sales" figure from marketing dashboards will always be higher than your accounting gross revenue).
Bookkeeping approach: record two separate figures for every payout period — gross platform revenue (net of VAT, before refunds) as your revenue line, and refunds as a contra-revenue account that nets against it on your income statement. Don't just book the final deposited amount as "Steam Revenue" — you'll lose the ability to see your refund rate trending, which is one of the more useful health metrics an indie studio has.
Refunds Aren't a Rounding Error — Track the Rate, Not Just the Dollars
Steam's refund policy lets a player request a full refund for any purchase made within the prior two weeks, provided they've played less than two hours. It's dramatically more generous than console or mobile storefronts, and it exists for good reason (it kills a lot of "buy, pirate the DRM-free copy, refund" abuse and builds trust with buyers). Across the platform, refund rates average around 5% of purchases, but short narrative games and titles that can be "critical-path completed" in under two hours frequently see far higher rates — developers have reported refund rates climbing into the double digits for titles that a player can finish in a single sitting before the two-hour window closes.
For your books, this means:
- Treat refunds as a recurring cost of doing business on Steam, not an exception. Budget for them the way a retailer budgets for shrinkage.
- Watch the refund rate as a KPI, not just the refund dollar total. A rate that creeps up after a patch or a marketing push is a signal — either a bug, a misleading store page, or (increasingly common in 2026) refund-window abuse targeting short games.
- Never recognize revenue on a sale until the refund window has meaningfully passed, if you're doing formal revenue recognition (ASC 606) — most indie studios don't need to defer recognition for a two-week refund window given its short duration and statistically predictable rate, but if refunds are material and volatile for your title, a monthly refund reserve/allowance is the more accurate approach than recognizing 100% of gross sales and taking a hit later.
Regional Pricing and the Currency Conversion You Didn't Choose
Steam supports pricing in 35 currencies, and Valve's 2026 pricing update moved beyond simple exchange-rate conversion to also weigh local purchasing power and regional entertainment pricing norms — meaning your $19.99 US price might translate to a very different real-terms price in, say, Brazil or Southeast Asia, and that translation can shift over time even if you never touch your own pricing settings.
Two consequences for your bookkeeping:
- Every international sale is a USD conversion, not a fixed number. The rate used is Valve's rate at time of reporting, not the rate on the day the player bought the game. If you're tracking revenue by region for tax or business-planning purposes, pull the regional breakdown from your Steamworks sales report rather than trying to back-calculate it from the deposit total.
- Don't manually adjust your regional prices without checking the downstream effect on net revenue per unit. A price drop in a high-VAT country can shrink your take more than the sticker price change suggests, because VAT is backed out before the revenue share is applied.
Payout Timing: Why Your Bank Deposit Never Matches This Month's Sales
Valve pays out approximately 30 days after the close of the sales month — February's sales are paid out at the end of March, for example — and Steam holds payment until your account crosses a $100 minimum threshold, which matters for tiny early-access titles or studios running several small games where an individual title's monthly revenue might not clear the bar on its own.
This lag is the single most common source of "my books don't match my bank account" confusion for new Steam developers. The fix is standard accrual accounting: record revenue in the month the sale actually happened (per your Steamworks sales report), not the month the cash hits your bank. Set up a "Steam Receivable" account that accrues each month's net revenue and clears when the wire or ACH deposit lands 30-ish days later. Without this, your monthly P&L will look like a rollercoaster that has nothing to do with your actual sales trend — it'll just reflect whichever months happened to have a payout land in them.
Tax Withholding: The Step Non-U.S. Developers Skip and Regret
If you're a U.S. taxpayer, Valve issues you a 1099 and you handle it like any other business income. If you're not a U.S. taxpayer, this next part is the one that catches people:
Steam revenue is classified as U.S.-source royalty income (specifically, the copyright royalty rate for games and DLC). During Steamworks onboarding, every partner completes a tax interview and generates either a Form W-9 (U.S. developers) or a Form W-8BEN (non-U.S. developers). Based on your country of residence and whether it has a tax treaty with the U.S., Valve withholds between 0% and 30% of your revenue share before it ever reaches your bank account, and reports it annually on Form 1042-S, issued by March 15.
If you're seeing 30% withheld and your country has a tax treaty with the U.S. that would entitle you to a reduced rate, you likely didn't complete the tax interview correctly — commonly because you didn't provide a foreign or U.S. taxpayer ID number where the treaty benefit requires one. That's a form you can go back and re-file; it's not a permanent rate. For a solo developer, the difference between an unclaimed treaty (30% withheld) and a claimed one (often 0-15%, depending on the country) can be thousands of dollars a year — worth a half hour re-checking the interview.
Either way, that withholding is a separate line from Steam's platform commission. Don't blend "Steam's cut" and "tax withholding" into one number in your books — they have completely different tax treatment. The withheld amount is a prepayment of your own tax liability (you may be able to claim it as a foreign tax credit or reclaim it depending on your home country's tax treatment), while the platform commission is Valve's fee, full stop, and not creditable against anything.
A Simple Chart of Accounts for a Steam-Funded Studio
For a small studio, five accounts capture almost everything above:
- Steam Gross Revenue — sales at net-of-VAT price, before refunds and commission
- Steam Refunds (contra-revenue) — dollar value of refunded/charged-back sales
- Steam Platform Fees — the 30/25/20% commission, tracked separately from...
- Steam Tax Withholding — non-U.S. developers only; treat as a prepaid tax asset, not an expense
- Steam Receivable — accrued but unpaid revenue from the current and prior month, clearing when the payout lands
If you run more than one title, add a class or tag per game rather than a whole new set of accounts — you want to compare title performance without duplicating your chart of accounts five times over.
Keep Your Game Studio's Books as Clean as Your Codebase
If you're comfortable reading a Steamworks sales report, you're comfortable with plain text — which is exactly what Beancount.io is built around. Instead of wrestling with a GUI-driven accounting tool to model something as irregular as tiered platform fees, refund reserves, and foreign withholding, you write it once as a version-controlled ledger and get every calculation that follows for free. Check the docs for how developers structure a marketplace-revenue ledger, or explore Fava for a dashboard view of revenue, refunds, and fees by title without leaving plain text.