Why Each Company Keeps Its Data Fully Isolated in a Core Business System

It is the Wednesday before month-end close. The accounting manager at a mid-sized trading group in Nagoya opens the ledger to confirm a customer's payment, and the screen shows a name she does not recognize. A subsidiary in Osaka, on a different product line entirely, has somehow surfaced inside her records. She freezes. Is this a display bug, or has someone in the head office been reading the subsidiary's invoices for months without anyone noticing?

Scenes like this are more common than vendors admit. When a core business system mixes records that belong to different companies inside the same database, the damage is rarely a single leak. It is the slow erosion of trust. The subsidiary starts to wonder whether its pricing is being shared with the parent. The parent worries the subsidiary's tax settings are corrupting its own books. And the auditor, told that everyone "shares one system," asks the one question that ends the conversation: prove that no one can see what they should not.

This post is about how a properly designed core business system answers that question. It is written for business owners, CFOs, and operations heads who run, or are about to run, more than one company on one platform. The short version: each company keeps its data fully isolated, one company cannot see another company's records, and the controls that enforce that separation are exactly the controls an auditor wants to see.

A Single ERP, Separate Company Data

Most groups arrive at a shared ERP for a sensible reason. Running one accounting package per subsidiary, one inventory sheet per warehouse, and one sales tool per business unit means three logins, three sets of master data, and three places where a customer name can be spelled six different ways. The attraction of a single core business system is consolidation: one place to define a chart of accounts, one set of tax rules, one place where the month-end close actually closes on time.

The fear that comes with consolidation is older than the cloud itself. If everyone is on the same platform, what stops one company from drifting into another's data?

The answer is per-company data separation. In a well-built ERP, the platform is shared but the records are not. Each company that signs up gets its own isolated data space. Its invoices, bills, journal entries, inventory movements, manufacturing orders, customer leads, and timesheets live inside a boundary that the system draws at the moment of login and never lets the request cross. When the Nagoya accounting manager logs in, the system resolves her to one company's data and refuses, by design, to return a row that belongs to any other company.

This is different from a "shared folder with permissions." Permissions are a rule that a user politely obeys. Data separation is a boundary written into how records are stored and retrieved, so that a record from company A is simply not reachable from a session that belongs to company B.

What a Buyer Should Be Able to See

When you evaluate a core business system for a group, you should be able to point at a small set of concrete mechanisms and hear a plain answer about each. Vague promises about "security" are not enough. Ask for the following.

A separate data space per company. The system should give each company its own isolated set of records, and it should be able to explain what that boundary is made of. The strongest designs do not rely on a single shared database with a filter; they keep each company's records apart at the storage layer, so a query that forgets the filter still cannot cross the line.

Resolution at the moment of the request. Every request that touches data should be tied to exactly one company, resolved from the login, the host the request came from, or an explicit identifier the system validates. There should be no global "give me everything" path that an everyday user can reach.

Login tied to the company. A user belongs to a company. The same login should not be a master key to every company's records. Access should be granted by role, and the role should operate inside the company the user belongs to.

Suspendable, not just deletable. When a company leaves the group or a trial ends, the right move is not to shred records quietly. The system should be able to mark a company as suspended, so that every login for that company is blocked at the door while the data stays intact for the audit window.

Feature and limit control per company. A group rarely buys the same package for every subsidiary. The system should gate features and limits per company, so the manufacturing arm can turn on lot traceability and manufacturing orders while the holding company runs only accounting. One company hitting its user or storage limit should never cap another.

If a vendor cannot show you these five things, the "shared platform" pitch is doing a lot of heavy lifting for very little underneath.

The Scenario That Makes It Real

Consider a precision parts maker in Higashi-Osaka, about seventy staff, with a smaller sales subsidiary of fifteen in Yokohama and a warehouse operation of ten in Fukuoka. Head office wants the group on one core business system so that month-end close, inventory, and tax filing stop being three separate fire drills.

The CFO has two non-negotiables. The subsidiary in Yokohama handles a customer list the parent is contractually not allowed to see, because a former shareholder's exit agreement put a wall around that book of business. The warehouse in Fukuoka keeps lot records for traceability, and those records must never be editable from the sales office.

On a system with real per-company data separation, the group signs up three company spaces on one platform. Each has its own records. The Yokohama sales team logs in and sees only their leads, quotations, and sales orders. The head office in Higashi-Osaka logs in and sees its own invoices, bills, and the consolidated reports it builds from exports, not from a live peek into the subsidiary's customer file. The Fukuoka warehouse runs inventory movements, transfer orders, and lot traceability inside its own space.

Because access is granted by role, the CFO in Higashi-Osaka can hold an administrator role in her own company without holding any role in Yokohama. The system never offers her a button to open the subsidiary's customer list, because that data is not in her space. When the month-end close runs, each company closes its own books on its own double-entry ledger, and the group consolidates through export and review, not through a shared live ledger that everyone can read.

The numbers make the case sharper. Japan's publicized security incidents reached 165 cases in 2025, up roughly 1.4 times from 121 the prior year, according to Cyber Security Cloud's 2025 Corporate Security Incident Survey Report. Roughly 70 percent of cyber incidents at small and mid-sized companies in Japan went on to affect a business partner, per IPA's 2024FY SME Security Survey (published February 2025). When a group runs mixed data, one breach is everyone's breach. When each company keeps its data fully isolated, a problem in Yokohama does not become a problem in Higashi-Osaka.

