How a Multi-Site Japanese Firm Unified Its Operations on One Core Business System

It is the last Friday of March, and the group controller for a precision parts maker in Higashi-Osaka is on her fourth spreadsheet. The parent factory runs one ledger. The sales subsidiary in Nagoya keeps another. A small machining outpost in Kani, Gifu, tracks inventory on paper that someone faxes in each week. She needs one consolidated number for group revenue before the board call at 5pm. She gets it, eventually, by 5:42pm.

That scene is ordinary. Across Japan, small and mid-sized enterprises account for 99.7% of all businesses and roughly 3.36 million companies, employing about 70% of the workforce (World Economic Forum, 2025). A large share of those companies are not single entities. They are groups: a factory plus a trading arm, a headquarters plus a regional branch, a parent plus the second-generation subsidiary set up for a new product line. Each entity carries its own books, its own invoices, and its own inventory count. When leadership asks for the group picture, someone rebuilds it by hand.

This is the story of how one such firm stopped rebuilding the group picture by hand, and what changed when they consolidated day-to-day operations onto a single core business system. It is also an honest look at what consolidation does and does not solve, because any vendor who tells you one tool fixes every group problem is selling you a fantasy.

Why multi-entity firms hit a wall

The pressure on Japanese group companies has stacked up over the last few years. The qualified invoice system, effective October 1, 2023, requires each legal entity in a group to register separately as a qualified invoice issuer with the National Tax Agency. A parent's registration does not cover its subsidiary. So a two-entity group now maintains two registration numbers, two sets of output and input consumption-tax accounts, and two reconciliation routines at month-end.

Layer on the 2025 legacy cliff. A generation of on-premise systems installed in the late 1990s and early 2000s is reaching end-of-life, and the vendors behind them are winding down support. The Japan cloud ERP market is growing at roughly 20% compound annual growth (20.1% CAGR, DataM Intelligence via erp.today, 2025) through 2032 as companies replace those aging systems. Group firms face this cliff twice, once per entity, unless they consolidate.

Then there is succession. The Small and Medium Enterprise Agency estimates that around 1.27 million Japanese companies have no decided successor, with potential lost output on the order of 22 trillion yen if those businesses close (SME Agency, 2025). When a founder hands a group to a successor, the inherited complexity is often the barrier. Three ledgers. Two inventory systems. A pile of approval rules that live in someone's head. Unification is not just an IT project. It is succession readiness.

The firm in this case

Consider a precision parts manufacturer based in Higashi-Osaka. About seventy staff across three operating entities. The parent runs machining and assembly, roughly 48 people. A Nagoya subsidiary handles sales and quotations, about 14 people. A small Kani workshop, about 8 people, does specialty finishing work for a key automotive customer.

Before unification, each entity ran its own tools. The parent kept a desktop accounting package and a separate inventory sheet. Nagoya tracked quotations and sales orders in spreadsheets emailed weekly to the parent. Kani phoned in material counts. The qualified invoice numbers sat on three different registration documents in three different drawers. Month-end took eight working days, and the group close depended on one controller who knew where every number lived.

The goal was not to merge the legal entities. Each one still files its own taxes and registers its own invoices, and that is correct under Japanese law. The goal was to run every entity on the same core business system, with each company's data fully isolated, so the group could finally see one consistent operational picture.

What unification actually means here

A common misunderstanding is that consolidation requires a single shared database where every entity's records sit in one pile. That is the opposite of what a group firm needs. Each company must keep its data fully isolated, both for clean accounting and for basic governance. The system this firm adopted enforces that isolation at the architecture level. Each company maps to its own dedicated data space, and records are kept fully separate from every other company. A Nagoya salesperson cannot see the parent's cost ledger. A Kani workshop lead cannot edit Nagoya's quotations.

Crucially, this isolation is the point, not a limitation. A Nagoya salesperson cannot see the parent's cost ledger, and that boundary is exactly what clean accounting and governance require. But because each company keeps its own isolated database, there is no built-in cross-entity rollup today. Producing one consolidated group number still requires a manual export step, the very spreadsheet rebuild the controller used to do every Friday, and a true consolidated reporting view is on the roadmap. The isolation each company needs is built; the single rolled-up group figure is not, yet.

Crucially, each entity keeps its own configuration. Plans, user limits, storage limits, and feature flags are set per company. The parent factory runs the full manufacturing set, including multi-level BOMs and manufacturing orders. Nagoya runs sales, quotations, and CRM. Kani runs a lighter configuration focused on inventory and finishing operations. One system, three fit-to-purpose profiles, zero duplicated tools.

Where the real time came back

The biggest win was not a single feature. It was the removal of hand-offs. Consider the order-to-cash flow that used to span all three entities.

A customer requests a quote. Nagoya raises a quotation in the system. On acceptance, it becomes a sales order. The parent factory sees the demand, allocates material against its multi-level BOM, and issues a manufacturing order that consumes components on completion. Finished parts move through inventory with lot traceability, so the lot tied to that automotive customer is identifiable for years. Kani's finishing step logs its work as an inventory operation. The invoice goes out under Nagoya's own qualified invoice registration number, with the correct output consumption-tax account and rate. Throughout, approvals route through configurable workflows, so a quotation over a threshold still lands on the right desk before it ships.

