Book a Demo
Book a Demo
Login

China Marketplace Pre-Sale Deposits: Recognizing 618 & Double 11 Deposit-and-Balance (定金/尾款) Revenue in Your ERP (2026)

China marketplace pre-sale deposits are the upfront, partial payments (定金, dìngjīn) that shoppers put down during Tmall, JD.com, and Douyin pre-sale events like 618 and Double 11 — weeks before they pay the balance (尾款, wěikuǎn) and the goods actually ship. Under ASC 606 and IFRS 15, that deposit is not revenue when it lands. It is a contract liability (deferred revenue) that you only recognize when control of the goods transfers at fulfillment. Booking pre-sale deposits as revenue on receipt overstates a brand’s China topline during peak season and opens a reconciliation gap that can take weeks to unwind.

For global brands, the pre-sale window is where China ecommerce accounting quietly goes off the rails. During the 618 shopping festival and Double 11, a large share of GMV is collected as deposits in one accounting period and fulfilled in the next — sometimes across a month-end or even a quarter-end boundary. If you recognize the deposit too early, your revenue spikes in the wrong period; if you never track it cleanly, you cannot tie platform settlement files back to your ERP. This guide explains the deposit-and-balance model on Tmall, JD, and Douyin, how ASC 606 and IFRS 15 revenue recognition treats pre-sale deposits, and how to map deferred deposit revenue into NetSuite or SAP without breaking your China P&L.


What is a China marketplace pre-sale deposit (定金/尾款)?

A pre-sale deposit is a two-stage payment structure that Chinese marketplaces use to lock in demand ahead of a major promotion. Instead of paying once at checkout, the shopper pays in two installments:

  • The deposit (定金, dìngjīn) — a small non-refundable down payment (often 10–20% of the price, sometimes as little as ¥20–¥100) paid during the pre-sale window, days or weeks before the event peak. It reserves the item, the pre-sale price, and any deposit-multiplier discount.
  • The balance (尾款, wěikuǎn) — the remaining amount, paid during a short balance-payment window on the sale day itself (for example, the night of November 11 for Double 11). Only after the balance is paid does the order become a shippable, fulfillable transaction.

Crucially, the deposit and the balance frequently fall in different accounting periods. A deposit collected on October 24 for a Double 11 order is cash in your platform account weeks before the goods ship in mid-November. That timing gap — not the amount — is what makes pre-sale deposits an accounting problem rather than a routine payment.

How the deposit-and-balance model works on Tmall, JD, and Douyin

The mechanics differ slightly by platform, but the revenue-recognition principle is identical: cash arrives in stages, control transfers only at fulfillment.

  • Tmall / Taobao (预售, yùshòu): The classic 定金 + 尾款 model. Deposits are typically non-refundable and often carry a multiplier (“定金膨胀”) — a ¥50 deposit might be worth ¥100 off the balance. Deposit and balance are recorded as separate transactions in the settlement file.
  • JD.com (京东预售): Similar deposit-plus-balance structure, with JD’s own presale terms and coupon stacking. JD’s settlement timing and refund rules for the deposit portion differ from Tmall’s.
  • Douyin (抖音 pre-sale & 预售): Pre-sale is increasingly tied to livestream events, where deposits are collected in-stream and balances due after the broadcast window. Douyin’s data structure separates deposit and balance events but labels them differently again.

The result is three platforms, three data schemas, and three sets of deposit/balance/refund rules — all of which have to be normalized before they can post to a single ledger. This is the same data-quality problem that undermines every China ERP integration, concentrated into a few high-stakes peak-season weeks.

When do you recognize pre-sale deposit revenue?

You recognize revenue when control of the goods transfers to the customer — at fulfillment — not when the deposit or the balance is collected. Both ASC 606 and IFRS 15 treat customer payments received before performance as a contract liability (deferred revenue). Walking the five-step model:

  1. Deposit received (定金): Record cash and an offsetting contract liability (deferred revenue). No revenue yet — you have not transferred any goods.
  2. Balance received (尾款): Increase cash and the contract liability again. Still no revenue — you have only collected the full price, not shipped anything.
  3. Goods shipped / control transfers: Now recognize revenue for the full order value, release the contract liability, and record the corresponding cost of goods sold.
  4. Platform settlement: When the marketplace remits net proceeds (after commissions, subsidies, and coupons), reconcile the settled amount against the recognized revenue and post the platform fees.

This is the same principal-vs-agent and gross-vs-net logic covered in our guide to China marketplace revenue recognition — layered on top of a timing problem. For authoritative treatment, see the IFRS 15 standard and the U.S. equivalent under FASB ASC 606; the concept of a payment-before-performance liability is explained plainly in this overview of deferred revenue.

Why pre-sale deposits break your China P&L

