Milestone Payment Checklists for Indie Publisher Deals - Scope Acceptance and Receipt Evidence 2026

Milestone payments are the lifeblood of indie publisher deals. They are also the most common place a small team's cashflow stalls. Not because the work was bad, and usually not because the publisher is hostile. The payment stalls because what counts as "delivered" was never written down in a way both sides could verify - and because the team did not assemble the receipt-style evidence the publisher's finance and diligence reviewers now expect in 2026.

This guide is the practical checklist for fixing both halves. You'll get a scope acceptance document template, a receipt evidence standard that mirrors what your CI pipeline already emits, a 24-hour pre-milestone pack, per-phase checklists across prototype through launch, and a receipt vault layout that survives an external auditor reading your contract three years from now.

This is not a contract template - real contracts need a lawyer. This is the operational layer that sits underneath the contract, where most cashflow accidents actually happen.

Who this is for and what you'll get

• Who: Indie teams of one to fifteen people signing or already inside a publisher deal in 2026, including platform-fund deals (Xbox, PlayStation, Nintendo, Apple Arcade, Netflix, etc.), traditional advance-and-recoup publisher deals, and milestone-based work-for-hire co-development.
• Result: A standing pre-milestone packet you can re-use every milestone, evidence files that pass a 30-minute diligence review, and a payment cycle that does not surprise your cashflow.
• Time investment: About a half-day to set up the templates and vault once, then 90-120 minutes per milestone to assemble the pack.

The three jobs of this document are simple. Make acceptance criteria unambiguous before the work starts. Make receipt evidence reproducible before the work ends. Make the milestone hand-off boring so finance can release the wire on the day they said they would.

Why this matters now (2026)

Three things shifted in the past 12-18 months that pushed milestone diligence from a polite formality to a hard gate.

1. The 2024-2025 layoff and refund wave tightened publisher finance. Layoffs across mid-size publishers and platform-fund teams meant fewer producers per deal. The producer who knew your project verbally moved on, and the replacement reads only what's in the deal room. If your milestone evidence is "we shipped a build, trust us," it dies on the first inbox triage.

2. AI-generated deliverables made "what was delivered" harder to verify. Publishers now ask for evidence that what they accepted was actually built, not generated wholesale on the day of submission. CI build IDs, source repo commit hashes, asset provenance lines, and review-time replay packets have become standard requests. This is the same trust gap that drove SBOM (software bill of materials) and SLSA build provenance to become routine for partner audits. See the ninety-minute SLSA attestation pass for Unity and Godot partner audits in 2026 for the build-provenance side.

3. Receipt-style evidence (artifact digests, replay packets, manifest diffs) became normalized. Partner certification work for Steam, Meta, Apple, and the console platforms began routinely asking for evidence that ties a specific build to a specific milestone. Once your CI is already emitting these digests for cert weeks, your publisher milestone deliveries can re-use the same evidence shape - that's the leverage move this guide is built around. The build-content hash lockfiles pattern is the canonical version of that pattern for Unity Addressables.

The teams getting milestone wires on the same day as the milestone delivery in 2026 are the ones who turned this evidence into a habit, not a panic.

Milestone vocabulary you have to keep straight

Three words get used interchangeably and they are not the same thing. If your contract treats them as the same, you will lose at least one payment cycle figuring it out.

• Delivery. The act of handing over the milestone (build, asset pack, design doc, etc.). Delivery is mechanical. You either uploaded the artifact or you didn't.
• Acceptance. The publisher's confirmation that the delivered milestone meets the scope acceptance criteria. Acceptance is judgmental. It can be granted, granted with conditions, or refused with a remediation list.
• Invoice / payment trigger. The contract clause that says the publisher will pay. Almost every modern indie publisher deal triggers payment on acceptance, not on delivery. A small but growing number of 2026 deals also require a short acceptance review window (5-15 business days) before the payment clock even starts.

This means the payment date you should be modeling in your cashflow is acceptance + payment terms, not delivery + payment terms. If you are modeling delivery + 30, you are budgeting four to six weeks too short.

The Scope Acceptance Document (write it before kickoff)

