Deferred Revenue Accounting for Client Prepayments

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

For accrual financial statements applying ASC 606 or IFRS 15, a client payment received before the related promised goods or services transfer normally creates a contract liability. This guide addresses that book treatment; cash-basis and tax rules can differ.

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#

Identify the performance obligations, allocate the transaction price and determine whether each transfers over time or at a point in time under the applicable standard. Contract terms and delivery evidence inform that assessment; a billing milestone alone is not a revenue-recognition rule.

A distinct deliverable may be recognized at a point in time when control transfers. For an obligation meeting over-time criteria, use a measure that reflects performance: elapsed time can suit evenly provided stand-ready service, while uneven work may need another supported measure. Doing work over several weeks does not by itself qualify it for over-time recognition.

Apply the recognition standard to the contract rather than using invoice dates or subjective completion estimates. Advance billing and advance cash are separate from transfer of the promised service. See Revenue Recognition for SaaS Companies for a related framework.

Assess whether an acceptance clause is substantive evidence of control transfer or an administrative formality. Payment and approval milestones do not automatically determine revenue timing. For over-time obligations, recognize measured performance even when billing occurs at a later milestone.

When a contract contains distinct promises, allocate the transaction price under the applicable standard and assess each transfer pattern. Multiple billing milestones do not necessarily create multiple performance obligations.

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: opening liability, advance additions, earned releases, refunds or reclassifications, 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 review: reconcile remaining contract liability to allocated consideration for unsatisfied obligations; it is not an estimate of delivery cost.

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.

• Illustrative receipt: debit Cash $12,000 and credit Contract Liability $12,000 for wholly unperformed service.
• If a distinct obligation allocated $4,000 transfers at the first handoff, debit Contract Liability $4,000 and credit Revenue $4,000.
• At the next close, support the remaining $8,000 against unsatisfied allocated obligations; assess delivery costs and any refund liability separately.

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#

Book deferral does not automatically defer U.S. taxable income. Cash-method income generally follows receipt; accrual-method advance payments have their own inclusion and limited deferral rules, subject to eligibility and elections. Review the actual tax method and jurisdiction separately from ASC 606 or IFRS 15 book recognition.

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.