Deferred Revenue Accounting for Client Prepayments

Why That $50,000 Prepayment Isn't 'Income' (Yet)#

A client prepayment is not earned revenue on day one. Under ASC 606 and IFRS 15, cash you receive before transferring the promised service is presented as a contract liability, often labeled deferred revenue, until the work is actually delivered.

That distinction matters because your bank balance and your income statement are telling different stories. The bank balance answers a cash question: did the money arrive? The income statement answers an earning question: did you actually satisfy the obligation tied to that money? Those are not the same event.

A common operational risk looks like this: the prepayment lands, you take a larger owner draw or use some of it for unrelated bills, and later you realize the project still requires labor, software, or subcontractor spend. If the client cancels and your agreement requires a refund, the same cash shortfall turns into a credibility problem quickly.

The practical risk is not just a technical accounting error. Treating advance cash like finished income can push you into bad operating decisions early in the contract. When the delivery work catches up, you are left funding it with less cash than you thought you had. That is why the accounting entry and the cash habit need to line up from the start.

Step 1 Record the prepayment as a liability and separate the cash mentally#

Treat the payment as an obligation, not as spendable profit. In deferred revenue accounting, the first entry increases Cash and increases a liability account such as Deferred Revenue or Contract Liability by the same amount. Nothing hits earned revenue yet because no performance obligation has been satisfied.

You do not need a complicated setup to make this work. You do need a clear barrier between cash received and cash available for general use. Some freelancers use a separate business account or a clearly labeled subaccount for advance payments so they do not spend against future delivery by accident. Even if you keep everything in one operating account, your books should still make it obvious that the cash came in attached to open obligations, which is easier to verify if you already know how to read a balance sheet.

A simple discipline helps here: when the prepayment lands, tie it immediately to the contract file before you move on. That file should let you answer, without guessing, who paid, what they paid for, what remains undelivered, and what refund terms still apply. If you have to reconstruct those facts later from email threads, your close process is already harder than it needs to be.

Verification point: after the deposit posts, your balance sheet should show the prepayment in a liability account, and your income statement should not show the full amount as current-period revenue.

That check is worth doing early, not only at close. If the cash receipt was posted straight to revenue by mistake, the error can spread. You may make decisions off inflated income, calculate owner distributions off numbers that are not really earned, or stop watching the reserved cash because the books appear to say the project is already profitable.

Red flag: if you cannot look at your books and tell how much of that $50,000 is still owed back in services or refunds, you are already exposed.

Another red flag is when the contract file and the accounting treatment live in separate worlds. If the agreement clearly shows open milestones or a service period, but the accounting shows the full amount as current revenue, the problem is not timing alone. Your records no longer reflect the commercial reality of the deal.

Step 2 Tie recognition to the actual delivery trigger#

Revenue should move out of the liability bucket only when your contract says value has been transferred. In practice, these triggers often fall into three patterns.

Use milestone-based recognition when value transfers at clear handoff points, such as strategy approval, design delivery, or launch. Use time-based recognition for retainers, subscriptions, or access-based services delivered evenly across a stated period. If work is performed over time but unevenly, a progress-based method may fit better, but only if you can support the measure with documentation.

Let the contract drive the trigger, not the invoice date and not your internal feeling that the job is mostly done. A bill can go out before delivery. Cash can arrive before delivery. Neither event, by itself, proves that revenue is earned. If you want a broader framework for this timing logic, A Guide to Revenue Recognition for SaaS Companies is a useful companion.

If the agreement says a milestone must be completed or approved, recognition should wait for that event. If the agreement says service is provided across a period, recognition should follow that period rather than bunching the amount into the day cash arrives.

This also matters when a single contract contains more than one pattern. If one part of the engagement is tied to a defined handoff and another part covers a service period, do not force the whole arrangement into one release rule just because that is easier to book. Map each part to the delivery trigger the contract supports, then make sure your records show how you got there.

The control that matters most is your evidence pack: signed contract, scope or statement of work, payment terms, refund terms, milestone definitions, and proof of delivery or service period completed. Without that file, your recognition schedule is hard to defend.