The single most useful artifact in any milestone deal is the Scope Acceptance Document (SAD). One per milestone. Written and signed by both the dev lead and the publisher producer before development on that milestone begins.

If your deal already includes a milestone schedule, the SAD is the per-milestone expansion of one row of that schedule. If it doesn't, the SAD is the missing piece your contract is silent about.

A working SAD has eight short sections.

1. Milestone header

• Milestone ID (e.g. M3-VerticalSlice), version (always v1 initially), and target acceptance date.
• The contract clause and payment amount this SAD binds to (e.g. "Section 4.3, USD 35,000 on acceptance").
• Names and roles of both signers (dev lead + producer is enough; do not list five people).

2. Scope summary in one paragraph

Plain language. No bullets. Three to five sentences. What this milestone proves about the game.

3. Acceptance criteria as a numbered checklist

Each line is observable: a reviewer can check it without reading your mind. "Combat feels good" is not observable. "Three enemy types each have at least one telegraphed wind-up animation and one stagger reaction on hit" is observable.

Aim for 8-15 lines. Anything below 8 is usually vague; anything above 15 is usually a sign two milestones got merged into one.

4. Scope exclusions (what this milestone is not)

The single most underused section. Two to five lines, each starting "This milestone does not include..." This is where you head off the "wait, where is X?" surprise email.

5. Build / asset / doc deliverables list

• Build platform(s) (e.g. PC Windows x64; Steam internal branch m3-vs).
• Build identity (Steam appID + depot id, or itch.io channel, or .zip with manifest).
• Asset packs (file list, format, naming convention).
• Documents (design overview, capture video links, screenshot folders).

6. Receipt evidence required

Explicit list of evidence files the dev will hand over alongside the milestone (see the next section). Putting this in the SAD up front means the publisher cannot ask for new evidence shapes during review.

7. Acceptance review window and remediation lane

• How many business days the publisher has to accept or list remediation items (5-15 typical in 2026).
• What "conditional acceptance" looks like and whether it still triggers payment immediately or only after remediation.
• The cap on remediation cycles per milestone (one or two; never open-ended).

8. Signatures and date

Two named human signers, dated. Email exchange with the SAD attached and "approved" written in the body is acceptable for almost all indie deals, and reads cleanly in a deal-room export.

The SAD is short. Two pages, sometimes three. It is not a design document. It is the acceptance contract for the slice of work this milestone covers.

The Receipt Evidence Standard

This is where 2026 indie milestone discipline diverges from the older "send a build and a recap email" pattern. A clean receipt evidence pack contains five files, every milestone, in the same shapes every time.

1. Build identity record (build-identity.txt)

For a code build, include:

• Engine and engine version (e.g. Unity 6.6 LTS (6606.0.42f1) or Godot 4.5.1).
• Git commit hash (full SHA-1) plus branch name and tag if any.
• Build configuration (Release, IL2CPP/Mono, ASTC compression flags, etc.).
• Build machine identity (CI runner ID or local host fingerprint).
• Build timestamp (ISO 8601, UTC).
• Output binary SHA-256 hash and total size in bytes.
• Steam appID + depot ID, or itch.io channel slug, or other distribution identity.

Five to ten lines. Plain text. Copy-pasted into the milestone email body so it survives any zip extraction issue.

2. Asset pack manifest (asset-manifest.csv)

If the milestone includes asset deliverables (art, audio, design docs), list one row per file with:

• Relative path inside the asset pack.
• SHA-256 hash of the file.
• File size in bytes.
• A one-column "origin" field that says either dev-authored, licensed-pack:<pack name>, or ai-assisted-<tool>-then-revised. The ai-assisted flag matters for any 2026 publisher who has a content provenance clause in the contract.

3. Acceptance criteria evidence map (acceptance-criteria-map.md)

A short markdown table that maps each numbered acceptance criterion from the SAD to:

• The build / asset / doc that satisfies it.
• A short note on how to verify (e.g. "main menu - new game - skip cutscene - first combat encounter").
• Optional: a 30-90 second video link demonstrating the criterion in motion.

This is the file that wins you the milestone in one read. Producers love it. Finance reviewers love it. You will love it the third time you need to find the evidence for a milestone you delivered eight months ago.

