One chart of accounts for a dozen entities, designed before the ERP

The leadership team here had built one of the largest TSL holdings in this part of Europe — around a dozen companies spanning transport, spedition, terminal operations, manufacturing, and trading. An organic group, family-controlled at the top, professionally managed at the operating level, with tens of millions of EUR in annual revenue and a serious operational footprint.

What the business had grown beyond was its financial architecture. Each subsidiary booked its accounting according to its own conventions, with no unified chart of accounts to consolidate against. Intercompany transactions weren't isolated in dedicated accounts, which meant consolidation eliminations had to be reconstructed manually each quarter. Profitability by business line — arguably the most important question leadership wanted answered — required spreadsheet gymnastics every time.

It's a pattern we see across organic groups and family-controlled holdings that have grown by addition rather than design: each entity made sense in isolation when it joined the group, but the collection never got reconciled into one architecture. Large groups roll out new ERPs with strong implementation teams that can model the most complex business structures. What's often missing is the experienced finance side — people who've lived consolidation, intercompany flows, and different business models inside one group. Without that, ERP rollouts stretch, scope grows, and the final architecture rarely answers the right questions. The leadership here saw the gap clearly and addressed it before the Comarch ERP decision was even on the table. They asked us to design the financial architecture first.

• A dozen subsidiaries, each with its own approach to bookkeeping and a different mix of business activities
• No unified analytical model — comparing performance across entities required spreadsheet rework every time
• Intercompany transactions not isolated in dedicated accounts, making consolidation slow and error-prone
• Three distinct business profiles (services, production, trading) needing one chart of accounts that worked for all
• A Comarch ERP implementation in scope — the architecture we delivered would need to underpin it cleanly

Week 1–2 — Discovery

‍Worked with finance and operations teams across the group's main subsidiaries. Mapped how each company books today. Identified what was shared across entities, what was specific to each. Defined what the group leadership actually needed to see at the consolidated level.

Week 3–4 — Design

‍Built the unified synthetic chart of accounts. Designed the cost structure (4xx for cost types, 5xx for cost by business segment, 7xx for revenue by business line). Built in intercompany isolation at the analytical level — every key account splits between capital-related entities, personally-related entities, and third parties — so consolidation eliminations can be generated directly from the system instead of reconstructed by hand each quarter.

Week 5 — Validation and handover

‍Worked through the proposed structure with the group's finance and operations teams. Documented analytical dimensions per business profile — vehicle, route, cargo type, and client for transport; production line, product group, work order for manufacturing. Delivered the report and the chart of accounts blueprint — ready to underpin the Comarch ERP implementation that followed.

• Unified chart of accounts (synthetic level) across the group
• Cost structure (4xx, 5xx) and revenue structure (7xx) supporting business-line reporting
• Intercompany isolation logic at the analytical level
• Per-company analytical dimensions tailored to business profile
• Implementation-ready blueprint and documentation for the Comarch ERP rollout

Designing a chart of accounts isn't glamorous work. But for a group with a dozen entities running a Comarch ERP rollout, it's the difference between operating off a clean foundation for the next decade and inheriting a structural problem the system will faithfully replicate. The leadership team here got that order right: financial architecture first, system selection second.

It's the pattern that defines the difference between organic groups that absorb their next ERP cleanly and the ones that spend three years trying to. The CFOs who get this order right are the ones who treat the ERP as the system the architecture runs on, not the system that decides what the architecture is.