How Isolation Meets the Japan Pressure Points

Per-company data separation is not a security feature bolted on the side. It is the same boundary that makes the daily work of a Japanese business possible.

Take the qualified invoice system. Each company in a group registers its own qualified invoice registration number, files its own consumption tax, and keeps its own output and input tax accounts. A group running mixed records ends up guessing which number belongs on which invoice. A group running per-company separation keeps each company's registration number, tax rates, and output and input tax accounts inside its own space, so the invoice and the tax return are built from one company's facts and nothing else.

Take the month-end close. Each company has its own chart of accounts, its own budgets, and its own closing schedule. The system's approval workflows run inside each company, so a journal entry that needs sign-off in Fukuoka does not accidentally surface in a Yokohama approval queue. When closing is done, the group can compare budget versus actual per company without ever merging the underlying ledgers.

Take inventory and traceability. Lot traceability, movement, transfer orders, and shipments live inside the company that owns the stock. A recall that depends on a lot number returns records from one company's space, not a cross-company soup where the same lot number could belong to two unrelated operations. Scrap, treated as an inventory operation, stays inside the same boundary.

Take the people. Timesheets, attendance, check-in and check-out, and leave applications belong to the staff of one company. A sales rep in Yokohama should not be able to clock time against the Fukuoka warehouse, and the system should make that impossible rather than merely frowned upon.

What Is Manual Today, and Why That Honesty Matters

A good vendor tells you where the automation ends. Per-company data separation is built and enforced in the system described here, and the modules it protects (double-entry accounting, qualified invoice handling, lot traceability, approval workflows, timesheets and attendance, CRM, sales, purchasing, inventory, expense reimbursement, and the partner-facing B2B portal) all run inside that boundary. The B2B portal itself respects the same separation: a partner logged in through the portal reaches only the records the owning company exposes, not the whole platform.

What is not built is the part a CFO will ask about next. Consolidated accounting across companies is not auto-generated. The system does not push one button and produce a group consolidation that merges the subsidiaries into a single set of consolidated financial statements. Each company keeps a clean, isolated double-entry ledger, and the group builds consolidation the way audited groups always have, by exporting per-company results and reviewing them. There is no multi-currency engine with exchange rates maintained per company, because there is no currency field in the data design today; companies operating in different currencies handle that outside the ledger. There is no dedicated immutable audit-log table; instead, the approval workflow history records who approved what and when, and that record lives inside the same per-company boundary.

This honesty is the point. The strongest data-isolation story is one where the boundary is real, the automation inside it is real, and the line between built and roadmap is drawn in daylight. A vendor that promises a magic consolidation button usually means the records were never truly separated in the first place.

Frequently Asked Questions

It works until it does not. A shared folder is permission on top of mixed data. The moment a link is forwarded, a sheet is duplicated, or a departing staff member downloads the folder, the separation is gone. Per-company data separation in Kikan System does not depend on people remembering the rules, because the boundary is enforced on every request, whether the user is careful or not.

If each company is isolated, how does the group ever see the whole picture?

Through controlled export and review, not through a live shared ledger. Each company closes its own books, and the group pulls per-company results on a schedule and consolidates them with human judgment. That is exactly what an auditor expects for a group that takes internal control seriously, because isolation is what makes the per-company numbers trustworthy enough to consolidate.

Our subsidiary is too small for this to matter. Is isolation really worth it?

Small companies leak too. The finding that a large share of cyber incidents at small and mid-sized companies goes on to affect a business partner is precisely the case for isolation. A small subsidiary with a weak perimeter should not be the door into the parent's books, and putting each company behind its own boundary protects the small one and the big one at the same time.

Will this slow down our staff with more logins?

No. A user belongs to one company and works inside it with a single login. The boundary is invisible during normal work, and it only becomes visible when someone tries to reach a record that is not theirs, which is exactly when you want it to be visible. You can try this on the free plan, which supports up to 2 users with no credit card required.

Why 2026 Is the Window to Fix Your Core Business System Boundary

The 2025 legacy cliff that Japan's Ministry of Economy, Trade and Industry warned about has now arrived as lived reality, and METI updated its legacy-systems findings again in May 2025. Roughly 60 percent of core systems at Japanese companies were projected to pass 21 years of age, and the modernization pressure has not eased. Groups that renewed by bolting a new front end onto a shared, mixed-data back end are now sitting on the same risk the cliff was supposed to retire.

The groups that come through cleanly are the ones that treated data isolation as a first-class requirement, not a line item. They chose a core business system where each company keeps its data fully isolated, where access is granted by role inside that boundary, and where the gap between built automation and roadmap is stated plainly. That is the architecture that survives an audit, a partner question, and the next incident headline.

Key Takeaway

Per-company data separation is not a feature. It is the structural promise that one company cannot see another company's records, enforced at the storage and request layer, and it is what turns a shared platform into something a group can actually trust.

See Isolation on Your Own Group

Kikan System gives each company its own fully isolated data space on one platform, with access granted by role, qualified invoice and consumption tax handled per company, and approval workflows, lot traceability, and double-entry accounting running inside that boundary. Start free with up to 2 users and no credit card at /#get-started, or compare plans at /#pricing. If your group is weighing a renewal, bring your subsidiaries and your audit questions to the first call.