Indie Game Developer Milestone Payment Accounting Guide

Indie game developer milestone payment accounting rests on three facts that a studio's books need to reflect before a single journal entry is posted. First, a publisher milestone advance is not revenue when it hits the bank account; it is a recoupable liability that sits on the balance sheet and is amortised against future royalty income, not recognised as earned income on the day the wire clears. Second, the developer's right to invoice is triggered by the publisher's formal approval of the milestone deliverable, not by the developer's internal sign-off that the work is finished. The approval gate is the accounting event. Third, recoupment plays out on a long, slow cadence: royalty statements land 45 to 90 days after the period they report on, the recoupment window often runs one to three years post-launch before the balance clears, and only after it does the headline split flip into the developer's favour.

Those three facts explain why the revenue split in an indie publishing deal looks punishing on paper during the recoupment window. The publisher typically keeps the majority, commonly 60% or more, of net revenue until the advance has been paid back, and in a meaningful share of contracts the developer sees nothing at all until the recoupment balance clears. In PC Gamer's analysis of indie game publishing contract structures, 42% of the deals reviewed gave the publisher 100% of net revenue until its advance had been fully recouped, and the average advance across the sample was approximately $318,000. That single figure is the anchor for the rest of the bookkeeping: a $318,000 liability landing on a studio's balance sheet at signing, drawn down as cash across milestone payments, and then slowly written off against royalty income that may not begin arriving until eighteen months to three years later.

Everything operational in game publisher recoupment accounting follows from those facts and that timeline. The hinge event in the milestone-to-cash cycle is publisher approval, which sits between completion and the invoice and which most studios underdocument until their first payment dispute forces them to rebuild the paper trail. Recoupable advance accounting for a game studio means a specific journal-entry pattern, posted at signing and unwound across the life of the deal, that keeps the advance off the profit and loss statement until it is genuinely earned. And the royalty-statement reconciliation is not a one-time post-launch task; it is a recurring obligation that runs for years, where platform fees, recoupable marketing, localisation charges, and QA deductions each shift the running recoupment balance in ways the studio has to reproduce independently to know whether the statement is correct.

The Shape of a Typical Indie Publishing Deal, in Numbers

A modern indie publishing deal is, at its core, a financed services arrangement dressed up as a partnership. The publisher fronts a cash advance, paid out in tranches against development milestones, and recoups that advance out of the developer's share of net revenue once the game ships. While the advance is being recouped, the split favors the publisher. Once the recoupment balance reaches zero, the split reverses and the developer starts earning the larger share. Every number in your contract sits somewhere inside that structure.

The pre-recoupment split most indie studios see is 60/40 in the publisher's favor, with 70/30 appearing regularly on deals where the advance is larger or the publisher is taking on marketing risk. After full recoupment, the split typically flips to 30/70 or 40/60 in the developer's favor. A more aggressive variant you will encounter is the 100/0 recoupment deal, where the publisher retains the entire developer-share of net revenue until the advance is fully recouped, and only then does the developer begin receiving royalties at, say, 50/50 or 60/40.

A structurally different deal shape worth flagging: some contracts pay the developer a minority share of net from day one, usually 20% or 30%, and recoup the advance only against that minority share. Recoupment for the publisher is slower, but the developer sees cash flow from month one of release instead of waiting six or twelve months to cross the recoupment line.

The split is never applied to gross sales, and that is the single most common thing founders miss when they read their first royalty statement. Net is gross sales minus a stack of deductions that the contract enumerates, and the stack is long. Storefront platform fees come off the top first: Steam, Xbox, PlayStation, and Nintendo are widely cited at a 30% platform cut, with specific tiers, revenue-share breakpoints, and promotional programs varying by platform and by deal. Payment processor fees and refunds come off next. Then the contract-specified deductions: localisation costs, QA and certification fees, and, most importantly, recoupable marketing, the publisher's spend on paid ads, influencer campaigns, trailer production, and event presence, which they deduct from the revenue pool before the split is calculated and which typically also adds to the recoupment balance you owe. A game grossing $1,000,000 on Steam can easily show net revenue of $550,000 or less once platform fees, refunds, localisation, and recoupable marketing are subtracted, and the 60/40 split is then applied to that $550,000 figure, not to the million.

