The two parent GLs Australian groups actually run
In our work with Australian-headed groups, the parent GL is almost always one of two:
- Xero — common in mid-market private groups, particularly those that grew from a single Australian operating entity and added overseas subsidiaries later.
- NetSuite — common in groups that have outgrown Xero, that operate in multiple regions, or that need OneWorld-style multi-subsidiary consolidation.
Both are capable, mature systems. Neither is designed to absorb a Mainland China entity directly from Kingdee or Yonyou (UFIDA). The work happens in the layer between source and parent.
What "feeding the data in" actually requires
A China subsidiary feed is not a copy of the local trial balance. It has to deliver four things to the parent GL:
- A balanced trial balance at the agreed group cut date, in the parent's chart of accounts and reporting currency.
- Period movement detail at the granularity the parent's audit and management reporting require.
- Intercompany balances tagged with counterparty, currency, and source.
- The translation / adjustment entries that turn the PRC view into the group view, posted as separate journals rather than baked into the source data.
The mapping and reporting structure has to deliver all four every cycle, in the same shape, with the same controls.
If you are unsure how this subsidiary-to-parent reporting output 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.
Xero-specific design considerations
Xero is structured around a single-entity ledger per organisation, with multi-entity consolidation handled either through Xero's group reporting features (where available), through reporting tools (Fathom, Spotlight, Syft), or through a separate consolidation layer.
Practical implications for a Xero-based parent receiving a China feed:
- Use a dedicated tracking category for the China subsidiary at the parent level rather than trying to mirror the Mainland chart inside Xero. Xero's chart works best as a group chart; the source detail belongs in the staging layer upstream.
- Avoid posting a multi-line journal entry per source transaction. The right pattern is a summarised period journal with a reconciliation pack supporting it.
- Run intercompany as a separate ledger pattern — a clearing account at the parent that nets to zero after elimination, with the supporting subledger maintained outside Xero.
- FX revaluation should be controlled, not automatic. Xero's currency handling is sufficient for many use cases, but for material intercompany loans you want the revaluation policy documented and the journal posted as a named entry, not as an auto-generated adjustment.
NetSuite-specific design considerations
NetSuite OneWorld supports multi-subsidiary consolidation natively, with elimination entities, intercompany frameworks, and multi-currency revaluation. That capability is real, and it removes some of the burden — but it doesn't remove the need for the staging layer between Kingdee / Yonyou and NetSuite.
Practical implications for a NetSuite-based parent receiving a China feed:
- Keep the China subsidiary as a posting entity in NetSuite, but use a controlled import pattern. Direct integrations between Kingdee / Yonyou and NetSuite exist, but they tend to either replicate too much detail or strip too much metadata. A staged import with reviewed journals is usually more durable.
- Use NetSuite's elimination subsidiary for cross-border eliminations, but maintain the intercompany matching outside NetSuite at source. NetSuite eliminations work cleanly when the inputs are clean; they don't fix bad inputs.
- Treat translation adjustments as standing journals rather than letting the system's auto-translation absorb them silently. Auditors prefer named entries with policy references.
- Use saved searches and reports as control artefacts. A saved search that produces the China entity's group-view TB at a cut date, repeatable cycle to cycle, is exactly the artefact an auditor wants to rely on.
What sits between source and parent
Whether the parent is Xero or NetSuite, the layer between source ERP and parent GL carries the real work:
- A canonical export contract from each PRC entity (see the Kingdee / UFIDA mapping note for detail)
- A staging layer with chart mapping, currency normalisation, and adjustment journals
- A reconciliation pack that travels with each release
- Version control on mapping tables, policies, and adjustment templates
When this layer exists and is owned, the parent GL becomes the place where the consolidated view lives, not the place where the China entity is reconstructed every period.
Build the layer once, run it forever
The most expensive pattern we see is groups that rebuild the China-to-parent feed every cycle. The cheapest pattern, over a five-year horizon, is groups that invest once in a documented bridge — contract, staging, mapping, journals, reconciliation — and then maintain it.
The technology choice (custom database, lightweight ETL, dedicated consolidation platform) matters less than the discipline of treating the bridge as architecture rather than as a recurring task.