Most of the ERP and accounting programs widely used in Türkiye keep each financial year as a separate period. In many installations a separate fiscal-period database or period record is opened every year, and balances are carried forward to the new year with opening entries. From an accounting point of view this makes sense: the closed year is locked and the new year starts clean. From a management point of view it creates a problem. The answer to "Which customers' share has dropped over the last five years?" sits in five different places. In this post we explain why merging fiscal-period databases into a single time series is hard and how to do it properly.
Why is the data split by period?
There are two main reasons for the split. The first is legal and accounting order: records for a closed year must not change afterward. The second is performance: as years pile up a single database grows, and separate periods keep day-to-day work fast.
Inside the ERP the split causes no trouble, because almost all daily work concerns the current year. The problem starts the moment management asks retrospective, comparative questions.
Five traps when merging
Putting periods side by side is not as simple as pasting files one under another. These are the most common traps:
- Code changes. A customer's account code or a product's stock code may have changed over the years. In the merge, the same company shows up as two different companies.
- Carry-forward entries. If opening and carry-forward entries are summed like ordinary transactions, balances are doubled. Carry-forward entries have to be recognized and kept apart.
- Chart of accounts changes. Over the years sub-accounts are opened, closed and merged in the chart of accounts. The same item may sit in different accounts in different years.
- Currency and exchange rates. If the rate used for foreign-currency transactions isn't consistent across years, comparisons are misleading.
- The effect of inflation. Nominal revenue growth does not necessarily mean real growth. Year-over-year comparisons should also look at volume-based indicators and a real-terms reading.
What does a proper merge look like?
A well-built merge reads each period exactly as it is in its own database, then maps them through a shared dictionary. That dictionary holds matches like "this account code in 2022 is the same company as that account code in 2025." Carry-forward entries are filtered out, transactions are ordered by date and a single time series emerges.
The critical point here is this: the merge should not be done inside the ERP. Writing to old periods, changing closed years or adding new tables to the ERP is risky both for audits and for ERP updates. The right approach is to only read the periods and produce the merged view in a separate layer.
What changes when you see it as one series?
Seeing five years on a single curve reveals things you can't see within one year:
| Question | Within a single period | In the merged series |
|---|---|---|
| Seasonality | The months of one year | A pattern that repeats every year |
| Customer loss | Accounts that declined this year | Accounts that have been slowly declining for years |
| Product life cycle | This year's sales | Product groups rising and fading |
| Collection behavior | This year's average | How payment times have drifted over the years |
A merged series also makes budgeting easier: next year's target can be built on the actual average and trend of several years rather than a single year. In particular, a slow lengthening of collection times over the years is almost impossible to notice by looking at one year. We explain how to measure it in our post on the receivables aging report.
Checklist before you start
- How many years of data do you need, and are old periods still accessible?
- Are there several company records within the same business?
- Were account and stock codes changed in bulk at some point over the years?
- Was there a major restructuring of the chart of accounts?
- Which exchange rate is used for foreign-currency transactions?
- Who will verify the merge? (Comparing a few figures with your accountant or head of accounting is a good test)
How we do it at Globya
We see this need most often at companies using Netsis and Logo, the ERP systems widely used in Türkiye. READERP reads the fiscal-period databases of the common ERP and finance platforms on the market, led by Netsis and Logo, in read-only mode and merges them into a single time series; it never writes a single line to the ERP and never touches closed years. Setup is done the same day, and on the merged data you can look at ready-made views such as Cash, Receivables, Revenue and Stock, or ask questions like "compare March revenue for the last three years" in plain Turkish. For company-specific issues such as code mapping, we work with you as part of our ERP and reporting service. For choosing an overall approach, see also our post on management reports from Netsis and Logo data.
Frequently asked questions
Wouldn't it be better to move old periods into a single database?
From an accounting point of view this is usually not recommended. Changing records for closed years breaks the audit trail and can cause trouble during ERP updates. Merging outside the ERP, by reading only, is safer.
Our account codes changed over the years. Can they still be merged?
Yes, but you need a mapping dictionary. Fields that don't change, such as the tax number, automate most of the matching; the few remaining exceptions are verified by hand.
How many years back makes sense?
For most management questions, three to five years gives enough perspective. Patterns such as seasonality and customer behavior become clear over that span.
The Globya assistant is online 24/7; it answers right away and passes your question to the team if needed.