The no-advance deal is worth understanding as the structural opposite. Here the publisher puts in zero upfront capital, so there is nothing to recoup, and in exchange the developer keeps a larger share of net from release, often 80/20 in the developer's favor, sometimes higher. It is the clearest illustration of what a recoupable advance actually is: not free money, but a loan priced into a worse revenue split. Viewing the advance through that lens is also what justifies the accounting treatment covered later in this guide, where the advance sits on the books as a liability rather than revenue.

Deal term is the last number that shapes the recoupment math. A typical indie publishing agreement runs for a fixed term of five to seven years, or until a defined revenue threshold is hit, or until a defined post-launch window closes, after which rights revert to the developer. That horizon matters because recoupment can take one, two, or three years of post-launch sales to complete, and the post-recoup split, the favorable side of the deal, only has value for whatever years of the term remain after the recoupment balance hits zero. A game that recoups in month thirty of a sixty-month term has thirty months of 70/30 revenue ahead of it; a game that recoups in month fifty-four has six.

The Milestone Lifecycle: Five Events Between Completion and Cash

A milestone in an indie publishing deal is not a single event. Between the moment the build is finished and the moment cash lands in the studio's account, five distinct operational events have to occur in sequence, and confusing them is the most common source of cash-flow surprise at small studios.

1. Milestone completion. The developer finishes the build and assembles the deliverables the contract calls for at that milestone: the executable, source assets where required, a milestone report that maps the build against the agreed feature list, and any supporting documentation such as a risk log or QA pass. Completion is an internal event. Nothing on the publisher's side has happened yet, and nothing can be invoiced.

2. Documentation submission to the publisher. The developer delivers the package through whatever channel the contract specifies, which for most deals is a publisher build portal plus an email to the producer. Many contracts also require a signed milestone acceptance form listing the deliverables and the contractual clause the milestone corresponds to. The date of submission is load-bearing, because it is the date from which the review window is counted.

3. Publisher review window. The contract specifies a fixed number of business days during which the publisher evaluates the build, plays it, and decides whether the milestone is met. Ten to twenty business days is typical, and it is almost always defined in business days rather than calendar days, which matters when submissions land near a holiday. During this window the developer is waiting, cannot invoice, and is usually already burning payroll against the next milestone.

4. Approval, or rejection with notes. At the end of the review window the publisher issues a decision. A clean approval moves the lifecycle to stage five. A rejection-with-notes returns a list of issues the developer must address, commonly with a first-revision deadline measured in days and an optional second revision before the publisher can treat the milestone as failed outright. Absolute rejection, where the build is declared a material breach rather than a fixable one, is rare and usually triggers a termination clause rather than a resubmission. The subjective approval language that makes this stage real is worth reading carefully: most deals require the publisher to be "reasonably satisfied" with the build, a standard that gives the producer wide discretion over what counts as done.

Rejection with notes is where timelines actually break. The developer addresses notes, resubmits, and the review window starts again from the resubmission date. Each round adds the full review window plus the revision work on top, so two rejection-revision cycles on a milestone with a fifteen-business-day review window can push approval four to six weeks past what the studio penciled in.

5. Invoice submission permitted. Only once the publisher has formally approved the milestone does the contract permit the developer to invoice, and only then does the payment clock begin. NET 30 from receipt of invoice, sometimes NET 45 or NET 60, is the standard. This is the hinge that separates a publisher milestone invoice from an ordinary service invoice: in normal accounts payable, a supplier invoices on delivery and the clock starts immediately, mirroring how AP teams approve service invoices against contractual milestone gates and change orders in other industries; in a game deal, the clock does not start until the publisher's approval is in hand and invoicing is expressly authorized. A studio that expected thirty days from completion to cash can easily be looking at sixty, ninety, or more once the review window, a revision cycle, and NET 30 payment terms stack on top of each other.

