One ERP for Japan HQ + India Subsidiary: The Cross-Border Playbook for 2026

Your finance team in Osaka closes the books in Japanese yen. Your plant team in Pune closes in rupees. Each runs its own books, its own chart of accounts, its own tax logic. And every month, someone stitches it all back together in a spreadsheet at midnight. If that sounds familiar, you are living the most expensive workflow in cross-border operations. The good news is that a single ERP can hold both companies, keep their data isolated, and speak both languages at once. This playbook is for the group CFO and IT head who want to stop reconciling two systems and start running one.

The Problem: Two Systems, Reconciliation Hell, and Data Silos

Most Japan-headquartered groups with an India presence did not plan for two systems. It happened by accident. The Tokyo office bought accounting software built for Japanese consumption tax. The India subsidiary, set up a few years later, needed GST compliance and rupee reporting from day one, so it picked a different tool built for the Indian market.

What looked like a pragmatic choice at the time has become a structural tax on your finance function. The two systems never agree. Accounts receivable in Japan shows one balance for the group. Accounts payable in India shows another. Currency conversions drift because each side uses a different rate on a different day. Intercompany transactions, the very lifeblood of a parent and its subsidiary, live in two places that cannot see each other.

The result is reconciliation hell. Month-end close stretches into week two. Your group controller exports trial balances from both systems, maps them to a common chart, converts currencies, and hand-checks every intercompany entry. A single typo in an account code means starting over. And when the auditors arrive, you cannot show them one clean thread from a Pune invoice back to the consolidated group balance sheet.

None of this is a people problem. Your team is capable. It is an architecture problem. Two disconnected systems cannot produce one source of truth, no matter how many late nights you throw at it.

What Changes: One System, Isolated Companies, Bilingual, Dual Tax Config

The fix is not another integration project bolted onto your existing tools. The fix is one ERP built to hold multiple companies while keeping their data fully isolated. Think of it as one system, many entities. Each company operates inside its own bounded space. The Osaka headquarters and the Pune plant share a platform, not a ledger. Your group CFO gets consolidated visibility. Your local controllers get clean, uninterrupted books.

This matters for three concrete reasons grounded in how a modern cloud ERP is actually built.

First, data isolation is real isolation. Each company in the system maps to a dedicated data store whose records are fully separated from every other company. The India entity cannot see Japan payroll. Japan headquarters cannot accidentally post to India tax accounts. You get consolidation without contamination. This is the same isolation pattern that lets one platform serve many unrelated businesses safely, and it works just as well for the two entities inside your group.

Second, the interface speaks both languages. A bilingual ERP is not a translation afterthought. The platform ships with English as the fallback language and full Japanese locale support, so your Osaka finance lead works in Japanese while your Pune operations lead works in English on the same system. Reports, field labels, and exports respect the language each user expects. No more screenshots of an English-only screen forwarded with a Japanese explanation typed underneath.

Third, tax is configurable per company, not hard-coded. Japan consumption tax and India GST are completely different regimes, and your ERP must treat them as such. A proper tax settings layer lets you define a tax name, a rate anywhere from zero to one hundred percent, and separate accounts for sales tax and purchase tax. Sales tax posts to a liability account. Purchase tax posts to an asset account. The system validates this at write time, so a misconfigured tax line is rejected before it ever reaches your books. Osaka configures consumption tax at the Japanese rate. Pune configures GST at the applicable Indian rates. Same screen, same structure, two correct outcomes.

A Real-World Scenario: Osaka Headquarters and a Pune Plant

Consider a mid-sized Japanese manufacturer. The headquarters in Osaka runs the core business, handling group treasury, consolidated reporting, and the Japan supply chain. Two years ago, the group opened a components plant outside Pune to serve Indian automotive customers and shorten lead times into South Asia.

Today this group runs two systems. Osaka reports in yen under Japan consumption tax and follows the qualified invoice rules. The Pune entity reports in rupees under GST, files monthly returns, and manages input tax credit across hundreds of vendor invoices. Intercompany shipments of components flow from Osaka to Pune every week, and every one of those shipments must be priced, taxed, invoiced, and reconciled across two ledgers that do not talk to each other.

