A global brand running Tmall, JD, and Douyin stores receives a stream of settlement statements, each with its own line items—commission, tech service fee, platform-funded coupons, deposits, penalties, logistics recharges, and reserve holds. Before any of that can become a consolidated China P&L, every one of those line items has to land in the right general ledger account in your ERP. Get the mapping wrong and your revenue is overstated, your marketing cost is buried inside a net revenue figure, and your China numbers refuse to reconcile at group level. This is why a disciplined China marketplace chart of accounts mapping is the quiet backbone of unified P&L visibility.
China marketplace chart of accounts mapping is the rule set that translates every line item on a Tmall, JD, Douyin, or Pinduoduo settlement statement into a specific general ledger account in your ERP—so that gross sales, platform fees, subsidies, taxes, and cash movements are each posted to the correct revenue, contra-revenue, expense, asset, or liability account consistently across every marketplace and legal entity. Done well, it turns raw platform payout files into audit-ready journal entries that consolidate without manual rework.
The short answer: why a mapping layer sits between the platform and your GL
A marketplace settlement statement is not a chart of accounts. It is a payout reconciliation built for the platform’s cash cycle, not for your accounting. A mapping layer resolves three mismatches at once:
- Granularity mismatch — one payout line (“service fee”) may need to split across several GL accounts, or many order-level lines may roll up into a single revenue account.
- Gross-versus-net mismatch — platforms report a net cash figure, but your GL needs gross revenue with each deduction posted separately, which is the heart of the GMV-to-net-revenue bridge.
- Naming mismatch — Tmall’s “技术服务费” (tech service fee), JD’s “扣点”, and Douyin’s commission are the same economic concept under three different labels and must map to one consistent account.
The mapping layer is what lets you post consistent journals no matter which platform the file came from—the prerequisite for clean group consolidation.
Why China marketplace COA mapping is harder than a Western payment gateway
Teams that mapped Stripe, PayPal, or Amazon settlements to their GL often assume China is the same exercise with different vendor names. Four structural differences make it a distinct problem.
1. Every platform uses a different statement schema
Tmall, JD, Douyin, Pinduoduo, and Xiaohongshu each publish settlement data with different columns, fee definitions, and sign conventions. A field called “deduction” on one platform is a marketing cost; on another it is a quality penalty. There is no shared schema, so the mapping must be maintained per platform—one reason off-the-shelf ERP connectors break on China data.
2. Principal-versus-agent treatment changes the accounts
Whether you record gross revenue and platform commission as an expense, or only net commission as revenue, depends on your principal-versus-agent assessment under IFRS 15 or ASC 606. The same JD payout maps to a completely different set of accounts for a 1P wholesale model versus a 3P marketplace model, so the COA logic has to be model-aware, not just platform-aware.
3. VAT and fapiao sit outside the payout file
Output VAT is driven by the official fapiao, not by the settlement statement. Your mapping must therefore reserve accounts for output VAT payable and input VAT recoverable—governed by China’s State Taxation Administration rules—that are populated from tax records, then reconciled against the revenue you posted from settlement—two data sources feeding one coherent GL.
4. Multiple entities and currencies per store
A single brand may operate a store through a China WFOE, a Hong Kong entity, and a Tmall Partner, each requiring its own entity dimension and functional currency. The mapping is not just account-to-account; it is line-item-to-(account × entity × currency), so the same fee type routes to different subsidiary ledgers before it rolls up.
How to build the settlement-to-GL mapping, step by step
- Inventory every line-item type per platform. Export several months of settlement files and enumerate the distinct fee, subsidy, deduction, and adjustment codes each marketplace actually uses—not the documented list, the observed one.
- Classify each type economically. Tag every line as gross revenue, contra-revenue (returns, refunds), platform fee, marketing/subsidy, logistics, penalty, tax, deposit/reserve, or cash movement.
- Assign a target GL account per class. Map each economic class to a specific account in your ERP chart of accounts, respecting your fees-to-net-margin structure so marketing subsidies never hide inside net revenue.
- Add entity and currency routing. For each store, define which legal entity and functional currency the journal posts to, and the FX rate source for translation.
- Encode sign and timing rules. Normalize each platform’s sign convention and define whether the line posts on order, on settlement, or on payout, so accruals land in the right period.
- Validate against a known close. Run the mapping over a prior month and confirm the posted journals reproduce a settlement total you already reconciled by hand before trusting it in production.
A reference mapping: common line items to GL accounts
The exact account numbers belong to your COA, but the economic routing below is consistent across most global brands running China marketplaces:
- Gross merchandise value → Revenue (gross sales), by channel dimension.
- Returns and refunds → Contra-revenue, never netted silently against gross sales.
- Platform commission / tech service fee → Cost of sales or selling expense (principal model); or netted into revenue (agent model).
- Platform-funded coupons → Typically contra-revenue; seller-funded coupons → marketing expense—two accounts, not one.
- Advertising and traffic spend (Zhitongche, JD Zhun, Qianchuan) → Marketing expense, kept out of the fee line.
- Logistics and warehousing recharges → Fulfilment cost.
- Penalties and fines → Other operating expense, flagged for dispute follow-up.
- Deposits, margins, and reserve holds → Balance-sheet asset (restricted cash / receivable), not P&L.
- Output VAT → VAT payable liability, sourced from fapiao records.
- Net payout received → Bank/cash, cleared against the marketplace receivable.
The last two rows are where most teams go wrong: reserves are a balance-sheet item, and the payout must clear an open receivable created at the point of sale—the mechanics covered in settlement reconciliation.
Failure modes that corrupt the China P&L
- Net-posting the payout. Booking only the cash received as revenue erases commission, ad spend, and subsidies from the P&L, making China look artificially high-margin and impossible to benchmark.
- One dumping-ground fee account. Collapsing commission, penalties, and logistics into a single “platform fees” line destroys the cost visibility finance needs to defend channel decisions.
- Ignoring reserves. Treating deposit and reserve holds as expense understates assets and misstates cash flow.
- Unversioned mappings. When platforms add a fee code and no one updates the map, the line falls into a suspense account and quietly breaks the close.
- No data-quality gate. Mapping dirty inputs just posts errors faster; a data-quality layer between platform and ERP has to sit in front of the map.
A mapping health check for finance and ERP teams
- Does every platform line-item code resolve to exactly one GL account, with a monitored suspense account for the unmapped?
- Are gross revenue, contra-revenue, platform fees, marketing, logistics, penalties, tax, and reserves each in distinct accounts?
- Is the mapping model-aware (principal vs agent) per store and per platform?
- Does every line carry entity and functional-currency routing before it posts?
- Is output VAT sourced from fapiao and reconciled against settlement-derived revenue?
- Is the mapping version-controlled, with alerts when a platform introduces a new code?
- Can you trace any GL balance back to the specific settlement lines that produced it?
How Digate fits
Digate connects Chinese marketplaces—Tmall, JD, Douyin, and Pinduoduo—directly to Western ERPs such as NetSuite and SAP S/4HANA, and the chart-of-accounts mapping layer is where much of that value lives. Digate maintains a normalized model of each platform’s settlement schema, applies your account, entity, and currency routing, validates the data before it posts, and generates audit-ready journals with full line-level traceability. When a platform changes a fee code, the mapping is updated centrally instead of breaking a spreadsheet—so finance gets a China P&L that consolidates on the first pass, not the third.
Frequently asked questions
What is a settlement-to-GL mapping for China marketplaces?
It is the documented rule set that assigns every line item on a Tmall, JD, Douyin, or Pinduoduo settlement statement to a specific general ledger account, entity, and currency in your ERP, so raw payout files become consistent, reconcilable journal entries.
Should platform commission be revenue or an expense?
It depends on your principal-versus-agent treatment under IFRS 15 or ASC 606. Principal sellers record gross revenue and book commission as a cost; agents record only net commission as revenue. The COA mapping must reflect whichever model applies to that store.
Why can’t we just import the net payout as revenue?
Because the net payout has already had commission, subsidies, penalties, and reserves removed. Booking it as revenue hides your true cost structure, overstates margin, and makes the China P&L impossible to benchmark or consolidate correctly.
How do reserves and deposits get mapped?
As balance-sheet items—restricted cash or a receivable—not as P&L. They represent cash the platform is holding, and they clear when released, so treating them as expense misstates both assets and cash flow.
How often does the mapping need updating?
Whenever a platform introduces or renames a fee code, which happens most around major promotions. A healthy mapping is version-controlled and alerts finance when an unmapped line appears, rather than silently routing it to suspense.