Reporting an Overseas Subsidiary Back to Chinese HQ

The short answer

An overseas subsidiary reporting to a Chinese parent has to produce three things: its local statutory result, a reporting package in the parent's format, and an explanation of the difference between them. Most systems and most projects do the first well and treat the other two as administrative work. That is the wrong allocation of effort, because the differences are where the risk and the recurring cost actually live.

The reporting package is the interface between two accounting worlds. If it is designed as a designed artefact — with a defined structure, a defined mapping, and a defined owner — then the monthly close is routine. If it is assembled afresh each period from whatever the local team can produce, then its quality varies with staffing, and the variation is invisible until an audit or a consolidation review exposes it.

• Small overseas entity: a compact package with a stored mapping is sufficient and should be owned locally.
• Material overseas entity: the package should be produced from the ERP rather than assembled in spreadsheets.
• Several overseas entities: standardise the package so the group consolidates comparable parts.
• Whatever the size, the statutory-to-group bridge should be a report with an owner, not a reconciliation exercise.

What the package actually has to contain

Reporting packages fail most often because they were defined by the parent for the parent's convenience and never interrogated from the subsidiary's side. A well-designed package asks the overseas entity for information it can actually produce from its own books, in a structure that maps cleanly to the group's needs.

• Statutory financial statements, in the local framework and language, as filed or as prepared for filing.
• The reporting package: balance sheet, income statement, and the schedules the group consolidates from.
• The statutory-to-group bridge, explaining each material difference between the two results.
• Intercompany balances with each group counterparty, agreed with the counterparty before submission.
• Currency translation detail: closing and average rates used, and the resulting translation differences.
• Supporting schedules for items the group treats specially — inventory provisions, revenue recognition, leases, or provisions.

The intercompany balance item deserves emphasis because it is the most frequent cause of a failed close. Two entities that each report a different intercompany balance create a difference that must be resolved before consolidation, and resolving it after submission is far more expensive than agreeing it beforehand.

The statutory-to-group bridge

This is the single most valuable artefact in cross-border group reporting. It takes the subsidiary's local statutory result and explains, line by line, how it becomes the entity's contribution to the group. Differences arise for legitimate reasons: different recognition criteria, different depreciation conventions, different treatment of provisions, different presentation of currency effects, and in some jurisdictions inflation accounting.

• A defined structure, so every entity reports its differences in the same categories.
• Produced from stored data, so it is derived rather than reconstructed.
• Reviewed every period, with every change in a difference investigated rather than accepted.
• Owned by a named person in the group finance function, with change control.
• Versioned, so the effect of a change in accounting policy or in local rules can be tracked.

When the bridge exists as a standard report, a difference that appears this month and not last month is immediately visible, and its cause can be found in hours. When it does not, differences accumulate quietly and surface during an audit as questions nobody can answer.

The calendar is part of the design

The reporting calendar has to reconcile the group's deadline with the subsidiary's statutory obligations, local public holidays, and audit timetable. Assuming the subsidiary can close on the group's schedule is the most common calendar error, and it is not a matter of effort — sometimes the subsidiary is legally unable to finalise its books before a date the group has already assumed.

The discipline that works is to run the calendar backwards from the group deadline and identify every dependency: intercompany agreement, rate capture, mapping updates, bridge review, and submission. Each dependency gets a date and an owner. Groups that do this find their constraint is usually the intercompany step, because it requires two entities in different time zones to agree on a number.

Language and format friction

There is a subtler problem that costs more time than it should: the package arrives in a local language and a local format, and someone at the parent has to interpret it. Every interpretation is a potential misreading, and each misreading is discovered late.

The efficient answer is to fix the format centrally — a defined template with defined line definitions and a defined language for the group package — and to require submissions in that format rather than accepting local reports with a translation attached. This costs the subsidiary some setup effort once and saves the parent a recurring interpretation burden. It also makes the package machine-readable, which matters if the group later automates consolidation.

What the ERP has to contribute to the package

A reporting package is produced from data, which means the system determines whether producing it is a routine or a project. The minimum contribution is the ability to produce a trial balance in the group's chart of accounts from the entity's own ledger, without re-keying — which requires the mapping between the two charts to be stored as configuration rather than held in someone's head. If that mapping is stored and versioned, the package is a report. If it is not, the package is a reconciliation exercise performed under deadline.

