The System Without the Year-End Rollover Nightmare
Minerva has fiscal years. It also has accounting closing and new-year opening. What it does not have is business transactions becoming invisible at year end. While working in fiscal year 2026, you see all of a customer’s movements from 2016 to today on a single screen, in a single list. Not as a carried-forward figure, but line by line.
The System Without Rollover- What is the year-end rollover, and why does it exist?
- Why did the accounting close spread to the entire system?
- What happens in the business on rollover day?
- The principle of business continuity
- What does the fiscal year do in Minerva?
- The accounting rollover: closing and opening
- Changing the chart of accounts at opening
- User authorization and fiscal year access
- The ten-year statement: a concrete example
- Which transactions does this capability cover?
- Frequently raised objections
- Summary comparison
- Conclusion
What is the year-end rollover, and why does it exist?
The year-end rollover is a natural requirement of accounting. When the fiscal year ends, income and expense accounts are closed, the result is transferred to equity, and the closing balances of the balance sheet accounts become the opening balances of the new year. There is nothing to debate so far; this is the science of accounting itself.
The problem begins on the software side. Many ERPs turn this operation, which is required to roll over the accounting, into a period-cutting mechanism applied to the entire system. Along with the accounting close, business transactions are also moved to a new environment; the old year is left behind.
In practice, this takes two main forms:
- Those that create a separate environment. A separate company, a separate period, or a separate data set is created for each fiscal year. The user switches to whichever environment holds the year they want to see. In the packages common on the Turkish market, the rollover is carried out by opening a new period, creating period files, or copying the company to create a new one.
- Those that keep a single database but tie reporting to the year. In the major packages, transactions remain in a single table, but balances are carried forward at the start of the year and standard reporting is anchored to the fiscal year. On the SAP side, the balance carry-forward is run as a separate operation, and carry-forward entries are created in period zero of the new fiscal year.
The right question is not this
“Does the system perform a year-end rollover?” For accounting, it must. The right question is: “Does this rollover also cut my business data?” This page explains that difference.
Why did the accounting close spread to the entire system?
There is a technical legacy behind this. In the 1980s and 90s, storage was expensive, and database engines could not carry today’s volumes. Partitioning by year was a necessity in terms of both performance and file size. System architects chose the most natural cut-off point: the fiscal year.
Once the architecture was built this way, the concept of the year settled at the very bottom of the data model. Tables, numbering templates, summary tables, reports — all were built on the fiscal-year key. Today the hardware constraint has disappeared, but the architecture remains.
Today, no technical justification requires a business to switch to another environment to see last year’s order. This is a solved problem, frozen in software.
Minerva did not carry this legacy. The system records a business transaction not as a sub-record of the fiscal year, but as an independent event with its own date. The fiscal year is an attribute of that event — not the compartment it sits in.
What happens in the business on rollover day?
In rollover-based systems, year end turns into a technical project. The typical flow is as follows:
- The costing operations of the old period are completed, and a backup of all data is taken.
- A period is defined for the new fiscal year and period files are created; in some installations, the company is copied to create a new company.
- The rollover program is run. During this time, no user may be in the system.
- Rollover parameters are set separately for headings such as general ledger, current accounts, banks, inventory, orders, delivery notes, and production.
- It is decided whether voucher numbers will continue from the old numbers or receive new numbers.
- Opening vouchers, exchange rate differences, and inventory costs are checked; if there is an inconsistency, the process is reverted.
- After the rollover, a warning applies that records must not be deleted or changed in the new period.
We are not exaggerating this list; these are the steps found in the guides of the firms that provide rollover services. Separately purchasing consultancy for the year-end rollover is also a common practice in the industry.
The hidden cost
- Several days of operational pause during the busiest period of the year.
- The risk of data losses that are hard to recover from if the rollover is not done correctly.
- Consultancy and verification effort repeated every year.
- Access to prior-year data turning into a “switch to another environment” task.
The difference here is not a naming preference. Customer, supplier, bank, competitor, employee are not entity types, but roles. Minerva places this distinction at the very bottom of the data model: first the identity is defined, then roles are added on top of the identity.
The principle of business continuity
What changes in your business between the evening of December 31 and the morning of January 1? From an accounting point of view, a period closes. From a business point of view, nothing. The same relationship with the same customer, the same contract with the same supplier, the same goods in the warehouse, the same equipment in the field continue.
A customer’s relationship with you is not divided into fiscal years. The history of a dealer you have worked with for five years is not a file split into five separate parts, but a single story. So is the cost trajectory of a product, the delivery performance of a supplier, the maintenance history of a piece of equipment.
Accounting is periodic; business is continuous. A system imposing the periodicity of accounting on business is a constraint with no counterpart in real life.
Minerva takes this distinction as its basis. Accounting works periodically, because legislation and financial statements require it. Business transactions, on the other hand, stand as an unbroken chain.
What does the fiscal year do in Minerva?
Minerva has the concept of a fiscal year, and it is necessary. But its function is different: the fiscal year is a classification tool, not a wall.
- It determines which period the financial statements belong to.
- It frames the accounting closing and opening operations.
- It provides the criterion for period selection and comparison in reports.
- It defines the time span to which budgets and targets are tied.
The one thing it does not do is hide business data outside that year. When a user selects fiscal year 2026, this does not mean “you can only see 2026 data”; it means “your default working period is 2026.” When they want to look at the past, they do not change environments; they widen the filter.
Same user, same screen, in fiscal year 2026
Access to business data: rollover-based system versus MinervaRollover-Based System — Accessible Business Transactions
Minerva — Accessible Business Transactions
The years shown as closed are not deleted in the rollover-based system; to access them, you must switch to a separate environment or run a separate archive query. On the daily working screen, only the carried-forward figure is visible.
The accounting rollover: closing and opening
In Minerva, the accounting rollover, as its name suggests, concerns accounting alone. It has two components: the closing of one fiscal year and the opening of the new fiscal year.
- The accounts of the fiscal year to be closed are closed; the result accounts are transferred to equity.
- The closing balances of the balance sheet accounts are determined.
- The new fiscal year is opened and the opening entries are created.
- The business side is unaffected by this operation; orders, delivery notes, invoices, inventory, and current account movements continue without interruption.
Rollover-based system
The entire system is put through the rollover in order to roll over the accounting.
Separate rollover parameters are set for headings such as current accounts, inventory, orders, delivery notes, and production.
The system cannot be used during the rollover; afterwards, access to the prior year requires changing environments.
Minerva
The rollover is only the accounting closing and opening.
There are no rollover parameters for the business modules, because there is no rollover.
Business operations do not stop during the operation; prior-year data is already accessible.
We can state this clearly:
Minerva does not eliminate the accounting close. Nor can it — financial statements and legislation require it. What Minerva does is keep the effect of the close confined to accounting.
Changing the chart of accounts at opening
The opening of the new fiscal year is a natural threshold for reviewing the chart of accounts. Minerva allows the chart of accounts to be changed at this threshold.
Typical situations with practical counterparts:
- Simplifying sub-accounts that have swelled over the years and are no longer used.
- Opening breakdowns for a new line of business, a new branch, or a new product group.
- Bringing the chart of accounts closer to a common structure across group companies.
- Reflecting a change in legislation or reporting standards in the chart.
- Carrying the detail required for management reporting into the chart.
In rollover-based systems, this change is usually postponed because it directly affects the structure of the opening voucher and prior-year comparisons. The result is a chart of accounts nobody is happy with but everybody puts up with. When the chart is changed in Minerva, the business data of prior years stays in place; you do not lose the ability to make comparisons.
Changing the chart of accounts:
Changing the chart of accounts in the new fiscal year is still a serious decision and should be planned together with your financial advisor. Minerva makes this decision easier; it does not make it unnecessary.
User authorization and fiscal year access
When a user logs in to the system, they can access all the fiscal years for which they have been authorized and the transactions belonging to those years. Access is determined not by changing environments, but by the authorization definition.
This has a two-sided consequence:
- Openness. A user who needs to see the past — the sales manager, the finance officer, the auditor — does not need a separate installation, a separate user account, or IT support to do so.
- Control. Access does not have to be unlimited. One user can be given only the last two fiscal years, another the entire history. Authorization is done on a per-year basis.
Entering records into closed fiscal years and viewing those years are handled separately. While a closed year is locked from an accounting point of view, the business transactions of that same year remain readable. Visibility is preserved without compromising the audit trail.
The ten-year statement: a concrete example
The screen in Minerva
12 Mar 2017 Invoice ..... 42,000
08 Sep 2019 Collection ..... 30,000
21 Jun 2022 Invoice ..... 118,000
15 Jan 2026 Invoice ..... 85,000
All ten years in a single list, in date order. You can narrow it with a year filter if you wish, or see it all together. There is no such concept as a carry-forward line.
The screen in a rollover-based system
Carried-forward balance ..... 1,240,000
15 Jan 2026 Invoice ..... 85,000
03 Feb 2026 Collection ..... 60,000
Behind the single carried-forward balance line lie nine years of transactions. To see these transactions, you must switch to the environment of the relevant year. Year-over-year comparison cannot be done on a single screen.
The everyday counterpart of this difference is simple. You are in a reconciliation meeting with your customer, and an invoice from 2019 is being disputed. In the rollover-based system, the meeting is postponed; in Minerva, you open the record and finish the conversation right there.
Which transactions does this capability cover?
The current account statement is only the most visible example. Rollover-free operation applies to all business transactions in the system.
- Sales and purchasing. Multi-year order history, price trajectory, discount practices, delivery performance.
- Inventory and warehouse. Ten years of receipts and issues for an item, turnover rate, dead stock analysis.
- Costing. The cost development of the same product over the years — as an unbroken series.
- Service and maintenance. The entire failure and maintenance history of a piece of equipment, from installation to today.
- Production. Recipe changes, scrap rates, the long-term trajectory of work center efficiency.
- Projects. Holistic tracking of projects spanning more than one fiscal year.
- Cheques, notes, guarantees. Natural tracking of instruments whose maturity extends into subsequent years.
Setting up a separate data warehouse for long-term analysis, moving prior-year data there, and keeping the two systems in sync — this is an additional cost created by rollover-based architecture. In Minerva, the data to be analyzed is already inside the system.
Frequently raised objections
Can a record be entered into a closed fiscal year by mistake?
No. Viewing authorization and posting authorization are managed separately. A closed fiscal year is locked from an accounting point of view; record entry is subject to authorization and period control. Rollover-free operation does not mean uncontrolled operation.
Does it create a problem in terms of audit and legislation?
On the contrary. Financial statements and tax returns continue to be produced periodically; nothing changes on that side. What changes is that presenting prior-period records to the auditor becomes easier. A request for retrospective review does not require setting up an old environment or restoring a backup.
Won’t the system slow down as the data grows?
This is a question that deserves to be taken seriously. Our answer is two-sided: the data model was designed from the outset for multi-year volumes, and the default filter on screens is the current fiscal year — you call up the past only when you want it. So not every query scans ten years. We measure your expected data volume together during the project and size the infrastructure accordingly.
We don’t need prior-year data anyway.
Most businesses say this because access is difficult. When access becomes easy, usage habits change too. Still, we pass this on not as a promise but as an observation: the analyses our customers use most are the ones that emerge after the second year.
Can we migrate our prior-year data from our current ERP?
Usually yes, but this is a data migration project and depends on the data quality of the source system. We evaluate together how many years of data are worth migrating; “let’s migrate all of it” is not always the right answer.
Summary comparison
| Topic | Rollover-based approach | Minerva |
|---|---|---|
| What happens at year end | A rollover project is carried out for the entire system | Only the accounting close and new-year opening are performed |
| Business transactions | Rolled over to the new period; the old year remains in a separate environment | Not rolled over; they stand as a single unbroken chain |
| Function of the fiscal year | A boundary that divides the data | An attribute that classifies the data |
| Prior-year statement | A single carried-forward balance line; changing environments for detail | All years in a single list, line by line, in date order |
| Working during the rollover | The system is closed to use | Business operations do not stop |
| Additional annual effort | Preparation, verification, and usually external consultancy | No additional operation for the business side |
| Changing the chart of accounts | Usually postponed because it breaks comparability | Can be done at the new-year opening; business history is preserved |
| Managing access to the past | A matter of environments and installations | User authorization on a per-fiscal-year basis |
| Long-term analysis | Usually requires a separate data warehouse | The data is already inside the live system |