Invoicing before approval is almost always contractually prohibited, even when the developer is certain the work is complete. Invoices sent early are routinely rejected by publisher AP without payment, and in some deals they count as a procedural breach. The invoice itself, when it does go out, must reference the specific milestone by name or number, cite the clause of the agreement under which it is raised, and state the publisher's approval date so the AP team can match it to their own acceptance record. Those three references, milestone, clause, and approval date, are what let a game publisher milestone invoice move through the publisher's accounts payable process without being bounced, and they are the reason video game development payment tracking has to start from the approval email rather than from the completion date the studio has in its own project plan. The same approval-gate mechanics drive game publisher recoupment accounting downstream: the approval date is the date the advance obligation crystallises against a given milestone, and every reconciliation after that point refers back to it.

Milestone Types, Typical Weightings, and the Documentation Package at Each One

Publishing contracts almost always structure the advance across a recognisable sequence of milestones, and if you can recognise the vocabulary you can read a draft schedule in minutes. The standard sequence, in the order it tends to appear: concept or prototype, vertical slice, first playable or alpha, beta, gold master (sometimes called release candidate), and one or more post-launch milestones tied to content updates, DLC drops, or specific platform certification passes.

The definitions worth carrying in your head are the practitioner versions, not the textbook ones:

Concept / prototype. A rough build or design package that proves the core loop is worth funding. Often just a playable mechanic, a pitch deck, and a technical design document.
Vertical slice. A short polished segment, typically 10 to 20 minutes of gameplay, demonstrating final-quality gameplay, art, audio, and UI. This is the build the publisher will show to platform holders and marketing partners, so production values matter far more than content volume.
First playable / alpha. The full game playable start to finish, with all major systems in place but content still rough, placeholder assets in some areas, and known bugs. Feature-complete is the test; polish is not.
Beta. Content-complete and polish-complete. All assets final, all levels in, localisation pipelines running, performance targets being hit on target hardware. Bug-fixing only from here.
Gold master. The submission build that passes platform certification (Sony TRC, Microsoft XR, Nintendo Lotcheck, Steam build validation) and is ready to ship. No further changes unless a submission fails and a new candidate is required.
Post-launch milestones. Usually tied to a specific deliverable, such as a patch hitting a stability target, a free content update shipping, a paid DLC reaching its own gold master, or a console port certifying on an additional platform.

Cash is almost never distributed evenly across these. A common weighting on a six-milestone schedule is 5 to 10% at contract signing, 15 to 25% at vertical slice, 15 to 20% at alpha, 20 to 25% at beta, and 20 to 30% at gold master, often with the gold master tranche structured as a balloon payment that materially exceeds any individual earlier milestone. Post-launch milestones, where included, tend to be smaller, in the 5 to 15% range each, and tied to the specific deliverable named in the schedule. Every deal is negotiated, and heavier front-loading, such as pushing more money into contract signing and vertical slice, directly improves the developer's cash flow during the riskiest phase of production when burn is high and revenue is zero. Front-loading the vertical slice, alpha, beta, and gold master payment schedule is how producers with limited leverage actually pull cash forward when they cannot move the headline NET terms.

What you owe the publisher at each gate is not just a build. The documentation package expected at almost every milestone includes, at minimum:

A playable build matching the milestone definition in the contract exactly, delivered through whatever channel the publisher specifies (a build server, a secure drop, a specific branch on their source control).
A milestone report, usually 2 to 10 pages, describing what was delivered against each bullet of the contractual milestone definition, what is working, what is known to be broken, and how known issues will be resolved before the next milestone or before launch.
A milestone acceptance form where the contract requires one, signed by the developer and countersigned by the publisher once the build is approved.

Many publishers also ask for a changelog summarising what has changed since the last build delivery, a known-issues list separate from the milestone report so QA can triage against it directly, and build notes for the QA team covering build flags, cheat codes, skip-to-level shortcuts, and save files that let testers reach specific sections quickly. On console milestones, expect to also attach a pre-certification self-test checklist against the relevant platform's technical requirements.

Keep the entire documentation package permanently attached to the eventual invoice for that milestone. If a publisher disputes an approval six months later, the defensible audit trail is build hash plus submission date plus milestone report plus approval response plus invoice plus payment receipt, all in one pack, all cross-referenced. For studios that may be audited, or that go through due diligence during an acquisition or a publisher change, this pack also matters years after the cash has landed. A producer who files sloppily at milestone three is handing future-them a reconstruction job under deal pressure.

Recording a Recoupable Advance on the Books