The second contribution is the audit trail. For each figure in the package, someone should be able to trace back to the transaction and the document that produced it, without leaving the system. That capability is what converts a query from headquarters into a five-minute lookup rather than an afternoon of reconstruction, and it is also what makes the package defensible when an auditor asks how a particular balance was derived.

The third contribution is intercompany support. If related-party transactions are tagged at the point of entry and balances are tracked by counterparty, agreeing the intercompany position with each counterparty becomes a comparison rather than an investigation. Systems that record intercompany activity as ordinary trading with an ordinary customer make that agreement unnecessarily hard, and the difficulty compounds as the number of entities grows. The related tax dimension is covered in our guide to intercompany transfer pricing in China.

The fourth contribution is currency detail. Translation differences are among the hardest items to explain after the fact, and they are straightforward to explain if the system stores the rates used at each level and shows which balances were translated at closing rates and which at average rates. Where that detail is summarised rather than supported, a question about a translation difference cannot be answered without going back to source records.

• Produce a group-chart trial balance directly from the entity ledger, with no re-keying.
• Store the local-to-group mapping as versioned configuration with an owner.
• Tag related-party transactions at entry and track balances by counterparty entity.
• Hold exchange rates at the level needed to support the translation detail in the package.
• Provide drill-down from any reported figure to the transactions behind it.
• Generate the statutory-to-group bridge as a standard report rather than a manual reconciliation.

None of these is an advanced requirement, and all of them are commonly absent — not because platforms cannot do them, but because nobody specified them when the entity was implemented. That is the pattern worth noticing: the reporting problem is almost always created during the implementation of the entity, long before anyone runs a consolidation.

There is a reason this matters more as a group grows. With one overseas entity, an informal package can be sustained by familiarity — the parent knows the entity, the numbers are small relative to the group, and the person assembling the package understands both sides. With four, the familiarity disappears, the volumes matter, and the same informal approach produces a month in which the group cannot close on time and nobody can say precisely why.

Where overseas reporting breaks

• The package structure differs by entity, so the group cannot consolidate comparable parts.
• Intercompany balances are submitted before being agreed with the counterparty entity.
• The statutory-to-group bridge is reconstructed each period by whoever is available.
• Currency translation detail is summarised rather than supported, so differences cannot be explained.
• Local statutory statements are sent without a group-format package, leaving the parent to interpret.
• The calendar assumes simultaneous closes without checking each entity's statutory constraints.

Each of these is a governance issue rather than a systems limitation, and each becomes considerably more expensive to fix once several entities are involved, because the fix requires changing established local habits.

Verdict

It is worth being explicit about what good looks like, because the absence of problems is not the same as a well-designed process. A well-designed reporting cycle has a package that arrives on a known date in a known format; intercompany balances that are agreed before submission rather than after; a bridge that explains the period's differences without anyone having to investigate a surprise; and a review step in which the group finance function genuinely reads the numbers rather than merely receiving them. Where all four are true, the close is unremarkable — and unremarkable is the objective.

A practical way to test whether a group's reporting process is genuinely designed rather than merely functioning is to remove a person from it. Take the individual who currently assembles the overseas package or reviews the bridge, and ask what would happen if they were unavailable for one close. If the answer is that the period would be reported late or with unexplained differences, the process depends on that person rather than on the system and the standard. That test is uncomfortable, it takes five minutes, and it predicts the problem earlier than any audit will.

The failure mode is more common than the success mode because the failure mode is survivable. A package that arrives late but does arrive, a bridge that is reconstructed but does get reconstructed, a difference that is explained eventually — each of these is tolerable in any single period and corrosive across many, because the organisation never builds the institutional memory that would make the next period easier. Groups that fix this usually do so by deciding that the bridge is a deliverable with an owner rather than an output with a deadline, and that distinction is the whole of the change.

Reporting an overseas subsidiary is where the accounting reality of international expansion becomes concrete. The groups that find it routine are the ones that standardised the package, made the statutory-to-group bridge a report rather than a project, agreed intercompany balances before submission, and designed a calendar around each entity's real constraints. For the entity-level consolidation view, see our guide to HQ consolidation from a China subsidiary; for the multi-entity version, see multi-entity consolidation for Chinese groups overseas.