4. Review-time replay or capture bundle (captures/)

A folder of short captures (5-90 seconds each, .mp4 or .webm) demonstrating each acceptance criterion you can not just point to in the build. Title each capture criterion-NN-shortname.mp4.

This is your defense against "the reviewer ran the build but it didn't crash for them at line 4 of the criteria checklist." Captures sit in the deal room forever; the reviewer's local PC does not.

5. Known issues log (known-issues.md)

Two columns - description, severity. Add a third column for "publisher-acknowledged on signing" if you are flagging anything that the publisher previously accepted as out-of-scope.

The known issues log is honesty insurance. Publishers expect issues at every milestone except RC. A clean known-issues file proves you triaged honestly. An empty known-issues file at vertical slice raises suspicion, not trust.

The 24-Hour Pre-Milestone Pack

Two business days before you deliver, run this 90-120 minute pre-milestone packet build. Doing this the day-of will cost you payment lag.

1. Lock the milestone branch. No new commits after the lock. Tag it (m3-vs-rc1).
2. Run the CI build pipeline against the locked tag. Save build logs, including warnings.
3. Compute the binary SHA-256 from the CI artifact, not your local machine. Locally-built binaries and CI binaries should match; if they don't, find out why before delivery.
4. Fill build-identity.txt with the CI run number, hash, and Steam/itch identity.
5. Run the asset hashing script across the deliverable pack to produce asset-manifest.csv. (A short PowerShell or shell loop with certutil -hashfile or sha256sum is enough.)
6. Fill the acceptance criteria evidence map referencing the SAD line items.
7. Record the captures folder, one short clip per criterion that needs visual proof.
8. Update the known-issues log with the current bug tracker snapshot, severity-coded.
9. Email the producer a "delivery preview" 24-48 hours before with the SAD reference number and the expected delivery time window. Producers schedule reviews this way; surprise deliveries land at the bottom of the queue.

When the milestone day comes, you upload the build, attach the evidence pack, and send a 4-line email that says what was delivered, where to find it, when you expect acceptance, and one sentence summary of known issues. That is it.

Per-Phase Milestone Checklists

Different milestones answer different publisher questions. The acceptance criteria density and receipt evidence emphasis shift across phases.

Prototype milestone

Publisher's question: "Does the core loop feel like the thing we're paying for?"

• Acceptance criteria density: 6-8 items focused on the core verb, the player goal in one session, and one piece of art-direction-of-record (key art or first level mood).
• Required evidence: build, one 60-90 second capture of the core loop, one design doc page describing the win/lose conditions.
• Risk to manage: scope drift in the contract. Many indie deals begin here with a verbal "we'll figure out specifics at vertical slice." Resist that. If the SAD for prototype is weak, every milestone after it inherits the weakness.

Vertical slice milestone

Publisher's question: "Can you actually ship the thing?"

• Acceptance criteria density: 10-15 items covering at least one fully polished playable segment (15-30 minutes of gameplay), the art-direction lock, the UX lock, and the targeted hardware tier(s).
• Required evidence: build, asset-manifest covering the slice content, acceptance-criteria evidence map, 5-10 short captures, known issues log.
• Risk to manage: the "vertical slice but really alpha" trap. Publishers will sometimes try to expand the slice into something closer to alpha during review. The scope exclusions section of your SAD is your defense.

Alpha milestone

Publisher's question: "Is the game complete in shape, even if rough?"

• Acceptance criteria density: 12-20 items covering all systems present (even rough), all levels/content scaffolded, all UI screens at least placeholder, save/load working.
• Required evidence: build, asset-manifest, criteria evidence map, a 5-15 minute longer capture demonstrating multiple systems in sequence, performance budget snapshot (FPS at target hardware), localization plan (even if only English text exists, the plan exists).
• Risk to manage: the "alpha but really beta" trap. Polish creep happens here.

Beta milestone

Publisher's question: "Is the game feature-complete and content-locked?"

