The two ERPs most Australian groups will meet
Mainland operating subsidiaries that were established or grown locally almost always run on either Kingdee (金蝶) or Yonyou / UFIDA (用友). Both vendors offer multiple product tiers — from desktop SMB editions through to mid-market and large-enterprise cloud platforms — and both are deeply optimised for PRC tax, fapiao, and statutory reporting requirements.
That local optimisation is exactly what makes the mapping to a group GL non-trivial. The systems are not "lesser ERPs"; they are differently shaped. Direct exports work for compliance, not for consolidation.
Why a raw export is not a reconciliation schedule
A typical request at month-end goes like this: "Export the trial balance from Kingdee, send it through to the Sydney team, they'll put it into NetSuite." The output looks like a spreadsheet. It behaves like a hand grenade.
The recurring problems:
- Account semantics differ. A Kingdee account labelled "应交税费 — 应交增值税 (进项税额)" maps to a specific group line, but the routing depends on whether the entity is a general VAT taxpayer, the period treatment of input VAT, and whether the parent treats VAT receivable as a working capital asset or nets it.
- Dimensional metadata is lost. Local ERPs carry rich auxiliary accounting (辅助核算) — department, project, customer, supplier, currency — that doesn't survive a flat TB export.
- Cut-off discipline is implicit. Mainland practice often allows back-dated postings within an open period to align to the fapiao cycle. Without an explicit cut, the file you receive on day three is not the file the parent receives on day five.
- Currency presentation is mixed. Original currency, functional currency (CNY for most PRC entities), and any group reporting currency need to be carried through together. A single-column export collapses them.
- Statutory adjustments are baked in. Tax-driven entries that the local team posts to align with PRC ASBE may need to be reversed or re-presented for group AASB / IFRS reporting.
A mapping has to handle all five before the file lands in the parent GL.
If you are unsure how this Kingdee or UFIDA-to-group mapping gap is currently impacting your group close, you can run a 2-minute diagnostic via our Close Clash Calculator to see where the evidence path is breaking down.
What a working mapping looks like
The architecture below is what we build for groups serious about repeatability. It is deliberately decoupled from any one ERP product, because the same patterns apply whether the source is Kingdee K/3, Kingdee Cloud (云), Yonyou U8, or Yonyou YonSuite.
1. A canonical export contract
Define a single, versioned export contract from each PRC entity. Not "what Kingdee gives you", but what the group requires: TB at the cut date, journal detail for the period, intercompany subledger, dimensional metadata, currency triplet (original / functional / group), and supporting tax positions.
The contract is documented, owned, and version-controlled. When the local team upgrades Kingdee or Yonyou, the contract doesn't move.
2. A staging layer between source and parent GL
Raw exports never go directly into the parent GL. They land in a staging layer — a database, a controlled spreadsheet pack, or a lightweight data warehouse — where they are validated and translated.
The staging layer carries out:
- Schema validation against the export contract
- Chart of accounts mapping with version control
- Currency normalisation
- Group adjustment journals applied as separate, traceable entries
- Reconciliation back to the source TB before release
3. Group adjustments as journals, not transformations
The most common mistake in homemade mappings is to transform PRC numbers on the way through — re-classifying lines, adjusting balances, or netting positions in the same step as the import.
That destroys audit traceability. The right pattern is: import the source numbers as they are, then post group adjustments as separate, dated, owned journals in the staging layer. The auditor can then see the source position, the adjustments, and the resulting group view as three distinct artefacts.
4. Reconciliation outputs that travel with the data
Every release from the staging layer to the parent GL includes:
- Source TB hash / signature
- Mapping table version
- Adjustment journal list with policy references
- Group TB after adjustments
- Variance report against prior period
These outputs are what allow a parent's external auditor to rely on the mapping as a process control rather than treating each cycle as a fresh investigation.
Build vs buy vs coordinate
There is no single right answer on tooling. Larger groups invest in dedicated consolidation platforms (OneStream, CCH Tagetik, Workiva, BlackLine for reconciliations) that interface with Kingdee and Yonyou. Mid-market groups often run the staging layer in a controlled spreadsheet pack with a database layer underneath.
What matters more than the tool choice is whether the four elements above — contract, staging, journal-based adjustments, reconciliation outputs — are present, owned, and refreshed each cycle. The tool can be replaced; the discipline cannot be.