A milestone advance is not income. It is consideration the studio has not yet earned, the publisher is funding development in exchange for a future share of net revenue, and the cash is effectively a conditional prepayment against royalties the game has not produced. Booking it as revenue on receipt overstates the P&L during development and then distorts the release window, when incoming royalty shares are legitimately earned but get offset against a balance you failed to carry. The correct treatment is a liability, commonly labelled Recoupable Advance or Publisher Advance, Unrecouped, that is drawn down as royalty income is earned post-launch.

The journal-entry pattern, stage by stage

When a milestone invoice is paid. The bank receives cash; the balance sheet picks up a matching obligation, not a revenue line.

Debit: Cash (or Bank), amount of the milestone payment
Credit: Recoupable Advance (liability), same amount

Repeat this entry for every milestone payment. If your chart of accounts does not yet have a Recoupable Advance liability account, create one under long-term liabilities (or current liabilities if the game is expected to ship and recoup within twelve months). This mirrors the journal-entry pattern for recording an advance payment as a liability before it is earned used in any prepayment context, the milestone-specific wrinkle is that the "earning" event is a royalty statement, not delivery of a service on a date certain.

During development. The advance itself generates no revenue entries. Development spend, salaries, contractor invoices, engine licences, middleware, QA, rent, the coffee, flows through the P&L as ordinary operating expense in the period incurred. Your P&L during development will show operating losses funded by the cash that sits behind the Recoupable Advance liability, which is accurate: you are burning through a publisher-funded runway against a future revenue share.

At launch and each royalty period. The publisher issues a royalty statement showing net revenue, deductions, and the developer's contractual share for the period. Your earned royalty share is split into two pieces, based on the opening unrecouped balance:

Up to the remaining unrecouped balance: Debit Recoupable Advance, Credit nothing on the P&L. This reduces the liability rather than recognising revenue, the advance is being earned out.
Any excess over the remaining unrecouped balance: Debit Royalties Receivable (or Cash, if paid), Credit Royalty Revenue. This is genuinely earned income and hits the P&L for the first time.

Once the Recoupable Advance liability reaches zero, subsequent royalty periods post entirely as revenue: Debit Royalties Receivable, Credit Royalty Revenue.

Cash-basis versus accrual-basis

The cash is real. You still pay employees, contractors, studio rent, and engine royalties out of it, and a cash-basis bookkeeping approach will see it hit the bank and book it straight to income. For a studio with material advances, anything where a single milestone payment would meaningfully distort a month or quarter of reported income, accrual-basis bookkeeping is the appropriate default, because only accrual treatment supports the liability-then-earn pattern above. This is also the point to confirm the approach with your tax preparer. Recoupable advance treatment varies by jurisdiction and by whether the publishing contract is structured as a licence (royalty income, advance against royalties) or as a service agreement (development fee, possibly taxed when received regardless of recoupment mechanics). The bookkeeping entries are only half the question; the tax timing is the other half, and it turns on contract language you should not read alone.

Two failure modes to avoid

Booking the full advance as revenue on receipt. The studio looks profitable during development, pays tax on income it has not economically earned, then takes a phantom revenue hit at launch when royalties arrive but fail to recognise as P&L revenue because they are now offsetting a balance the books never carried. The distortion runs in both directions and is painful to unwind after the fact.

Booking nothing at all until the royalty statement arrives. The cash is in the bank and being spent, but the balance sheet shows no corresponding obligation. The studio's own cash-flow forecasting breaks, there is no unrecouped-balance figure to reconcile against, and an external reader of the books, whether a lender, an investor, or a tax authority, sees a studio that appears to be sitting on unexplained cash.

Rejections, terminations, and unrecouped balances at end of life

A rejection-with-notes on a milestone does not change the liability treatment of prior milestone payments already received; it delays or cancels the next payment, not the accounting for earlier ones. Contract termination is more nuanced. If the contract makes the advance non-refundable and the studio retains the cash, the liability remains on the books until the contract mechanism for earning it out resolves, typically through royalty offset against a released game, or through an explicit written release. If the game ships and royalties never reach the advance, the unrecouped balance does not evaporate on its own; eventual derecognition of the liability depends on the specific contract language around non-refundability, any reversion of rights, and the studio's accounting policy, and is a conversation for the tax preparer and, at any size, an auditor. The one thing that is never correct is quietly dropping a stale Recoupable Advance balance off the balance sheet because the game has stopped earning.

