Every article in our ERP series ends the same way: keep your system, add a layer. This one is about the other half of that bargain — how to run the system so that the layer, whoever builds it, has something worth building on.
It comes from a specific observation. We connect POHODA, HELIOS, Money, ABRA, Comarch, enova365, Business Central, SAP, Xero, QuickBooks and the rest — 70+ companies across 11 countries, on 12+ different ERP and accounting systems. The governed model that sits above them is structurally identical in every engagement: the same fact tables, the same dual mapping, the same dimensions, the same scenario architecture. The only component that differs per system is the connector.
That has a consequence worth taking seriously. If the model above every system is the same, then what makes a company cheap to connect — and expensive to repair — is not which system it runs. It is a short list of practices inside whichever system it runs. Companies that follow them get first reports in a week and keep their history through a migration. Companies that don’t buy a repair project first.
Here is the list. None of it requires our involvement, new software, or a project. All of it is decided at the moment someone enters a document.
1. One entity, one set of books
Every system in the series draws the same boundary: one accounting entity per database, company file or subscription. POHODA, Money and HELIOS hold one entity per database. Comarch Optima keeps one company per baza firmowa. QuickBooks holds one company per realm and documents that two can never be merged.
The boundary is not a limitation to work around — it is the design that keeps statutory books defensible. The failure mode we meet is the workaround: divisions booked as pseudo-entities inside one set of books, or two legal entities squeezed into one company file “to see them together”. Both corrupt the one thing the system does perfectly — a clean, auditable record of one legal entity — in exchange for a group view the system was never going to render well anyway.
Keep the boundary clean. The view across entities is a layer above the system, built properly as consolidation , and it works best when each set of books underneath is exactly what it claims to be.
2. Extend the chart of accounts downward — and map it twice
The statutory chart of accounts answers to the tax authority. That is its job, it does it well, and every attempt to make it also answer management questions ends in the same place: account numbers that mean something only to the person who invented them, and a chart that serves neither master.
The practice has two halves. First, extend downward, never sideways: create analytical accounts under the standard synthetic structure your jurisdiction defines, and resist inventing top-level creativity. In the Czech and Slovak účtová osnova the first digit of an account already tells every reader — and every tool — whether it is a balance sheet or profit and loss item; in the Polish plan kont the team-5 cost accounts carry an analytical convention every accountant recognises. That structure is free machine-readable metadata. Preserve it.
Second, map the chart twice. The statutory view stays untouched. A second, management structure — revenue by what you actually sell, cost by what you actually control, margin at the level where decisions happen — is a mapping over the accounts, versioned, owned by a named person, reviewed at each close. Every implementation we run carries exactly this dual structure, on every system. The design principles are in our chart of accounts architecture guide ; the practice for you is simply to keep the raw material clean enough that the mapping is a table, not an archaeology project.
3. Dimensions at the moment of entry — the practice that pays for all the others
Every system in the series has a mechanism for tagging a transaction with management meaning beyond the account. The names differ; the mechanism is the same:
| System | What it calls the dimensions | Where they attach |
|---|---|---|
| POHODA | Středisko, zakázka, činnost | Documents and postings |
| Money S3 / Money ERP | Controlling variables — středisko, zakázka, činnost | Document and line level, readable and writable through the API |
| HELIOS iNuvio | Středisko, zakázka, nákladový okruh, vozidlo | Through purchasing, stock, payroll and the ledger |
| ABRA Flexi / Gen | Středisko, zakázka, činnost | Transactions, alongside the statutory posting |
| Comarch ERP Optima / XL | Opis analityczny — MPK, project, custom dimensions | Documents and ledger entries; a separate licence in Optima |
| enova365 | Opis analityczny plus cechy (custom attributes) | Almost any object, at line level on trade documents |
| Subiekt / Rewizor | Plan kont analytical segments, team-5 MPK accounts; kategorie and cechy | Accounts, documents, products and customers |
| Symfonia | Wymiary analityczne, MPK, dictionary-backed słowniki | Postings, counterparties, accounts and documents |
| Superfaktúra | Tags — labels rather than a hierarchy | Invoices, expenses and clients, on the top plan |
| Business Central | Dimensions — two global, up to eight shortcut | Every posted line |
| QuickBooks Online | Class and location — Plus and Advanced only | Class per line or transaction; location per transaction |
| Xero | Tracking categories — two active at a time | Transaction lines |
The rules are the same in every row. One list per dimension, owned by one named person — not three cost centre codes for one department because three people set them up. Filled at the moment of entry, not reconstructed at close — a dimension added retroactively is an estimate wearing a code. Reviewed on a cadence — quarterly is enough — so jobs get closed when the work closes and dead codes get retired instead of accumulating. Validated above the system where the system itself cannot enforce the rule: most can’t, which is why exception reporting exists.
This is the highest-return practice on the list, and the most commonly half-done. When we audit dimension usage across a client’s history — by module, by document type, by year — the pattern is almost always the same: two good years, then drift. The companies that held the discipline get profitability analysis almost for free. The companies that didn’t get a repair project — done in the layer, so nobody touches history in the system, but a repair project all the same.
4. The subledger ties to the ledger — daily, not at close
What was sold and what was booked are recorded in different places in every system — trade documents in one structure, journal postings in another, sometimes in different products entirely. The InsERT family makes the split explicit — Subiekt records the sale, Rewizor books it — but the same seam runs through every system on the list, and through every invoicing platform sitting beside an accounting system.
The practice is document discipline. Nothing booked directly to the journal where a source document exists. Credit notes linked to the documents they correct. Advance invoices resolved promptly rather than left half-settled. Bank items matched, not parked in suspense. The test is simple: can the revenue line in the ledger be decomposed back to documents, today, without a spreadsheet?
Where the books are kept this way, reconciliation between subledger and ledger becomes a short, automatable daily control — a categorised list of timing differences and corrections instead of a month-end argument about which number is right. Where they aren’t, every close starts with forensics.
5. Plan in the shape of actuals
Most budgets are built in a spreadsheet whose rows were invented for the budget. Then twelve months are spent translating between that geometry and the ledger every time someone asks about a variance.
The practice: budget on the accounts and dimensions you book on. Same chart, same cost centres, scenario as a label — plan next to actual in the same structure. In every model we run, plan and projection sit in the same journal structure as actuals, blended at a cutoff date, which is what makes a rolling forward view fall out of the model instead of being a separate project. That architecture is only possible because the plan was born in the same shape as the books.
If your planning tool cannot hold the ledger’s structure, hold the mapping between them formally — one table, owned, versioned — rather than in the head of the analyst who built the budget.
6. Currency at the transaction, translated once
Every multi-currency mess we untangle started the same way: rates maintained casually, translation done in reports, each report translating differently. The practice costs nothing: let the system fetch its official daily rates automatically where it supports that, book revaluations at close where the jurisdiction requires them, and record every transaction with its transaction currency and rate. Translation to a reporting currency then happens once, consistently, in one place — not per report, per person, per meeting.
7. Definitions outlive connectors
The tooling around your ERP will change faster than the ERP. Microsoft is retiring its first-generation Dynamics MCP server one generation after it shipped. BI tools get replaced. Report authors leave. Every vendor in the series now ships or has announced an AI surface, and each one will happily answer questions about your data the moment it is connected.
Which is exactly the risk. A KPI defined inside a report object dies with the report. A margin definition living in one analyst’s SQL dies with the analyst. And an AI assistant connected straight to a transaction system — over MCP or anything else — inherits raw tables with no ruling on which of three revenue figures is the one the board sees. That is why AI fails on raw ERP data : not for lack of access, but for lack of meaning.
The practice: every measure that matters has one written definition, one owner, and one home that is not a report, a spreadsheet or a connector. For our clients that home is the governed layer, where the definition is enforced rather than merely documented. But the discipline stands on its own — a definitions register maintained in finance beats definitions scattered across report objects, on any system, with any tooling.
What this buys you
Three things, all of them published rather than promised.
Reporting gets cheap. Stahlmann came to us on POHODA with — their case study says it plainly — good basic processes in place. That is why the engagement was analytics from day one rather than repair: real-time profitability across 20,000+ SKUs and three channels, built on books that were already worth reading.
Migrations get safe. When JING Tea replaced its operational stack , the reporting layer carried through the change unaltered — because meaning lived above the systems, the systems could move. Run your ERP as if you’ll change it someday and the day it happens is an integration task, not a reset of institutional memory.
Group views become possible. TEPEDE consolidates 8 entities across 6 countries on 6 different ERPs daily. That works because each entity’s books are clean within their own boundary — practice one on this list, held eight times.
None of these practices requires choosing us, and none requires changing your system. That is rather the point. The ERP decision matters less than it appears; the entry discipline matters more. If you want to know where your own books stand, that is what a diagnostic is for .