ERP and Accounting

Something has caught my attention on this subject for years: most ERPs in Turkey are systems designed from an accounting background, while IFS and SAP were designed from a cost accounting background. This design difference can still be felt today.

The classic approach of Turkish ERPs

The first generations of products such as Logo, Netsis, Mikro, ETA and Zirve grew with this logic:

Ledger account
    ↓
Trial balance
    ↓
Financial statements

Analytical dimensions were therefore added later.

Where IFS started

In IFS, the starting point was this:

Ledger account
+
Cost Center
+
Cost Element
+
Project
+
Activity

The multi-dimensional structure sits inside the core.

Single axis versus multiple axes: the technical difference

The difference between the two approaches is clearest in the anatomy of an accounting line.

In a single-axis design, analysis information is embedded inside the account code. The code has to carry both the account and the breakdown:

770.01.003
 │   │   └── breakdown (rent? electricity? which unit?)
 │   └────── sub-breakdown
 └────────── main account (General Administrative Expenses)

In a multi-axis design, the account is just the account; analysis is carried in separate fields:

Account          770
Cost Center      PRD-01
Expense Type     ELECTRICITY
Project          P-2026-14
Activity         ASSEMBLY

The two structures seem to hold the same information. The difference is whether the information is compressed into a single axis or sits on independent axes. This difference grows as the number of breakdowns increases.

The breakdown explosion

Say you want to see 12 expense types, 8 cost centers and 6 projects separately.

In a single-axis structure you have to open a separate account for every combination:

12 × 8 × 6 = 576 accounts

In a multi-axis structure you define each axis once:

12 + 8 + 6 = 26 definitions

The real pain comes when a new breakdown is added. In a single-axis structure, opening a new cost center means opening new accounts for all of that center’s expense and project combinations — 72 new accounts in the example above. In a multi-axis structure, a single code value is added and the existing structure is not disturbed.

Behind the charts of accounts with thousands of lines we see in the field, this is usually the cause: because the system doesn’t think in multiple dimensions, the chart of accounts has taken the place of the dimensions.

The cost on the reporting side

The difference doesn’t stop at the number of definitions; you run into it when writing reports too.

In a single-axis structure, analysis is done by slicing up the account code:

-- analysis is extracted from inside the account code
SELECT SUBSTR(account_code, 1, 3) AS main_account,
       SUBSTR(account_code, 5, 2) AS expense_type,
       SUM(debit - credit)
  FROM gl_line
 GROUP BY SUBSTR(account_code, 1, 3), SUBSTR(account_code, 5, 2);

In a multi-axis structure, the fields are already separate:

-- analysis lives in its own columns
SELECT account, cost_center, expense_type,
       SUM(debit - credit)
  FROM gl_line
 GROUP BY account, cost_center, expense_type;

The difference between the two shows up in three places:

Performance. Queries that wrap a column in a function cannot use the normal index on that column. For details: our Oracle performance note.
Fragility. If the code structure changes once (a digit is inserted in the middle), the character positions in every report break.
Flexibility. In a multi-axis structure, reporting on a new breakdown is just a matter of adding a column to the query. In a single-axis structure, it often requires changing the chart of accounts.

Budget and control

Dimensions make not only reporting but also control possible. When you can build the budget on “cost center + expense type” instead of on “account”, the budget stops being a report and becomes a mechanism for warnings, blocks and approvals. We have written about this separately: Budgeting in SAP and IFS.

You don’t have to abandon the Uniform Chart of Accounts

There is a common misunderstanding here. Moving to a multi-axis structure does not mean abandoning the Turkish Uniform Chart of Accounts (TDHP).

The TDHP is a legal requirement; tax returns, financial statements and audits run through it. In multi-axis systems too, the statutory ledger axis is the account code. What changes is this: the analysis burden is lifted off the account code.

So account 770 stays 770; the electricity expense, the production department and the related project are carried in separate fields on the same line. Nothing changes on the tax return side, while on the management reporting side a door opens.

Cost centers exist but aren’t used

Logo, Netsis and Mikro all have these structures:

Cost Center
Project Code
Work Center
Department

But in most projects they aren’t used, because this view is widespread among users:

“Let’s open 770.01 Personnel, 770.02 Electricity, 770.03 Rent — that’ll do.”

As a result, even though the system has a cost center feature, the organisation doesn’t use it.

The only reason isn’t habit either. When the dimension field isn’t mandatory, some entries are left empty; an empty dimension makes the report unreliable; nobody looks at an unreliable report; nobody fills in a field nobody looks at. The cycle feeds itself.

Where to start

Moving to a dimensional structure doesn’t have to be a big project. The sequence that works in the field is:

Write down which decision you want to make. A concrete question such as “Which line has high energy costs?” also tells you how many dimensions you need.
Keep the number of dimensions small. Two well-maintained dimensions are better than six half-filled ones.
Make them mandatory. A dimension that can be left empty is a dimension that doesn’t exist.
Build the reporting on the dimension. Once teams start seeing their own cost center’s report, the field starts getting filled correctly on its own.

Logo, Netsis, Mikro, Uyumsoft, ETA and Zirve are registered trademarks of their respective companies; IFS of IFS AB; SAP of SAP SE. This note is an independent assessment.