Reconciling a Royalty Statement Against the Recoupment Balance

Publisher royalty statements arrive on a lag. Most deals run on a quarterly or biannual cycle, with the statement delivered 45 to 90 days after the period close. The delay is not administrative laziness: each storefront reports sell-through on its own schedule, FX has to be converted into the contract currency at a defensible rate, returns and chargeback windows have to close out, and the publisher's own finance team runs its close before the developer report is cut. A studio that expects cash the day the period ends will be disappointed every cycle for the life of the deal.

What a Royalty Statement Actually Contains

The line-item order on a typical statement follows the money from gross sell-through down to what the developer is actually owed. Expect, in roughly this sequence:

Gross sales by storefront, broken out per platform: Steam, Xbox, PlayStation, Nintendo eShop, Epic Games Store, GOG, and any mobile storefronts. Each line usually carries unit counts, gross revenue in local currency, and the platform the units were sold through.
Returns and chargebacks netted against gross, so the working number is sell-through rather than sell-in.
Storefront platform fees deducted next. Each storefront takes its cut before the publisher sees net receipts, and the percentage varies (Steam's standard 30%, first-party console fees at 30%, reduced tiers kicking in at revenue thresholds on some storefronts, different rates for mobile).
FX conversion of each storefront line into the contract currency, often USD or EUR, at the rate the contract specifies, monthly average, period-end spot, or the platform's own reported rate.
Net sales or net receipts, the sub-total after storefront fees and FX.
Recoupable deductions taken against net receipts before the contract split is applied: recoupable marketing spend, localisation costs, QA and certification costs, platform compliance and submission fees, and any other categories the contract names as recoupable.
Contract split applied to what remains: the developer's royalty share for the period.
Recoupment accounting: opening recoupment balance brought forward from the previous statement, current-period royalty applied against it, closing recoupment balance, and the cash payable this cycle (zero until the advance is fully recouped).

The Reconciliation Routine

Run the same checklist every statement cycle. This is the routine that catches both honest errors and the slow drift of deductions that should not be there.

Verify gross sales against the platform dashboards you have direct access to. Even when the publisher holds the storefront contract, most storefronts give the developer a reporting portal as the creator of record, and the numbers on that portal should match the gross line on the statement for the same period. Steamworks, Partner Center, Dev Portal, Publisher Tools, each storefront has a backend, and the developer is usually granted at least read access.

Verify FX rates against the period's published rates from the source the contract references. If the contract specifies monthly average rates from a named provider and the statement has applied period-end spot, the difference on a six-figure period can be material.

Verify platform-fee percentages against each storefront's current published rates. Revenue-share tiers change; Steam's reduced rates above $10M and $50M, PlayStation's tiered structure on first-party, mobile storefronts' 15% small-business rates, these shift, and a statement that bakes in an out-of-date percentage should be questioned.

Verify recoupable marketing, localisation, and QA lines against the backup documentation the contract entitles you to request. Most publishing deals include an audit right or at least a line-item backup right; exercise it. Marketing recoups in particular are where disputes live: a $40,000 influencer campaign line with no backup invoice attached is not a line you post against your liability schedule on faith.

Confirm the opening recoupment balance matches the closing balance on the previous statement, to the cent. A mismatched opening balance means either the publisher adjusted the prior period without notice or your books are out of sync, and either case is resolved in writing, tracked by statement period, before you post the current cycle.

Any delta from any of the above becomes a question to the publisher in writing. Keep a log per statement period of what was asked, what was answered, and what was adjusted. This is the artefact that matters if the deal ever enters audit or dispute.

The Journal Entries the Statement Drives

The accounting flows from the reconciled numbers:

Post the current-period royalty earned as a debit to the Recoupable Advance liability, up to the remaining balance. The advance was originally booked as a liability when it was received (see the prior section on recording a recoupable advance); each statement chips away at it.
Any royalty earned in excess of the remaining liability balance posts as revenue for the period. Until the balance hits zero, nothing hits the P&L; after it hits zero, only the excess does.
If cash is payable this cycle because the advance is fully recouped, debit Cash (or Accounts Receivable if the cash lags the statement) and credit Revenue for the payable amount.
Update the running liability schedule so the next statement's opening balance can be checked against your books rather than accepted on faith.

Statement Complexity at Scale

This reconciliation runs every cycle for the life of the deal, which for a successful game is often years past launch. The volume of line items grows as the game is released on more storefronts and in more territories. A title that shipped on Steam only at launch, added Xbox and PlayStation six months later, added Switch and GOG the year after, and then got a mobile port, will be generating a statement with dozens of deduction lines across a dozen storefront-territory combinations. At that scale, rebuilding the statement in Excel each quarter stops being a task a single operator can do in an afternoon, and studios start reaching for a tool for extracting line items from milestone invoices and royalty statements into structured spreadsheets so the per-cycle reconciliation work scales with the deal rather than with the operator's patience. The pattern is the same one how entertainment studios reconcile guild residual statements against per-project balances describes for film and television: structured financial documents arriving on a cycle, checked line-by-line against a running balance.

The reconciliation itself does not change as the volume grows. The checklist above is the same whether the statement has four deduction lines or forty. What changes is how you get the numbers onto a spreadsheet in a form you can actually check.

Invoicing a Game Publisher: What the Invoice Must Carry and When You Can Send It

In almost every publisher deal, the developer is contractually permitted to invoice only after the milestone has been formally approved in writing, not on the day the build is delivered. Delivery starts the approval clock; approval starts the invoicing clock. Sending an invoice the moment a gold master upload completes is one of the most common first-deal mistakes a studio operator can make, and the usual consequence is the publisher's AP team kicking the invoice back as non-conforming, which costs anywhere from several days to two full weeks off the payment cycle before you can resubmit against the approval date.

The invoice itself is where a lot of first-deal studios also trip up, because a publisher milestone invoice is not a generic freelance service invoice. It must carry:

The milestone name exactly as written in the contract (if the contract calls it "Milestone 3, Vertical Slice", the invoice says "Milestone 3, Vertical Slice", not "VS build" or "Playable demo").
The milestone approval date issued by the publisher's producer or business-affairs contact.
The contract clause or milestone number reference (e.g., "Milestone 3 per Schedule A, Section 4.2").
The amount matching the tranche allocation in the contract to the cent, in the contract's stated currency.
The developer's legal entity name and registered billing address (not the studio's trading name or a personal address).
The publisher's specified billing address and invoice email from the contract or from the onboarding packet the publisher's AP team sent at contract signature.
Any PO number the publisher requires (many mid-size and larger publishers route everything through a purchase-order system and will automatically reject invoices without a matching PO number).
A unique invoice number the studio controls and can reference on later chases.
The payment-term clause restated on the invoice face, usually "NET 30 from receipt of invoice" or whatever the contract carries.

