Milestone Billing Accounting: How to Record Deposits and Milestone Payments

Key Takeaways

• A client deposit is a liability on your balance sheet — not revenue — until you satisfy the related performance obligation.
• Under ASC 606 and IFRS 15, revenue is recognized when the client can genuinely use what you delivered and confirms the milestone is complete.
• The five-step revenue recognition model (identify contract → identify obligations → determine price → allocate → recognize) governs when each milestone payment moves from liability to income.
• Milestone billing structures vary widely: one common pattern uses 50% at project start and 12.5% at each of four subsequent milestones — but the accounting treatment follows the same rules regardless of the split.
• Scope creep and late client approvals are the two most common causes of mismatched billing and revenue on software projects.

Milestone billing accounting is the process of recording client payments — deposits and milestone invoices — at the correct point in time: as a liability when cash is received before work is delivered, and as revenue only when a defined performance obligation has been satisfied. Getting this right keeps your balance sheet clean, your monthly close accurate, and your books compliant with ASC 606 and IFRS 15.

This matters more than most studio operators realize. Cash in the bank and revenue earned are two different things. Treating them as the same creates overstated income early in a project, understated income later, and a close process that never quite reconciles.

How Is a Client Deposit Recorded Before Work Begins?

A client deposit received before any work is performed is recorded as a liability, not revenue. The cash hits your bank account (debit: cash), and the offsetting credit goes to a liability account — typically labeled Deferred Revenue or Customer Deposits Payable on your chart of accounts.

This reflects the economic reality: you owe the client either the promised deliverable or a refund. Until you deliver, the money isn't yours to recognize as income.

The journal entry at deposit receipt

Each row above is a hypothetical illustration of the entry pattern, not a measured benchmark.

The liability account balance represents your remaining obligation to the client. It should decrease — and revenue should increase — only as milestones are satisfied.

For software studios managing multiple concurrent projects, this liability balance can grow quickly. A well-structured chart of accounts for software development studios separates customer deposits from other current liabilities so you can see your total project obligation at a glance.

How Do Deposits Appear on the Balance Sheet?

Customer deposits appear as a current liability on the balance sheet, typically under a line called Deferred Revenue or Customer Deposits Payable. They remain there until the corresponding performance obligation is satisfied.

This is one of the most commonly misclassified items in software studio books. Studios using cash-basis accounting — or studios that haven't set up their chart of accounts for project work — often book deposits directly to revenue. That inflates income in the period the deposit arrives and understates it in later periods when the real work gets done.

On an accrual-basis balance sheet, the deposit liability gives you and your clients a clear picture of what's been paid but not yet earned. It also signals to any outside reader — an investor, a lender, or an acquirer — that you understand the difference between cash received and revenue earned.

The balance should reconcile to your open project obligations every month. If your deferred revenue balance is growing faster than you're delivering work, that's a signal worth investigating before it becomes a close problem. See what a monthly close package should include for how this account fits into a complete close review.

When Does a Milestone Payment Become Revenue?

A milestone payment becomes revenue when the related performance obligation is satisfied — meaning the client can genuinely use what you delivered and has confirmed it. This is the core rule under both ASC 606 and IFRS 15.

The standard doesn't care when you invoiced or when cash arrived. It cares when the obligation was met.

The five-step revenue recognition model

Productive.io's 2026 milestone revenue recognition guide summarizes the IFRS 15 / ASC 606 framework in five steps:

1. Identify the contract — your signed statement of work (SOW) or master services agreement (MSA).
2. Identify separate performance obligations — the distinct milestones in the contract.
3. Determine the transaction price — the total amount the client will pay.
4. Allocate the transaction price to performance obligations — split the total across milestones.
5. Recognize revenue when each obligation is satisfied — recognize the allocated portion when the client confirms the milestone is complete.

Step 5 is where most studios get tripped up. "Complete" needs to be defined in the contract — not assumed. If your SOW says "design phase complete" without specifying acceptance criteria or naming who approves, you'll have a dispute every time.

What "satisfied" means in practice

In practice, a milestone is satisfied when:

• The deliverable has been handed off to the client
• The client has had a reasonable opportunity to review it
• The client has confirmed acceptance (in writing, ideally)

If the client hasn't approved, the milestone isn't satisfied — even if you believe the work is done. This is why nearly half of all B2B invoices in the U.S. are paid late: clients need to approve work before payment is triggered, and revisions push that timeline back.

How Are Milestone Payments Structured in Software Contracts?

Milestone payment structures vary by project size, complexity, and client relationship. There's no single standard, but a few patterns are common in software development.

SOFTRAX's 2026 documentation describes one example: a contract with five billing milestones, with 50% due at project start and 12.5% at each of four subsequent milestones. This is one illustrative structure, not a universal benchmark.