Build a contract evidence pack#

Specifically, keep one working packet that includes the signed agreement, the delivery proof, and a short rollforward showing what moved this month. That packet creates a cleaner audit trail, gives you better variance review, and makes How to Read a Cash Flow Statement more useful because the liability movement now has context.

• Contract packet: agreement, scope, refund clause, and milestone definitions in one place.
• Close packet: a 30-day rollforward that shows opening liability, releases booked, and ending liability.
• Review packet: one owner note that explains why the remaining balance still fits the undelivered work.

Think of the evidence pack as the bridge between the contract and the journal entry. If you release revenue for a milestone, you should be able to point to both the milestone language and the evidence that it happened. If you release revenue over a service period, you should be able to point to the dates and show that the period has passed. If you are using progress-based recognition, your documentation should show how progress was measured and why that measure is the one you are consistently using.

A common failure mode is to start with one recognition idea and then drift as the project evolves. Scope shifts, timing changes, and informal client approvals can blur the original trigger. When that happens, do not leave the old release schedule on autopilot. Update the contract file and your close support so the books still match what the engagement now requires. Then make sure the books actually follow that trigger at each close.

Step 3 Release earned amounts during your close process#

Do not wait until year end to sort this out. Set a recurring close step where you review what was actually delivered and move only that earned portion from the liability account into revenue. The account flow is straightforward:

Run a 30-day close checkpoint#

As a result, set a 30-day checkpoint even if your formal close is quarterly. When we review a file, we look for the opening liability, we look for the release trigger, and we look for the ending balance to tie back to the contract. That same habit turns How to Read a Balance Sheet into a practical control instead of a theory article.

• On receipt: Cash goes up, contract liability goes up.
• As you perform: contract liability goes down, earned revenue goes up.
• At any review date: the remaining liability should equal the value of work still owed.

That last line is the real test. If the remaining liability does not make sense against the work still open, something is off. Either too much has been recognized too early, too little has been released, or the contract support is incomplete. The close review is where you catch that before the error sits in the books too long.

• Receipt week: book the full $12,000 prepayment to contract liability.
• First approved milestone: release $4,000 only if that slice is actually earned.
• Next 30-day review: confirm the remaining $8,000 still matches undelivered work, refund exposure, and delivery cost.

A practical close sequence can be very simple. Pull the list of contracts with open liability balances. For each one, look at the contract terms, the service period or milestones, and the delivery evidence for the period. Decide what was actually earned, book only that amount, and leave the rest in the liability account. Then do one more pass and ask whether the ending balance still matches what you owe. That final comparison often catches the entries that looked reasonable in isolation but do not hold up when you step back. If your month-end packet also includes a simple cash view, How to Read a Cash Flow Statement helps you explain why collected cash and earned revenue are moving on different clocks.

A short checklist keeps this from drifting:

• Create a liability account named Deferred Revenue or Contract Liability.
• Attach each client prepayment to a contract file with service dates, milestones, and refund terms.
• Choose a recognition method that matches each contract obligation and apply it consistently.
• At close, compare the liability balance to open obligations and booked delivery evidence.
• Investigate any negative liability balance, manual override, or fully recognized contract that still has undelivered work.

If you are doing the close yourself, avoid releasing revenue based on memory alone. Pull the documents and verify the trigger each time. That sounds basic, but it is exactly where rushed closes go wrong. You remember that a client was happy with the work, assume the milestone is done, release the amount, and only later notice the formal approval or delivery step had not actually happened yet.

Keep book and tax reviews separate#

One caution on taxes: under the accrual method, income is generally reported when earned, regardless of when cash is received, but tax reporting and financial statement presentation are not always identical. If you are unsure, get the recognition rule and the tax treatment reviewed separately.

That separation matters operationally too. Do not use a tax assumption to justify a financial statement entry, and do not assume a book entry automatically answers the tax question. Keep those reviews distinct so one shortcut does not create two different problems.

If you want a deeper dive, read Hiring Your First Subcontractor: Legal and Financial Steps. Want a quick next step for "deferred revenue accounting"? Try the free invoice generator.