Publishers routinely reject invoices that are missing any one of these fields. Each rejection pushes the payable further down the queue at the publisher's AP team, so a studio that gets the invoice format right on the first submission genuinely gets paid faster than one that doesn't.

Game publisher payment terms: NET 30, NET 45, NET 60

NET 30 from receipt of invoice is the most common baseline you'll see, but NET 45 and NET 60 appear often enough that you should expect them rather than treat them as outliers, particularly with larger publishers and with any publisher that is itself part of a public parent company running centralized finance. The larger the publisher's corporate finance apparatus, the more likely the terms push out to NET 45 or NET 60, because those cycles are set by group-level AP policy rather than by the individual business-affairs contact you negotiated with.

Read the trigger language carefully. NET 30 from invoice date and NET 30 from receipt of invoice can differ by several days in practice, because "receipt" is when the publisher's AP system logs the invoice, not when you emailed it. If the contract says "from receipt", the day you send the invoice and the day the clock starts are not the same day, and for NET 45 or NET 60 terms that gap compounds. The approval-gated invoice workflow is not unique to games, either; much of the approval-gated invoice workflow film production accounting teams run against a shooting budget follows the same logic of a controlling document (the budget, the milestone schedule) against which each invoice is validated before payment can move.

Pre-invoicing to shave days off the payment clock