Before unification, that chain involved three phone calls, two emailed spreadsheets, and a weekly reconciliation meeting. After unification, it is one connected flow inside one core business system. The approval history itself serves as the audit trail, recording who approved what and when, which matters for J-SOX-style internal control without forcing the firm to build a separate logging apparatus.

Month-end close changed shape. Because sales invoices, purchase bills, and expense reimbursements auto-generate journal entries, the controller stopped keying routine transactions by hand. The double-entry ledger closes each period consistently, and budget-versus-actual comparison runs against the same numbers instead of a parallel spreadsheet. The eight-day close dropped to roughly three, for this seventy-person firm specifically, not a universal benchmark. That is real, measurable capacity returned to this group.

The honesty section: what is still manual

Any case study that claims everything is automated is lying to you. Here is what this firm still does by hand, and what is on the roadmap.

Multi-currency conversion is not automated. The schema has no exchange-rate field, and each company records amounts in its own single currency. For a domestic group like this one, operating entirely in yen, that is fine. For a group with overseas entities, foreign-currency translation is handled manually today through journal entries, and a built-in conversion engine is on the roadmap. If a vendor promises you automatic multi-currency on day one, ask to see the exchange-rate table. If they cannot show it, they do not have it.

Manufacturing-to-ledger auto-posting is also partial, by design. Labor, scrap, and material consumption do not automatically create accounting entries. Scrap is recorded as an inventory operation, and its accounting impact is booked through a manual journal entry. Only sales invoices, purchase bills, and expense reimbursements generate journal entries automatically. This is a deliberate boundary. It keeps the ledger clean and reviewable rather than cluttered with operational micro-transactions. The trade-off is that cost accounting for production still requires a human step.

Inventory valuation does not auto-post to the ledger either. When the firm wants to recognize inventory value changes in the books, the controller enters a manual journal entry. There is no immutable audit-log table in the traditional sense. Instead, the approval-workflow history and the recorded who-and-when on every record serve as the audit trail. For most mid-sized Japanese groups, that is sufficient and far cleaner than a sprawling event log nobody reads.

MES, capacity planning, shop-floor scheduling, payroll, and certified electronic-bookkeeping storage under Japan's electronic bookkeeping preservation law are not part of the built system. They are manual or handled in adjacent tools. The firm knew this going in, and it did not change the decision. The point of unification was to kill spreadsheet hand-offs and consolidate operations, not to install a factory execution system.

Frequently Asked Questions

Will switching disrupt our current close?

This is the fear that kills more consolidation projects than any technical issue, and the answer is to migrate one entity at a time. The parent went first during a quiet month, with parallel running for two cycles, then the next entity followed once the parent's close was stable, and the smallest went last. At no point did all entities change simultaneously, so switching risk is a sequencing problem rather than a software problem.

What does this cost, and is there a real ROI?

The firm ran the free plan first, which covers up to 2 users at no cost and requires no credit card, letting the controller and two leads validate the workflow before any spend. Once the group moved to paid plans, the calculation was the controller's recovered days, the elimination of one contracted bookkeeping helper, and the avoided cost of replacing the legacy on-premise system before the support cliff. Payback inside the first fiscal year is realistic for a group that currently depends on manual reconciliation, though a single-entity firm with a clean ledger will see less dramatic returns.

Does one system fit entities of very different sizes?

Yes, because each company keeps its own plan and feature set in Kikan System. The parent runs the full manufacturing and accounting configuration while a small workshop runs a stripped-down profile with just inventory and finishing. You are not forced to buy the enterprise package for an eight-person team, and you are not forced to run that team on a tool that breaks at the parent's scale, because the per-company feature flags make fit-to-standard realistic.

How do we handle qualified invoice numbers for each entity?

Each entity stores its own qualified invoice registration number and its own output and input consumption-tax accounts, including multi-rate handling for the 8% and 10% rates. Because each company's data stays isolated, there is no risk of one entity's invoices going out under another's registration number, which is exactly the per-entity structure the tax authority expects, reflected directly in the system.

The decision that mattered most

The technology in this story is not the hero. Plenty of ERP projects fail not because the software is bad but because the firm treated unification as a software purchase rather than an operating-model decision.

What worked for this group was a clear sequence. First, map the real flows across entities and admit which ones are broken. Second, consolidate operations onto one core business system while preserving per-company data isolation. Third, migrate one entity at a time with parallel running. Fourth, accept the honest boundaries around what is manual today and budget human time for it instead of pretending automation exists where it does not.

The result is not a perfect system. It is a coherent one. The controller gets the group number before the board call, not after. The successor who eventually takes over inherits a single, legible operation instead of three disconnected ledgers. And the firm faces the 2025 legacy cliff on its own terms, with one system instead of three expiring ones.

Key takeaway

Multi-entity unification is less about a single database and more about removing the hand-offs between entities. Run every company on one core business system, keep each company's data fully isolated, get a real consolidated view, and be honest about what is still manual. That combination is what lets a seventy-person Japanese group close in three days instead of eight.

If your group is staring at the 2025 legacy cliff or preparing for succession, start where this firm did. Kikan System gives you one core business system with per-company data isolation, configurable approvals, lot-traceable inventory, and a double-entry ledger that auto-generates journal entries from invoices, bills, and expenses. Begin on the free plan, up to 2 users, no credit card. Start at /#get-started, or compare plans at /#pricing.