Multi-Currency Per-Entity Books: The Honest Foundation for Intercompany and Transfer Pricing

Running a group that books transactions in JPY, INR, and USD teaches you one truth fast. The intercompany mess is never really about the intercompany transaction itself. It is about the data underneath it. When your Japanese entity, your Indian entity, and your dollar-denominated trading partner each keep their numbers in a different place, with different currencies, different tax rules, and different period calendars, the group close becomes a month of spreadsheets and reconciliations.

This guide is for the group CFO and treasury lead who are tired of that cycle. We will walk through what actually changes when every legal entity keeps clean, currency-correct books in one ERP, and why that is the real prerequisite for intercompany reconciliation and transfer pricing. We will be honest about what automation can and cannot do, because overstating it is how finance teams get burned at audit.

The Problem: FX Chaos Across JPY, INR, and USD

Picture a typical quarter close in a group that operates across Japan and India, with a dollar-denominated trading company in the mix. The Japan parent invoices in JPY and files consumption tax at 10 percent. The India subsidiary bills in INR, charges GST, and once aggregate turnover crosses the 5 crore threshold must also meet the e-invoicing requirement by generating IRNs and submitting e-invoices to the Invoice Registration Portal as a separate regulatory step outside the core books. A dollar invoice lands in between, and nobody agrees on the rate to use.

Three painful patterns emerge.

First, currency ambiguity. The same invoice exists in three spreadsheets, each converted at a different rate. Which number is the truth? No one is sure. Second, period mismatch. The Japan entity closes on one calendar, the India entity on another, and the group consolidation lands somewhere in the middle with gaps. Third, intercompany fog. Internal charges between entities sit in side ledgers, reconciled by hand, with FX gains and losses that nobody spotted until the auditor asked.

None of this is a tooling accident. It is the predictable result of each entity running its own books in isolation. Fix the foundation, and the symptoms get quieter. Leave the foundation broken, and no amount of reconciliation effort will close the gap.

What Changes: Multi-Currency Per-Entity Books

The shift is structural. Instead of one shared bucket of transactions tagged with a currency, each legal entity keeps its own complete set of books, denominated in its own currency, inside a single ERP.

In practice, this is grounded in how the system models entities and money. Each legal entity has a dedicated company master record. That record carries the legal name, the representative, the address, the corporate number for Japan, the tax registration number, the fiscal year end month, and crucially a country code that drives the currency. The country master maps each country to its ISO currency code and symbol. A Japan entity maps to JPY with the yen symbol. An India entity maps to INR with the rupee symbol. A dollar entity maps to USD.

From that one mapping, the rest of the books stay currency-correct. Product prices, vendor purchase prices, customer revenue targets, journal entry lines, invoices, bills, and payments all record amounts in the entity currency, stored as precise decimals. A double-entry journal entry line holds a debit and a credit that must balance to the cent within a tight tolerance, and every line posts to one chart of account owned by that entity. Bank accounts are country-scoped too, so a Japan account validates Zengin bank and branch codes plus katakana names, while an India account validates the IFSC, the MICR, and the RBI sector category.

The payoff is simple but powerful. You stop arguing about which currency a number is in, because the entity that owns the number defines the currency. The group close stops being a translation exercise and becomes a roll-up of books that were already correct at the source.

What This Is, and What It Is Not

Honesty matters here. Native multi-currency per-entity books mean each entity records and reports in its own currency cleanly. They do not mean the ERP automatically eliminates intercompany balances, computes transfer prices, or files your transfer pricing documentation. Those remain accountant-owned processes.

What the clean per-entity data does is make those processes possible without the usual agony. When every entity books its side of an internal transaction in its own currency, with a real journal entry and a real partner record, reconciliation becomes a matching exercise rather than a forensic dig. When revenue and cost sit in the right entity in the right currency, your transfer pricing analyst has a defensible starting point for the arm's length analysis. The ERP gives you the data spine. Your tax and accounting teams still own the judgment.

A Real-World Scenario: A Group Across Japan and India

Consider a group with a Japan parent, an India operating subsidiary, and a dollar-denominated trading entity that handles regional procurement. No single company name matters here. The pattern is what counts.

The Japan parent sells consulting services to external clients and bills 12,000,000 yen in a month. Consumption tax at 10 percent adds 1,200,000 yen. The invoice, the journal entry, and the receivable all live in the Japan entity books in JPY. Nothing gets converted at entry time, because the entity currency is JPY.

The India subsidiary manufactures components and invoices 85,000,000 rupees to customers in the same month, plus 18 percent GST split into CGST, SGST, or IGST depending on the place of supply. Because aggregate turnover is well above 5 crore, the subsidiary must also comply with e-invoicing, generating IRNs and submitting e-invoices to the Invoice Registration Portal. That compliance step runs outside the core books, but it draws on the connected master data and tax-consistent line detail those books already hold: GSTIN, registration numbers, HSN or SAC codes, and the line-level tax split. Those invoices post to the India entity books in INR.