A practice some experienced studios use to tighten the payment cycle: attach the milestone invoice to the milestone submission package itself, with a cover note stating that the invoice is effective only upon the publisher's formal approval of the milestone. For publishers whose AP process accepts this, it removes the separate "now send your invoice" step after approval, and payment terms effectively start running from the approval date with no dead days in between. Not every publisher's finance team will accept a pre-dated or conditionally effective invoice, so confirm with your business-affairs contact before adopting this as standard practice, but where it is accepted it can pull three to seven days forward on every milestone payment.

Where leverage actually lives

Be honest with yourself about payment-term leverage on a first deal. A studio signing its first publishing contract, with no shipped title and no competing offer, has essentially zero leverage on NET terms and will almost always accept whatever the publisher's standard template carries. That is not a failure of negotiation, it is the market. Where leverage appears is on the second deal and onward: studios with a prior shipped title, studios with a live PC/console track record, and studios holding a competing offer from another publisher can push on NET terms, on recoupable-marketing caps, and on milestone cash weighting (shifting more of the total advance into earlier milestones).

Of those three, milestone weighting is usually the highest-value win for a studio that still has limited leverage. Moving 10 percent of the total advance from the gold-master milestone into the vertical-slice or first-playable milestone can matter more to a small studio's survival than shaving NET 45 down to NET 30 on the same total, because the cash arrives months earlier in the development cycle when runway is tightest. Studios without strong leverage tend to win more by negotiating on where the cash lands in the schedule than on how many days the publisher takes to pay it.

Cash-Flow Planning Around Approval Gates and Post-Launch Dead Zones

A service company with a normal book of clients can forecast accounts receivable with reasonable confidence. Invoices go out, NET 30 or NET 45 terms apply, and aged AR behaves like a slightly noisy but predictable signal. Publisher milestone cash flow does not behave that way. Each tranche is gated by a subjective approval decision from the producer on the other side, the gate can open on time, open late with notes, or close entirely pending a revision, and the NET clock only starts once the gate opens. A studio that plugs milestone dates straight into a cash-flow model as if they were invoice due dates will run out of money before the tranche arrives.

The planning problem for game studio cash flow milestone delays is therefore not "when is the next payment due" but "what is the realistic distribution of arrival dates, and do I have payroll covered across that distribution." Video game development payment tracking has to account for the review window itself, not just the contractual payment terms that begin after it.

Buffer heuristics studios actually use

The 20% overrun rule is the most commonly cited starting point: budget for 20% more time and 20% more money than the contractual plan calls for on any given milestone. The rule is specific to games because the delay drivers are specific to games, subjective creative approval, platform certification slippage at first-party submission, QA feedback cycles that compound across builds. Studios on their first publisher deal often run a heavier buffer, closer to 30%, because they have no internal data yet on how the specific producer reviewing their build actually behaves under pressure.

Translate the buffer from a schedule cushion into a cash-flow reserve. A workable rule is to hold back roughly one payroll cycle of cash at each milestone gate, separate from general operating reserves. If payroll runs at $80,000 per cycle, the reserve against the next milestone is $80,000, and it is only released once the milestone payment has actually landed in the bank account, not on the contractual due date.

Modelling the rejection-with-notes path

A contract that allows two revision rounds with a 15-business-day review window each is generous on paper and punishing on the cash-flow spreadsheet. A first-pass rejection triggers a revision period, a second submission, and a second review window. Before the NET clock even starts, a rejected milestone can drift by roughly a full month per revision round. Two revision rounds, plus NET 30 on top, stretch a "milestone complete" date two or three months into the future.

Treat at least one milestone per project as travelling the rejection-plus-revision path, even if in practice it does not materialise. The planning question is not whether every milestone will be rejected, it is whether the studio can survive if one is. Running the model on the happy path only is what produces the emergency bridge-loan conversations six months later.

The post-launch dead zone

The period between the gold master payment and the first royalty statement is the stretch most likely to surprise a first-time indie studio. The gold-master tranche pays out on approval of the shippable build. The game then launches, starts generating sales, and the studio watches the wishlist conversion numbers tick up, and no publisher cash arrives for weeks. Royalty statements arrive on the contractual cadence, often 45 to 90 days after the close of the reporting period, and even then the statement may show the advance unrecouped with a zero balance due.