• Acceptance criteria density: 15-20 items covering content-lock per area, all systems shipping-quality, accessibility flags addressed, save migration tested if there have been save changes, performance within budget on minimum spec.
• Required evidence: build, asset-manifest with licensed-pack: provenance fully filled, acceptance-criteria evidence map, captures for any criterion that requires hardware-specific evidence (handheld, controller, accessibility), QA report with bug counts by severity, known issues log with severity caps respected.
• Risk to manage: late art changes. The single most expensive late change in any indie deal is "let's tweak the art direction." Once beta is signed, that change should be re-pitched as a contract amendment, not absorbed into beta.

Release Candidate (RC) milestone

Publisher's question: "Is this the version we can submit to platforms?"

• Acceptance criteria density: 8-12 items focused on partner-submission readiness, not new content. Build identity must match what is being submitted to Steam, Meta, Apple, Sony, Nintendo. SBOM and license-notices hygiene complete. Privacy labels filled. Notarization done where applicable.
• Required evidence: build SHA-256 matching the platform-submitted binary, SLSA-style attestation evidence, SBOM and dependency receipts, third-party license notices pass, platform smoke pass screenshots (Steam Deck Verified pre-check, Meta Quest store listing preview, etc.), and a copy of any platform reviewer feedback already returned.
• Risk to manage: the cert-bounce loop. Pair this milestone delivery discipline with the 7-Day Release Candidate Freeze Challenge so the publisher inherits a "frozen" build, not a moving target.

Launch and post-launch milestones

Publisher's question: "Are commitments after launch being met?"

• Acceptance criteria density: 5-10 items per post-launch milestone. Update cadence promises, patch quality bar, hotfix response window, localization coverage for any additional languages contracted.
• Required evidence: build per patch with SHA-256, patch rollback rehearsal evidence, QA reports per patch.
• Risk to manage: post-launch scope sprawl. The contract probably allows the publisher to request reasonable updates. "Reasonable" needs a working definition - put it in each post-launch SAD.

The Acceptance Conversation Template

When the milestone is delivered, the conversation often goes one of three ways. The cleanest version is:

Day 0 (Friday afternoon): Build + evidence pack uploaded. Email: "Delivered milestone M3-VerticalSlice per SAD v1. Build ID and SHA in build-identity.txt. Acceptance review window per Section 4.6 (10 business days). Known issues log attached. Producer call scheduled Wednesday."

Day 3 (Wednesday call, 30 min): Walk the producer through the acceptance-criteria evidence map. Producer flags 2 items for clarification. You record the clarifications in a producer-review-notes.md file in the same evidence folder.

Day 5-7: Producer accepts in writing. Finance receives a copy of the acceptance email and the SAD reference. Wire is scheduled.

The acceptance email is short. Something like "Approved per SAD v1, please proceed to payment." That email is the single most important piece of paper in the whole deal. Save it. Save it twice. It is what unlocks the wire.

The Receipt Evidence Vault (file naming and retention)

A vault is not fancy. It is a folder structure that survives three years of personnel changes, deal renewals, and the inevitable laptop dying.

publisher-deals/
  <publisher-slug>/
    <project-slug>/
      contract/
        deal-signed.pdf
        amendments/
      milestones/
        M1-Prototype/
          SAD-v1.pdf
          acceptance-email-2026-02-14.txt
          build-identity.txt
          asset-manifest.csv
          acceptance-criteria-map.md
          known-issues.md
          captures/
        M2-...
        M3-...
      payments/
        m1-invoice-2026-02-14.pdf
        m1-wire-confirmation-2026-02-28.pdf
        ...

Three rules for the vault:

1. Hash-stable evidence. Each build-identity.txt and asset-manifest.csv is regenerated from CI, not edited by hand after the fact. If you re-build to fix a typo, the manifest changes - you generate a new manifest and call the milestone v2.
2. Acceptance emails are forever. Convert them from your mail client to .eml or .pdf and drop them in the milestone folder. Email accounts churn; the vault doesn't.
3. Retain for at least three years past the last payment. Most indie publisher deals have a 24-36 month tail of audit and reconciliation rights. The vault must outlive that tail.

If you have a private Git LFS repo or an encrypted bucket, put the vault there. If not, an encrypted folder on two physical machines with backups is the floor.

Common failure modes that cost milestone payments

Real, repeated reasons indie teams lose milestone cycles. Each one is preventable with one of the artifacts above.