When brands book deposits as revenue on receipt — or simply wait for the platform settlement file and reverse-engineer the numbers — several failures compound during peak season:

  • Period distortion: Deposits collected in October inflate October revenue for a sale that economically belongs to November, breaking month-over-month trend analysis and any quarter-end cutoff.
  • Phantom topline at peak: Reporting gross deposit inflows as sales makes 618 and Double 11 look larger than the fulfilled, recognizable revenue — a number no auditor will accept.
  • Refund and non-payment leakage: A portion of balances are never paid, so a slice of “pre-sold” GMV never converts. If you recognized it early, you now have to claw it back.
  • Settlement mismatch: Platform settlement files net deposit, balance, fees, and coupons into payouts that arrive on their own schedule, making it nearly impossible to tie cash to revenue after the fact.

These are the mechanics behind why your China P&L is always two weeks late: the pre-sale period injects a wave of deferred cash that your ERP has no clean way to hold and release.

Forfeited deposits, refunds, and coupons: the edge cases

Peak-season pre-sales generate edge cases that a simple deferred-revenue journal does not cover:

  • Forfeited deposits: If a shopper pays the 定金 but never pays the 尾款, the deposit is typically non-refundable and forfeited. That forfeited amount is not product revenue — it is usually recognized as other income when the balance window closes and the contract is cancelled.
  • Deposit multipliers (定金膨胀): The extra discount value created by the multiplier is a platform- or brand-funded promotion, not cash. It has to be modeled as a discount against the balance, not as additional deposit revenue.
  • Refunds and returns: Once fulfilled orders start coming back, deposit-based orders flow into your normal returns process — see our guide to China marketplace returns reconciliation.
  • Coupons and subsidies at balance payment: Platform-funded and brand-funded coupons applied to the 尾款 change net proceeds and must be split correctly, exactly as in ordinary fee and net-margin reconciliation.

How to map pre-sale deposits into NetSuite or SAP

The clean pattern is to treat every pre-sale order as a contract liability that is opened, topped up, and released across events. In practice that means:

  1. Capture deposit and balance as distinct events from each platform’s data feed, keyed to a single pre-sale order ID so the two installments stay linked across periods.
  2. Post both payments to a deferred-revenue (contract liability) account, not to revenue — with the marketplace, event (618 / Double 11), and currency tagged for later reconciliation.
  3. Trigger revenue recognition on the fulfillment event, releasing the contract liability to revenue and booking COGS, in the period the goods actually ship.
  4. Reconcile against the settlement file, matching net payouts to recognized revenue and posting commissions, subsidies, and coupons — after converting RMB settlements to your reporting currency.
  5. Sweep unpaid balances and forfeited deposits when the balance window closes, so deferred revenue never carries stale, never-to-be-fulfilled orders.

Done well, this folds straight into your China ecommerce month-end close and feeds a single unified China P&L — instead of a peak-season scramble to explain why the topline moved.

A pre-sale close checklist for 618 and Double 11

  • Are deposits and balances both posted to deferred revenue, not to sales?
  • Is each deposit linked to its balance and fulfillment by a single order key across periods?
  • Have you recognized revenue only for orders that actually shipped in the period?
  • Are forfeited deposits from unpaid balances swept and classified correctly?
  • Are deposit multipliers, coupons, and subsidies modeled as discounts, not revenue?
  • Does recognized revenue tie back to the platform settlement file after FX conversion?

How Digate handles pre-sale deposit reconciliation

Digate connects Tmall, JD, Douyin, and Pinduoduo directly to Western ERPs like NetSuite and SAP, normalizing each platform’s deposit, balance, refund, and settlement events into one consistent model. Pre-sale deposits are captured as contract liabilities the moment they are collected, kept linked to their balance and fulfillment across period boundaries, and released to revenue only when goods ship — so 618 and Double 11 land in your P&L as fulfilled, recognizable revenue rather than a wave of deferred cash. It is the same China-to-ERP data integration layer that generic connectors like Celigo, Workato, and Boomi do not cover for Chinese marketplaces.

Frequently asked questions

Is a China marketplace pre-sale deposit refundable?

The 定金 (deposit) is typically non-refundable if the shopper fails to pay the balance, whereas an ordinary prepayment (预付款) may be refundable. Because the deposit is usually forfeitable, it should be held as a contract liability and only released — to revenue on fulfillment, or to other income if forfeited — never booked as sales on receipt.

When should I recognize revenue from a Double 11 pre-sale?

Recognize revenue when the goods ship and control transfers to the customer, which for Double 11 pre-sales is usually mid-November — even though the deposit was collected in late October. Both the deposit and the balance are deferred revenue until fulfillment.

How do pre-sale deposits affect my China GMV vs. revenue?

Pre-sale deposits inflate collected cash and reported GMV before any revenue is earned. Recognized revenue should always trail GMV during a pre-sale event, converging only as orders are fulfilled and unpaid balances are swept out.