The fiscal-period database problem
Common ERPs such as Netsis open a new database for each fiscal year (or every few years). From an accounting point of view this makes sense: the period closes and the new period starts in a clean database. But from a management point of view, it creates a problem. Putting last year next to this year means merging two databases correctly. Going back ten years means merging ten.
In most companies this is done in Excel: each year's report is pulled separately and pasted into one sheet. It's tedious, and it has to be redone every month.
The hard part: the name doesn't always tell the truth
The real trap is this: a database's name doesn't always correctly tell you which year it holds. Some databases also contain records from the neighboring year. For example, a database with 2023 in its name might contain transactions from both 2023 and 2024. A system that matches by name will show 2024 as empty or incomplete in that case, and won't tell you, because from its point of view there's no error.
An illustrative example:
| Year | Database where the transactions live |
|---|---|
| 2021 | ORNEKFIRMA2021 |
| 2022 | ORNEKFIRMA2021 |
| 2023 | ORNEKFIRMA2023 |
| 2024 | ORNEKFIRMA2023 |
| 2025 | ORNEKFIRMA2025 |
| 2026 | ORNEKFIRMA2025 |
A system that looks at names would show 2022 and 2024 as empty here.
READERP maps by counting
During setup, READERP counts how many transactions from each year sit in each database. Each year is assigned to whichever database actually holds its transactions. The result is a single time series: in the panel you move back and forth between years without needing to know which database is answering behind the scenes.
This mapping is part of same-day setup and is updated when a new period is opened.
What can you see in one series?
- Twelve years of monthly revenue in a single chart (revenue analysis)
- Customer and product comparisons across years
- The balance trend of a customer account over the years (receivables aging and the account scorecard)
- Seasonality: which months speed up every year, and which slow down
An honest limit
Some figures can't be rolled back into the past. Values such as a bank balance or the current stock quantity are positions; they show today's state. No balance query can tell you on its own what things looked like on a given day in the past. When you select a past year, READERP states clearly which figures belong to that year and which reflect today's state. Not saying so leads to a management meeting built on the wrong numbers.
Who is it important for?
Any company that has used the same ERP for many years and wants to see growth trends, seasonality and customer behavior across years. Especially in manufacturing and industry and wholesale distribution companies, long-term revenue and receivables analysis directly affects decision-making.
Frequently asked questions
How many years back can we go?
As many as you have fiscal-period databases. There is no limit on the number of years that can be merged into a single chart.
What if older fiscal-period databases are on a different server?
As long as the agent can reach them, databases on different servers are also merged into the same series.
Do we need to do anything when a new year opens?
No. The new fiscal-period database is detected and added to the mapping.
To see your data spread across years on a single line, talk to us.