Why Adding a Company Never Just Doubles the Work

Part 1 of our Multi-Entity ERP Implementation series.

Somewhere in the first month of nearly every multi-entity ERP project, someone says a version of the same sentence: “Let’s just set up the new or next company the way we set up the first one.” It sounds efficient. However, it is usually the moment the project quietly starts to fail.

Adding a second legal entity to your environment does not double the work. It changes the work. A single-company implementation is mostly a process project. A multi-company implementation is an operating-model project that happens to use ERP, and configuration should be the last place those decisions get made, not the first. The software will accept almost any structure you build, including the wrong one. It has no opinion. However, the audit, the close, and your next acquisition will have plenty.

Four Jobs Hiding Inside One Org Chart

Before anyone creates a company record in the system, it helps to identify the job each entity performs. Honestly, “subsidiary” is not much of a job description. Most groups are running some combination of these four:

• An operator: making, moving, selling, or serving somewhere in a primary value chain
• An integrator: serving its siblings inside the same chain
• A buffer: standing apart from core operations to mitigate risk
• A shared bet: a partnership or joint venture the parent doesn’t wholly own

Most mid-market groups are hybrids: a few tightly coupled operating companies, a services or treasury parent, a buffer or two, and maybe a joint venture that shows up on the org chart looking exactly like everything else. If your ERP design treats each of those the same, you haven’t skipped a critical step. You have overlooked the entire planning problem.

Three Reasons Parents Have Children

Underneath the four jobs lies a simpler question: what is the parent’s intention for each company held? There are three common answers.

The first is to operate together. Subsidiaries in this camp make, move, sell, or support the same value chain and trade with each other constantly. Intercompany as an operator is not a month-end nuisance; it is a normal Tuesday.

The second is to contain risk and diversify earnings. These entities exist to protect collective interests, ensuring setbacks lessen the threat to the whole group. They might share a treasury function and a board of directors and very little else.

The third is to share a bet. Partnerships, joint ventures, and alliances exist because the parties decided they did not want to own the outcome alone. Percentage of ownership tells you almost nothing about how to build the system. On the other hand, control of the operations tells you everything. If the managing partner isn’t named intentionally, the implementation will pick one by accident, with whoever’s system of record becoming the default.

Name the intention for each company before discussing system modules. If you skip this step, future scope discussions may evolve into debate sessions.

What the Word “Company” Could Be Hiding

Here is a small but expensive trap: legal reality, the management story, and the system record are three different things wearing the same name. A company as defined by law may not perfectly match the segment in a management report or a company record in your ERP system. Forcing them to align is how a group ends up with fourteen “companies” that are merely fourteen answers to “can we get a profit and loss statement for that?” A new legal entity should exist because of incorporation, tax ID, currency, fiscal calendar, or a genuine subledger intercompany requirement, not because someone wanted their own tab in a report.

The Same Pattern Appears Everywhere

Let’s dispel the myth that the job/company pattern applies only to limited industries. Whether a manufacturer runs both a components branch and an aftermarket business, a brand owner manages wholesale and retail banners, a biotech company separates discovery from commercial functions, or a professional services firm shares an admin function, different industries face the same underlying design questions. If a blog series, or a project team, treats any one of these scenarios as unique, it will miss the pattern that emerges everywhere a parent company operates more than one kind of business.

Design for the Future

Challenge the implementation team to think beyond the entities that already exist. Plan with the future in mind. What does the future holding company look like? What would an additional shared services branch look like? Is there a likely acquisition target, or a joint venture already being discussed in a room the ERP team is not in? If you only design for today’s organizational chart, the next deal will reopen legal-entity definition, the chart of accounts, intercompany, security, and reporting, usually all at once and usually on a timeline nobody planned for.

Before Configuration Begins

Here’s a helpful question to consider for every entity, current or future: if this company disappeared tomorrow, would operations stop, or would risk concentrate somewhere else? The answer highlights which of the four jobs it is really doing. This job, not the industry and not the software, is what should drive the design.

As part of this initial discovery, compile a concrete deliverable to guide the team forward. The result is a functioning one-page entity inventory. At a minimum, it should include the purpose, ownership, control, hosting, and intended future for every entity that you have and for every entity you can already foresee. Sorting out these details at the onset of the implementation means you will spend the rest of the project making decisions instead of discovering them.

Next up in this series: designing for the company you have not bought yet, and why the container you put an entity in (legal entity, segment, or something else entirely) matters more than you think!

Put this into practice with our free Entity Inventory template, a one-page structure for capturing the purpose, ownership, control, hosting, and intended future of every entity in your group. Download the Entity Inventory template: