Intercompany Transfer Pricing in China: What ERP Must Handle

Transfer pricing is a data problem before it is a tax problem

A China entity that transacts with related parties abroad — a parent, a sister company, a shared service centre — has obligations beyond ordinary bookkeeping. Related-party transactions must be reported, their pricing should be consistent with an arm's-length standard, and the tax authority can examine them. All of that depends on one thing: being able to identify and total the related-party transactions accurately, by counterparty, by type, and by period. In practice, that is where ERP quality shows. A system that tags related parties and reports their transactions cleanly makes the annual obligation routine. A system that does not means finance reconstructs the numbers from the ledger every year, and the reconstruction is only as good as the person doing it. This guide explains what to require.

What the Chinese regime expects

The framework follows the international arm's-length principle and is administered through disclosure and documentation, rather than quoting specific thresholds here — those depend on the entity and should be confirmed with a local advisor. What matters for ERP design are the recurring obligations.

• Related-party disclosure filed alongside the annual corporate income tax return, covering the year's transactions by type and counterparty.
• Transfer pricing documentation for entities that meet the applicable conditions, typically structured in tiers (a local file, and a master file and country-by-country report for groups above size thresholds).
• Consistency between the disclosed transactions, the accounting records, and the pricing policy the group applies.
• Support for the analysis itself: comparable data, the tested party, and the method chosen.

The five things the ERP must do

Software does not replace a transfer-pricing professional, but it removes most of the manual data work that makes the annual exercise painful. Require these.

• Tag related parties distinctly, so their transactions can be extracted without manual filtering.
• Report related-party transactions by type and counterparty for the period, from stored data.
• Trace each transaction to its source document, so a disclosed figure can be evidenced.
• Reflect the group's intercompany pricing policy consistently, and flag deviations.
• Feed the statutory-to-group reconciliation, so related-party adjustments are visible in both views.

Where manual processes go wrong

When related-party transactions are tracked outside the system, three problems recur. First, completeness: a transaction between affiliates that never flowed through the standard process is missed, and an incomplete disclosure is worse than an awkward one. Second, consistency: the figure disclosed differs slightly from the ledger because the two were totalled at different times from different extracts. Third, evidence: when the authority asks how a number was derived, the trail leads to a spreadsheet rather than to transactions. Each of these is eliminated by tagging related parties in the ERP and reporting from it, which is why the transfer-pricing requirement belongs in the system design, not only in the tax advisor's engagement.

How this connects to consolidation

Related-party pricing affects both the Chinese statutory result and the consolidated group result, and the two must be reconcilable. If a China entity buys from, sells to, or shares costs with affiliates, those flows sit at the centre of the statutory-to-group bridge. A system that tracks them consistently in one place makes the bridge traceable; one that leaves them scattered makes the bridge an annual detective story. Our HQ consolidation guide describes how the bridge should be built. For the broader compliance picture, see the ERP checklist for foreign companies in China.

One honest caveat: transfer pricing is a specialist field where the rules and thresholds are entity-specific, and no ERP makes the judgment for you. What an ERP can do is ensure the data a professional needs is complete, consistent, and evidenced. That alone converts a recurring scramble into a routine, and it is the difference worth paying attention to when you evaluate systems.

The three documentation tiers

Transfer pricing documentation is usually structured in tiers, and each tier draws on the same underlying data at a different level of aggregation. Knowing which tiers apply to you — which depends on the group's size and profile, confirmed with your advisor — tells you how much data discipline you actually need.

• The local file: the entity-level analysis, covering the related-party transactions, the functions and risks, and the method applied.
• The master file: the group-level picture, describing the global business, the group's transfer-pricing policy, and where value is created.
• The country-by-country report: an aggregate, jurisdiction-by-jurisdiction view for the largest groups, drawing on consolidated data rather than entity detail.

The practical consequence for system design is that no single ERP report satisfies all three. What the ERP contributes is the base layer: accurate, complete, consistently classified related-party transactions. Everything above that is analysis, and the quality of the analysis is bounded by the quality of the base. This is why a system that reports related-party flows cleanly is valuable even though it produces none of the documentation itself.

Building a related-party register

The most useful concrete step an ERP implementation can take is to establish a related-party register — a maintained list of related entities, their relationship to the reporting entity, and the transaction types that flow between them. On its own this sounds administrative, but it is the mechanism that makes completeness achievable. When a new affiliate is created or a relationship changes, the register is updated once, and every subsequent extraction inherits the change. Without it, each year's disclosure depends on someone remembering which of the group's many entities are relevant this time, which is precisely how omissions happen.

The register also makes the review tractable. Instead of asking whether the disclosure is complete, a reviewer can compare the register against the entity list and the transaction report, and see the gaps. A register that is maintained and reconciled is worth more than a more sophisticated analysis built on an incomplete population, because an analysis of the wrong data is simply a more convincing error.

When the authority examines

The reason all of this matters is that the tax authority can examine related-party pricing, and when it does, the conversation is about evidence. The authority will ask what the transactions were, how the pricing was determined, and whether it is consistent with what unrelated parties would have agreed. A company that can produce a complete transaction population, traced to source documents, with the pricing policy applied consistently, is in a fundamentally different position from one that reconstructs the answer in the corridor outside the meeting. The ERP's contribution is to have made the first position achievable without heroics, so the specialist's time goes into analysis rather than data gathering. In that sense the transfer-pricing requirement is less about compliance software and more about whether the system can answer a straightforward question about the business with confidence.

Common documentation failures

Most transfer-pricing problems are not analytical failures; they are data failures that undermine otherwise sound analysis. Four recur often enough to be worth designing against.

• Incomplete populations: a transaction between affiliates that never entered the standard process, so the reported total is understated.
• Inconsistent classification: the same type of transaction coded differently in different periods or entities, making the trend meaningless.
• Broken traceability: a disclosed figure that cannot be tied back to source documents, so it cannot be defended if questioned.
• Stale policy: a pricing policy that was correct when set but was never updated as the business changed, so current prices are unexplained.

Each of these is a system or process issue rather than a transfer-pricing issue, and each is far cheaper to prevent than to repair. The remedy is consistent with everything above: a maintained register, a single classification scheme, automated extraction, and a review step that compares the reported population against the register before the disclosure is filed. None of that requires judgement; it requires that the data be assembled from one place rather than several.

How the data flow looks end to end

It is worth describing the flow an ERP should support, because the requirement is easier to test when it is concrete. A related-party transaction is created through the normal sales or purchase process, so it inherits the standard controls. The counterparty carries a related-party flag, set once in master data. The transaction is classified by type as it is recorded, not reclassified at reporting time. At period end, the system extracts related-party transactions by counterparty and type, reconciles the total against the register to confirm completeness, and produces the report the disclosure is built from. Each figure in that report links back to the documents behind it.

When that flow exists, the annual disclosure becomes an extraction rather than a project, and the professional's effort goes where it adds value — the analysis of whether the pricing is defensible. When the flow does not exist, every step above is manual, and the manual steps are precisely where completeness, consistency, and traceability are lost. That is the whole difference the ERP makes in this area, and it is measurable in the hours the exercise consumes each year.

What to do if you find gaps

Most China entities that run this audit discover the same two gaps: related parties are not tagged in master data, and the extraction is performed by hand each year. Both are fixable within an existing system, and neither requires a new platform. Tagging related parties is a master-data exercise that takes a few days and pays back every subsequent period. Building the extraction as a saved report converts an annual scramble into a click, and it also creates the register reconciliation that catches omissions before the disclosure is filed.

The larger question — whether the system can trace a disclosed figure back to its source documents — is worth testing explicitly, because it is the one that matters if the authority asks a question. Pick a related-party transaction from last year, and ask the finance team to produce the documents behind the reported number. If that takes minutes, the controls are adequate. If it takes a day, the disclosure exists without the evidence to support it, and that is the gap worth closing before it is tested rather than after. None of this is a reason to change systems; it is a reason to use the one you have more deliberately.