Upland Software describes a percentage-of-completion approach: when 40% of the project is done, you bill for 40% of the total. BQE's milestone billing guide shows a more granular breakdown — for example, a project might use 30%, 60%, and 100% milestones for longer phases.

The accounting treatment is the same regardless of the split: cash received before delivery → liability; obligation satisfied → revenue.

All structures in this table are illustrative patterns drawn from the sources cited above, not universal standards.

For studios running multiple project types simultaneously, the fixed-fee software project revenue recognition reference covers how percentage-of-completion and milestone methods compare under ASC 606.

What Happens to Unbilled Work Between Milestones?

Work performed but not yet billed — because the next milestone hasn't been reached — creates work in progress (WIP) on the balance sheet. This is the mirror image of the deposit problem: instead of cash received before work is done, you have work done before cash is billed.

WIP sits as an asset (unbilled revenue or contract asset) until the milestone is invoiced and accepted. Tracking it accurately is what separates a studio with clean financials from one that can't explain why its P&L and cash flow never seem to match.

Software Studio WIP accounting covers how to record and manage unbilled revenue under milestone contracts in detail. The short version: every month, your close should reconcile three things — what's been billed, what's been recognized as revenue, and what's been delivered but not yet billed.

Why Scope Creep Complicates Milestone Billing Accounting

Scope creep is the most common source of accounting errors in milestone-billed projects. When clients request additional work mid-project, the original milestone structure no longer maps cleanly to what's being delivered.

Upland Software's research puts the scale of the problem in context: 50% of projects deal with scope creep, and because of it, only 57% stay within budget, with just 51% finishing on time. A review of nearly 1,500 projects found the average cost overrun is 27%.

From an accounting standpoint, scope creep creates two problems:

1. Milestone definitions become ambiguous. If the deliverable has changed, it's unclear whether the original performance obligation has been satisfied.
2. Revenue allocation breaks down. If the transaction price changes (via a change order), you need to reallocate it across the revised set of obligations.

The fix is contractual, not just accounting: change orders should be documented, signed, and reflected in an updated SOW before additional work begins. That gives your accountant a clean paper trail to follow when it's time to close the month.

How to Keep Your Close Clean on Milestone Projects

A predictable monthly close on milestone-billed projects requires three things to be in sync: your project management tool, your billing system, and your accounting records.

When those three live in separate places — and nobody reconciles them — you end up with deferred revenue balances that don't match open project obligations, WIP that's never been billed, and revenue that was recognized in the wrong period.

Here's what a clean close process looks like for a software studio:

1. Reconcile the deferred revenue balance to open project obligations. Every dollar in that account should map to a specific project and a specific undelivered milestone.
2. Record WIP for work delivered but not yet invoiced. If a milestone was substantially completed before month-end but the invoice hasn't gone out, the revenue should still be recognized in the correct period.
3. Confirm milestone acceptance documentation. Revenue recognition requires client sign-off. If you don't have it, the revenue stays in deferred.
4. Review the project profitability dashboard. Billing progress and cost progress should move together. If you've billed 60% of a contract but burned 75% of the budget, that's a margin problem — catch it now, not at project close.

The software studio project profitability dashboard covers the metric set and review cadence that makes this visible every month.

Frequently Asked Questions

What account does a customer deposit go into?

A customer deposit goes into a liability account — typically labeled Customer Deposits Payable or Deferred Revenue — on the balance sheet. It stays there until the related performance obligation is satisfied. Only then does it move to revenue on the income statement.

Is deferred revenue a current or long-term liability?

Deferred revenue is classified as a current liability when the related obligation is expected to be satisfied within 12 months — which covers most software project deposits. If a project spans more than a year, the portion tied to obligations beyond 12 months may be classified as long-term.

Can you recognize revenue before invoicing a milestone?

Yes. If a performance obligation has been satisfied — the deliverable was completed and accepted — revenue should be recognized in that period even if the invoice hasn't been sent. The unbilled amount is recorded as a contract asset (WIP) on the balance sheet until invoiced.

What is the difference between milestone billing and progress billing?

Milestone billing ties invoices to the completion of specific deliverables. Progress billing ties invoices to the percentage of work completed over time, often on a monthly schedule. Both methods defer revenue until the corresponding work is delivered, but milestone billing requires defined acceptance criteria for each invoice trigger.

Laya provides this content for informational purposes only. This material does not constitute tax, legal, or accounting advice. Please consult your own tax, legal, and accounting advisors before engaging in any transaction.

If your studio's monthly close isn't reconciling deposits, WIP, and recognized revenue cleanly, book an intro with Laya to see how we structure the close for milestone-billed projects.