• "We delivered, why hasn't payment moved?" Almost always because acceptance is missing in writing. Fix: chase an acceptance email, not a wire confirmation.
• "The producer wants to add scope to this milestone." Mid-milestone scope expansion. Fix: point at the SAD's exclusions section. Anything outside is a contract amendment with its own payment.
• "We can't reproduce the build we sent." Loss of the build identity record means you cannot defend evidence. Fix: every build that leaves your machine has an entry in the vault, including failed pre-milestone attempts.
• "The publisher's finance team has new diligence questions." New person on the deal asking about SBOMs or AI provenance. Fix: the receipt-evidence pack already covers it - re-send the existing files, do not redo work.
• "The milestone calendar slipped, we missed the next milestone too." Slipping one milestone cascades because you didn't re-baseline the rest. Fix: every slip requires an updated milestone schedule signed in email; treat it as a mini-SAD-revision.
• "The acceptance review window expired without an answer." Some contracts default to acceptance after silence; some don't. Fix: know which yours is, and chase the answer in writing at day 3 and day 7 of the review window.
• "AI-assisted asset provenance got challenged." Publisher asked which assets used generative tools. Fix: the origin column in asset-manifest.csv answers this on day one. Honesty plus evidence beats vague reassurance.
• "The publisher's annual audit caught something." External auditor or platform partner asked for milestone receipts 18 months later. Fix: vault retention. The folder is already there.

Pro tips

• Get the SAD signed on the same week the previous milestone is accepted. This eliminates the "what's the next milestone again?" lag that costs indie teams a week or two per cycle.
• Cap remediation rounds. One paid remediation cycle per milestone is normal. Two is the absolute outer limit. Beyond two, you are eating margin for free.
• Pair payment with the wire-confirmation file in the vault. It closes the milestone loop cleanly and gives your accountant the trail they need at year-end.
• Set a calendar reminder for "acceptance window day 3 and day 7." Politely chase. Producers rotate; calendars rotate; payment days don't.
• Treat each SAD as a re-usable template. By milestone three, your SAD should take 60 minutes to write, not four hours.
• Maintain a single "evidence index" file at the top of the project vault. One line per milestone: ID, status, acceptance date, payment date, vault folder. This is the file you send to your accountant.
• Co-development deals need clarified ownership in every SAD. If you are work-for-hire or co-dev, write the IP and ownership status of each deliverable in the SAD too. The revenue share versus work for hire risk checklist covers the contract framing; the SAD is where that framing becomes operational.

Common mistakes to avoid

• Mistake: "We'll write the milestone criteria when we get closer." No, you won't. Write them at SAD-signing time or accept that the milestone will be subjective at acceptance.
• Mistake: One SAD for the entire deal. SADs are per milestone. A whole-deal SAD is a contract, not an acceptance document.
• Mistake: Submitting evidence in three different formats over the deal. Pick a shape. Use the same shape forever. Producers and finance reviewers triage by familiarity.
• Mistake: Treating captures as "marketing." Captures in the vault are evidence. They are not pretty trailers. Don't waste an hour editing them.
• Mistake: Confusing milestone payment with royalty payment. Recoupment and royalties are separate. Milestone payments do not recoup unless the contract explicitly says so. Re-read the contract before assuming.
• Mistake: Sending the acceptance evidence as a giant ZIP that the publisher's email rejected. Send the evidence in the deal-room folder; send the 4-line summary email pointing to it.
• Mistake: Ignoring the publisher's diligence checklist after acceptance. Acceptance plus diligence are sometimes two separate gates. Confirm both before assuming payment is moving.
• Mistake: Letting cashflow plans assume delivery + 30. Always plan for acceptance + payment-terms, with at least a two-week buffer.

Real-world cashflow example

Say your deal has six milestones: Prototype (USD 20k), Vertical Slice (USD 40k), Alpha (USD 60k), Beta (USD 60k), RC (USD 30k), Launch (USD 30k). Total USD 240k advance.

A team that runs the SAD + evidence discipline above sees payments at roughly:

• Delivery → Acceptance (5-10 business days) → Wire (Net 15-30 from acceptance).
• Average delivery-to-wire: 4-6 weeks across all 6 milestones, predictable.

