Every global brand selling on Tmall, JD.com and Douyin eventually hits the same wall: the numbers in the platform back-offices do not add up to a number the CFO can sign. At that point finance and IT face one decision, and it is almost always framed too late and with too little evidence — do we build the China marketplace data integration ourselves, buy a platform that already does it, or keep relying on our TP (代运营) to send us spreadsheets?
Short answer
Rely on your TP when China is under roughly 5% of group revenue and you need reporting, not control. Buy a platform when China is material to the group P&L, you need auditable settlement-level data in your ERP, and you do not have a dedicated China data engineering team. Build in-house only when you have Mandarin-capable engineers on payroll, a mandate to own marketplace APIs as a long-term capability, and tolerance for an 8–14 month runway before the first trustworthy month-end close.
The rest of this guide gives you the evidence to defend whichever of those three you pick — including the costs each option hides, and the five questions that settle the decision faster than a vendor bake-off.
What the three options actually are
These are not three flavours of the same project. They differ in who owns the data pipeline, who owns the reconciliation logic, and who is accountable when a settlement report and the general ledger disagree.
- Rely on your TP (代运营). Your Tmall Partner or store operator runs the storefront and sends you periodic reports — usually Excel, usually monthly, usually in their own format. You own nothing technical. You also verify nothing.
- Build in-house. Your own engineers register on the marketplace open platforms, obtain API credentials, pull orders, settlements, fees, refunds and ad spend, land them in a warehouse, and write the reconciliation and mapping logic that turns them into journal entries.
- Buy a platform. A vendor maintains the marketplace connectors, absorbs API and fee-schedule changes, normalises settlement data across platforms, and delivers a unified China P&L plus an ERP-ready feed.
One thing is common to all three: the output has to survive contact with your ERP. If you have not yet mapped what that means in practice, start with the complete guide to China marketplace–ERP integration, because the target state is the same regardless of who builds it.
Option 1 — Rely on your TP (代运营)
This is the default, because it is the status quo. Your TP already has the data; asking them for a report costs nothing today.
Where it works
It works when China is a test market. If you need to know roughly what GMV was and roughly what you were paid, and nobody downstream is building a forecast or an audit position on it, a TP report is proportionate.
Where it breaks
- Granularity. You receive summaries. Settlement-level detail — the line items that explain the gap between gross sales and the cash that landed — stays on their side.
- Conflict of interest. The party reporting on performance is the party being measured. Ad pass-through and service fees are precisely where reports get generous, and they are exactly the items covered in our TP (代运营) reconciliation guide.
- Audit trail. A spreadsheet emailed by a third party is not evidence. When your auditors ask how a China revenue figure was derived, “our operator told us” is not an answer.
- Exit risk. If the relationship ends, the history goes with it. You cannot restate prior periods from data you never held.
The decisive question is not whether your TP is honest. It is whether you can independently verify the numbers you are reporting to the group. If the answer is no, this option has an expiry date.
Option 2 — Build it in-house
Building means owning the connection to each marketplace’s open platform: Alibaba’s Taobao/Tmall Open Platform for Tmall, JD’s Open Platform for JD.com, and the Douyin e-commerce open platform for Douyin Mall. Each has its own app registration, authorisation model, rate limits, versioning and documentation — largely in Chinese.
What the build actually contains
Teams scope the extraction and forget the other four fifths of the work:
- Access. App registration and ISV approval, which frequently requires a China-domiciled entity or a local partner to sponsor the application.
- Extraction. Orders, refunds, settlement statements, fee schedules, deposits, promotions, ad spend and logistics events — each a separate endpoint with separate pagination and separate freshness behaviour.
- Reconciliation. Tying settlement lines to orders and to bank receipts. This is where projects stall, and it is a finance problem wearing an engineering costume.
- Semantic mapping. Turning platform fee codes into your own GL accounts, per our chart of accounts mapping guide. The mapping is not stable; platforms add fee types without notice.
- Compliance. Moving China transaction data offshore engages the Personal Information Protection Law and the cross-border transfer regime. Read a competent summary of the PIPL before you design the pipeline, not after.
- Maintenance forever. API deprecations, festival-period volume spikes, new platforms, new fee categories. There is no finished state.
The honest cost
A credible in-house build for three platforms is a multi-quarter programme needing a data engineer, a Mandarin-capable analyst who understands marketplace settlement mechanics, and a finance owner with authority over mapping decisions. Then it needs roughly a quarter of an engineer indefinitely to keep working. Most brands can staff the build. Far fewer can staff the decade after it, and that is where China marketplace-to-ERP integrations break.
Option 3 — Buy a platform
Buying moves the connector maintenance, the fee-schedule churn and the normalisation logic to a vendor whose entire business is keeping them current. You keep the decisions that are genuinely yours: which accounts things map to, what your close calendar is, what you consider material.
What to demand before you sign
- Settlement-level granularity, not dashboards. If you cannot export the line items behind a figure, you cannot audit it.
- A named ERP path. Ask how the data lands in your system specifically — whether that is Oracle NetSuite, Oracle Fusion Cloud ERP, or Microsoft Dynamics 365 Finance.
- A GMV-to-net-revenue bridge. Any vendor that reports GMV as revenue has told you they do not understand the problem. The bridge itself is explained in our post on GMV vs. net revenue.
- Data ownership and exit. Your historical data must leave with you, in a usable format, on termination.
- Documented cross-border posture. How does the vendor handle PIPL and cross-border transfer? Vagueness here is a liability you inherit.
Unified China P&L visibility is the specific problem Digate’s platform was built to solve for global brands — settlement-level marketplace data, reconciled, mapped, and delivered into the ERP you already run.
Build vs. buy vs. TP, side by side
| Dimension | Rely on TP | Build in-house | Buy a platform |
|---|---|---|---|
| Time to trustworthy close | Immediate, unverified | 8–14 months | 4–10 weeks |
| Data granularity | Summary only | Whatever you build | Settlement-level |
| Who absorbs API changes | TP (opaque to you) | You, forever | Vendor |
| Audit defensibility | Weak | Strong if documented | Strong |
| Internal headcount needed | None | Engineering + finance | Finance owner only |
| Cost shape | Bundled in TP fees | High capex, ongoing opex | Predictable subscription |
| Main risk | Unverifiable numbers | Stalls at reconciliation | Vendor fit and lock-in |
| Best when | China <5% of revenue | China data is a strategic capability | China is material, team is not China-dedicated |
Five questions that settle the decision
Answer these honestly before you run a vendor process. They resolve most cases without one.
- Is China material to the group P&L? If a China error would be material at group level, you need data you can verify. That removes the TP-only option.
- Do we already employ engineers who can read Chinese API documentation? Not “could hire” — employ, today, with capacity. If no, building is a hiring plan, not an integration plan.
- Who owns reconciliation logic? If finance is not resourced to own fee-to-GL mapping decisions, an in-house build will produce data nobody will certify.
- What is the cost of being wrong for another four quarters? Build timelines are long. Price the delay, not just the project.
- Is China marketplace plumbing a capability we want to own in five years? If it is not on your strategic roadmap, owning it permanently is a choice you will keep paying for.
The costs every option hides
- Fee-schedule drift. Platforms introduce new fee categories continuously. Whoever owns the pipeline owns the work of classifying them, and a misclassified fee silently distorts margin.
- Festival concentration. Singles’ Day and 618 compress a quarter of annual volume into days. Pipelines that pass a quiet-month test fail under peak.
- Settlement timing. Payout dates and revenue recognition dates do not coincide. A pipeline that ignores the difference produces a plausible, wrong P&L.
- Currency translation. Reporting-currency conversion applied at the wrong layer creates variances nobody can trace back.
- Key-person risk. In-house builds concentrate in one or two people. When they leave, an undocumented pipeline becomes a liability overnight.
What a finished integration looks like
Whichever route you take, judge it against the same finish line. You are done when:
- Every China revenue figure in the group P&L traces to settlement line items you hold yourself.
- The gap between GMV and net revenue is explained by named, quantified fee categories — not a plug.
- China closes on the same calendar as every other region, without a heroic spreadsheet.
- A new platform or fee type is a configuration change, not a project.
- Your auditors can follow the derivation without asking a third party.
Frequently asked questions
Can we get Tmall and JD API access without a China entity?
Often not directly. Both open platforms expect an app owner that can satisfy local registration requirements, which in practice means a China-domiciled entity or a sponsoring partner. Brands without one typically authorise a service provider — which is a form of buying, whether or not it is called that.
Our TP says they will build us a dashboard. Is that the same as buying a platform?
No. It keeps the conflict of interest intact: the party being measured still controls the measurement, and the underlying data still does not leave their systems. A dashboard from your operator is a nicer presentation of the same unverifiable input.
How long does an in-house build really take?
Extraction for a single platform can be working in weeks. A reconciled, GL-mapped, audit-defensible pipeline across Tmall, JD and Douyin is realistically 8–14 months, and reconciliation — not extraction — consumes most of it.
Can we start with a platform and build later?
Yes, and it is usually the lowest-regret sequence — provided your contract guarantees export of historical data in a usable format. Buying first gives you a trustworthy close now and a documented specification for any later build.
What is the single most common failure mode?
Treating it as an IT project. The hard part is deciding what each platform fee means in your chart of accounts, and no engineer can settle that without a finance owner who has the authority to decide.
Where to go next
If China is material to your group P&L and you cannot currently verify the numbers you report, the TP-only option has already expired — the only live question is build or buy. Price the delay as carefully as the project, and be honest about whether marketplace plumbing is a capability you want to own for the next five years.
If you want to see what settlement-level China data looks like inside your own ERP, explore Digate’s solutions for global brands.