Name this gap the dead zone in the internal cash-flow model. Between gold master and the first meaningful royalty payment, a six-figure cash gap is normal, not a deal going wrong. Plan for it explicitly. A studio that assumed launch-week sales would translate into launch-month cash from the publisher is planning against a structure that does not exist.

The runway rule that follows from all of this

The practical rule of thumb ties the buffers together. A studio's runway should extend not to the date of the next expected milestone payment, but to:

Next expected milestone payment + worst reasonable rejection-and-revision delay + NET terms + one payroll-cycle buffer.

For a milestone contractually due in 90 days with NET 30 terms and a two-round revision allowance, that calculation lands somewhere around 180 to 210 days of runway coverage against that single milestone, not 90. For the gold-master-to-first-royalty stretch, the runway has to cover the full dead zone on top, because the next publisher cash event after gold master is not next month's payment, it is next quarter's statement.

Anything tighter than this treats the publisher's subjective approval process as if it were a predictable AR cycle. It is not, and the cash-flow model should not pretend otherwise.

What Indie Studios Actually Use to Track All of This

The honest baseline is unglamorous. Most indie studios signing their first publisher deal run milestone payment tracking and recoupment in a spreadsheet, Excel or Google Sheets, wired into QuickBooks or Xero for the general-ledger work. The spreadsheet is where the milestone schedule lives, one row per milestone with columns for submission date, approval date, invoice date, NET term, cash-received date, and the running recoupment balance. The accounting software handles journal entries: booking the advance as a liability, reducing the recoupment balance as statements come in, posting royalty income on top once the advance is fully recouped. Neither tool is doing anything exotic, and that is the point.

The concrete setup converges on three tabs. A milestone tracker tab with one row per milestone and a column for each event in the lifecycle, from kickoff through cash receipt, so the team can see at a glance which milestones are mid-submission, mid-approval, or overdue for payment. A recoupment-balance tab that carries an opening balance forward, logs each royalty statement as a row (gross sales, platform fees, refunds, chargebacks, marketing deductions, net to recoup, closing balance), and seeds the next period's opening line from the prior period's close. A cash-flow forecast tab driven off the milestone tracker, translating expected approval dates plus NET term into projected cash-in dates across the next six to twelve months. This is the shape of video game development payment tracking at the studios who handle it cleanly: not sophisticated, but disciplined, and sufficient up to a certain volume.

The inflection point is reasonably predictable. Once the game is live on five or more storefronts across multiple territories, each royalty statement becomes a document carrying dozens of deduction lines, and rekeying those lines by hand each quarter eats a meaningful slice of the month for whoever owns the books. Studios hitting that point typically do one of three things. They hire a bookkeeper with actual game-industry experience to run the reconciliation. They engage a specialist outsourced accounting firm that already knows how platform fees, refund clawbacks, and recoupable marketing behave on a statement. Or they move to extracting the statement line items programmatically into the same spreadsheet and accounting-software workflow they already have, so the manual rebuild goes away while the ledger structure stays intact.

The ERP question is worth answering directly because it gets asked at the wrong time. A studio with one deal, or a handful of deals, and statement volume in the range of a few hundred lines per quarter does not need a full ERP implementation, and the cost-benefit does not pencil out at that scale. The honest path from spreadsheet to heavier tooling is incremental. Add extraction for the statement line items first. Keep the existing recoupment-balance ledger and the existing chart of accounts in QuickBooks or Xero. Only look seriously at a larger system when deal volume, multiple concurrent titles across multiple publishers with overlapping recoupment pools, actually demands it. Recoupable advance accounting at a game studio does not get better because the software is heavier; it gets better because the operator stays on top of the numbers.

Which is where the studios who do this well separate from the ones who don't. They keep the milestone tracker current every week, not once a quarter when something breaks, because a milestone slipping two weeks is a cash-flow problem detectable only from a current tracker, never from an after-the-fact one. They reconcile every royalty statement within a week of receipt, while the deduction lines are still fresh and the publisher's finance contact still remembers the period. And they treat unrecouped advances as a live liability line in their monthly management reporting, visible to the founder and the producer running the P&L, rather than as a once-a-year accounting adjustment surfaced at year-end close, where a six-figure unrecouped balance can surprise a founder who has stopped watching it. The tooling is almost never the constraint at this stage. The cadence is.