In a single ERP, the picture changes. Osaka is company one. Pune is company two. Both live in one platform with isolated data. The Osaka finance team works in Japanese; the Pune team works in English. Osaka carries a consumption tax setting at the standard ten percent rate, with a separate reduced rate for qualifying transactions, each linked to the correct sales and purchase tax accounts. Pune carries GST settings structured the same way, output tax to a liability account and input tax to an asset account, at the rates that apply to that entity.

When components ship from Osaka to Pune, the transaction is captured once. The Japan side posts its output. The India side books its input. Currency is handled at the company level, yen for Osaka and rupees for Pune, so neither team manually converts. At month-end, the group controller pulls consolidated figures from one platform instead of two exports and a spreadsheet. What used to take ten days now takes a fraction of that, and every figure traces back to a source document the auditors can follow.

Why This Matters: Consumption Tax, GST, Consolidation, and Audit

The stakes here are regulatory, not just operational. Japan and India both enforce tax regimes that punish sloppy records, and they do it in very different ways.

Japan introduced the qualified invoice system to tighten how input tax credits are claimed. Only registered qualified invoice issuers can hand buyers a document that supports a credit, and buyers now demand that registration number on every invoice. Your ERP must let you configure the consumption tax rates and the linked accounts correctly, or your input credit workflow breaks. Approximately 3.7 million businesses registered as qualified invoice issuers around the system launch, and the compliance expectation has only tightened since. India runs GST, a destination-based tax with monthly returns, input tax credit reconciliation, and strict invoicing rules. The GST taxpayer base has grown past 15 million active registrations. For a Japan-headquartered group, the India entity must file accurately and on time or face penalties and lost credits.

One ERP handles both without compromise because the tax layer is configurable per company. You are not forcing Japanese consumption tax logic onto an Indian entity, and you are not bending GST around a Japanese chart of accounts. Each company gets the regime it actually operates under.

Consolidation becomes real instead of theatrical. A group that runs one system can produce consolidated reporting that actually ties out, because the underlying data was never duplicated or manually bridged. Intercompany entries are consistent by construction. Currency sits at the company level. And audit becomes a conversation, not a fire drill. When the Japan auditor asks to see a consumption tax account, it is there. When the India auditor asks to trace an input tax credit, it is there. One platform, two compliant entities.

Is This Right for Your Business?

This approach fits a specific shape of organization. You are likely a Japan-headquartered group, anywhere from a few dozen to a few hundred staff, with one or more entities in India. Manufacturing is the most common case, given that roughly half of the approximately 1,500 Japanese companies operating in India are in manufacturing, but the same logic applies to trading houses, engineering services, and distribution groups.

You feel the pain most if month-end close routinely spills past the first week, if your group controller spends days on consolidation spreadsheets, or if your auditors have ever flagged an intercompany mismatch. You also feel it if your Japan team and your India team are effectively running two finance functions with two tool sets and two sets of tribal knowledge.

If you are a single-country operator with no cross-border entity, you do not need this playbook. A single-company setup will serve you well. But the moment you have a headquarters in one country and a real operating entity in another, the cost of two disconnected systems climbs every quarter.

Frequently Asked Questions

Can one ERP really keep each entity's data separate while still consolidating?

Yes. Each company maps to its own isolated data store, so records are fully separated at the storage level. Consolidation reads across companies without merging their books. You get group visibility without losing entity-level integrity.

How does the system handle consumption tax and GST at the same time?

Tax settings are configurable per company. You define a tax name, a rate between zero and one hundred percent, and separate accounts for sales tax and purchase tax. Osaka can run a ten percent consumption tax configuration while Pune runs GST configurations, each linked to the correct liability and asset accounts.

Do my parent and subsidiary teams have to use the same language?

No. The platform ships with English as the fallback and full Japanese locale support, so each user works in their preferred language. Your Osaka team operates in Japanese and your Pune team operates in English on the same system.

Key Takeaway

Cross-border growth does not have to mean disconnected books. One ERP, holding your Japan headquarters and India subsidiary as isolated companies, with a bilingual interface and per-company tax configuration, turns reconciliation hell into a single source of truth. The monthly fire drill becomes a routine close.

Get Started with Kikan System

Kikan System is built for exactly this shape of group. Multiple companies with isolated data, a bilingual interface spanning English and Japanese, and a tax settings layer that lets each entity run its own consumption tax or GST configuration, all validated against your chart of accounts. If your Japan headquarters and India subsidiary are still living in two systems, start with the free plan, which supports up to 2 users and requires no credit card. Visit /#get-started to begin.