A team that does not run the discipline sees the same milestones at:

• Delivery → Diligence-back-and-forth (1-3 weeks) → Acceptance → Wire (Net 30-45 from acceptance).
• Average delivery-to-wire: 8-14 weeks, with at least one milestone stalled for 4-6 weeks longer than expected.

For a 6-person team burning USD 35k/month, a single 4-6 week stall is one full month of payroll. The SAD + evidence discipline is, conservatively, worth USD 35-70k per indie publisher deal in avoided runway loss. That is the actual ROI on the half-day setup time.

For the broader funding context (publisher advances vs. platform funds vs. grants and how to layer them), pair this milestone discipline with the indie game funding landscape playbook. For freelancer-side milestone framing (animation buyouts, revision caps), see the animation work quoting guide - the receipt-evidence shape transfers cleanly to freelance work.

Key takeaways

• Acceptance, not delivery, triggers payment. Model cashflow on acceptance + payment-terms, with a 2-week buffer.
• Write a Scope Acceptance Document per milestone. Eight sections, two pages, signed before development on that milestone starts.
• Make acceptance criteria observable. "Three enemy types each with one telegraphed wind-up and one stagger reaction" beats "combat feels good."
• Always include scope exclusions. Two to five lines explicitly listing what the milestone is not.
• Receipt evidence = five files. Build identity, asset manifest with origin column, acceptance criteria evidence map, captures folder, known issues log.
• Run the 24-Hour Pre-Milestone Pack. Lock branch, CI build, hash, manifest, captures, evidence map, known issues, delivery preview email.
• Per-phase milestones have different evidence emphasis. Prototype proves the core loop; vertical slice proves you can ship; alpha proves shape; beta locks content; RC proves submission readiness; post-launch tracks update cadence.
• Vault structure survives personnel churn. Per-publisher / per-project / per-milestone folders with SAD, evidence, acceptance email, and wire confirmation.
• Retain three years past last payment. Most deals have a 24-36 month tail of audit and reconciliation rights.
• Chase acceptance in writing at day 3 and day 7 of the review window. Producer rotation is the single biggest invisible cost to indie cashflow.

FAQ

How long should a Scope Acceptance Document (SAD) actually be?

Two pages, sometimes three. If your SAD is longer than three pages, you have probably merged two milestones into one or you are writing a design document instead of an acceptance document. A SAD is an acceptance contract for one milestone, not a development plan.

What if the publisher pushes back on signing per-milestone SADs?

Frame it as protecting both sides from ambiguity, not as legal overhead. Most experienced producers will welcome the SAD because it makes their finance approval easier. If a publisher refuses to sign per-milestone scope, treat that as a red flag for the entire deal - you will hit the same ambiguity at every milestone and own the cost of resolving it.

Do indie deals with platform funds (Xbox, PlayStation, Nintendo, Apple Arcade, Netflix) need this?

Yes - often more than traditional publisher deals. Platform funds typically have stricter milestone gating tied to platform-specific deliverables (Xbox parity, PSN store readiness, Apple Arcade exclusivity confirmation, Switch certification). The SAD shape is the same; the acceptance criteria density at RC and post-launch milestones is higher.

What's the right SHA-256 hashing tool for the build identity record?

On Windows, certutil -hashfile <file> SHA256 from PowerShell. On macOS and Linux, sha256sum <file> (or shasum -a 256 <file> on macOS). Use the CI runner's output, not your local machine's, so the evidence is reproducible from CI logs alone.

Should milestone evidence be encrypted?

The build identity record and acceptance criteria map are typically delivered through the deal room (which is already encrypted in transit and at rest). Captures and asset manifests live there too. The vault you keep on your side should be encrypted at rest - either on a private LFS repo, an encrypted disk volume, or an S3-class bucket with default encryption. Personnel changes happen; encryption survives them.

If your team has not yet adopted this shape, set up the SAD template and an empty vault folder this week. The next milestone you deliver will be the easiest milestone you have ever delivered - and the first acceptance email will land before your finance plan needed it to.

Found this useful? Share it with your producer on your next milestone call. The cleanest deals are the ones where both sides ran this playbook.