The trading entity procures raw materials invoiced in USD, say 480,000 dollars for the month, and records the payable in its own books. Internally, the trading entity charges the India subsidiary a management fee of 15,000,000 rupees for shared services, and the India subsidiary charges the Japan parent a royalty of 8,500,000 yen for licensed technology.

Here is where per-entity books earn their keep. Each internal charge is a real journal entry in the originating entity, in that entity currency, posted against the partner record of the receiving entity. When the group closes, the intercompany balances can be matched entity by entity, currency by currency, instead of reconstructed from email threads. The transfer pricing analyst takes those same clean revenue and cost figures and builds the local file and master file on numbers that match the general ledger.

This is the discipline that auditors in both Japan and India want to see. Japan has required transfer pricing documentation since the 2016 tax reform, and new documentation rules for intercompany IP and service transactions take effect in April 2026. India runs its own robust transfer pricing regime under the arm's length principle. In both countries, the question is not whether you have documentation. It is whether your documentation ties back to books that are internally consistent. Per-entity books make that tie-back straightforward.

Why This Matters for JPY, INR, and USD Groups

Three reasons this matters more than finance teams sometimes admit.

First, FX risk becomes visible. When each entity books in its own currency, you can see exactly where transaction exposure sits. The yen receivable against a rupee payable, or the dollar payable against a yen receivable, shows up as a real position rather than a buried spreadsheet number. That visibility is the prerequisite for any hedging decision, and it is also what protects you from misstated FX gains and losses that auditors love to challenge.

Second, GST and consumption tax stay clean in each jurisdiction. The India entity applies GST correctly on its INR invoices and can produce the data needed for e-invoicing and returns. The Japan entity applies the 10 percent consumption tax correctly on its JPY invoices. Because the books never blurred the currency or the entity, the tax numbers are traceable from invoice to journal entry to return.

Third, the group close gets shorter. You are no longer translating and reconciling in a panic. You are rolling up books that were already correct, converting at agreed rates for reporting, and presenting consolidated results that tie to the legal entity ledgers. That is the difference between a close that takes weeks and one that takes days.

A Note on Honest Boundaries

Be careful with vendor claims in this space. Some ERP marketing promises fully automated intercompany elimination and transfer pricing computation out of the box. In reality, transfer pricing is a judgment-laden exercise that depends on functions, assets, and risks analysis, comparable benchmarking, and method selection. No ERP should be filing that for you. What you want is an ERP that gives your analysts clean, currency-correct, entity-specific data so they can do the judgment work efficiently and defensibly. That is the honest division of labor.

Is This Right for Your Business?

This approach fits if any of these describe your group.

You operate two or more legal entities across Japan, India, or other currency zones, and you are tired of reconciling numbers that should already agree. You need to produce transfer pricing documentation that ties to your general ledger without a forensic project each year. You are scaling into a new country and want the new entity to keep its own clean books in its own currency from day one. You want GST in India and consumption tax in Japan to stay correct at the source, not patched at period end.

If your group is a single entity in a single currency, this is more structure than you need today. But if growth, acquisition, or cross-border trade is on the horizon, the per-entity foundation is worth laying now.

Frequently Asked Questions

Does this ERP automatically compute transfer prices or eliminate intercompany balances?

No, and it should not claim to. The ERP keeps clean per-entity books with native JPY, INR, and USD currency support, so every internal transaction posts as a real journal entry in the right entity and the right currency. Your accountants and transfer pricing analysts then match, eliminate, and document using data that already ties to the general ledger. Transfer pricing remains an arm's length judgment exercise owned by your tax team, supported by defensible source data.

How are exchange rates handled for group reporting?

Each entity records transactions in its own entity currency at the time of entry, with precise decimal amounts. For group reporting, your team applies agreed exchange rates to translate entity books into the reporting currency. The ERP does not impose a single hardcoded rate, which means you retain control over the rates used for consolidation, hedge accounting, and disclosure, and you can document those choices for audit.

Can one entity handle GST and e-invoicing while the other handles consumption tax?

Yes. Because each entity keeps its own books in its own currency, the entity applying GST can include the CGST, SGST, and IGST split on INR invoices and supports the e-invoicing workflow relevant above the 5 crore turnover threshold. The other entity applies the 10 percent consumption tax on JPY invoices and holds the corporate number and tax registration details on its company record. Tax stays correct by entity, not bolted on at the end.

Key Takeaway

Multi-currency intercompany success is not bought with a magic automation button. It is built on per-entity books that record every transaction in the right currency, in the right entity, with tax applied at the source. Give your finance and tax teams that clean data spine, and reconciliation, transfer pricing documentation, and the group close all become tractable. Kikan System is built around exactly that foundation, with a legal entity company record, native JPY, INR, and USD currency support, country-scoped bank validation, double-entry journal entries, and period closing per entity.

Ready to Clean Up Your Group Close?

If your group is reconciling JPY, INR, and USD in spreadsheets every month, the fix starts with the right data foundation. Kikan System gives each legal entity its own currency-correct books in one cloud ERP, so intercompany matching and transfer pricing documentation stand on numbers that tie to the ledger. Start on the free plan, which supports up to 2 users with no credit card required, and map your first entity at /en#get-started.