.png&w=3840&q=75)
Optimise and Harmonise
When a company decides to align its fiscal year to group logic, to optimise intra-year reporting, or simply to correct a decision made during go-live, the most common reaction in management committees is: "We'll update the SAP configuration and that's it."
It doesn't work that way.
A Fiscal Year Change (FYC) in SAP is one of the few interventions that simultaneously touches the core of general ledger accounting, the structure of historical documents, period-end closings, and the referential integrity of the entire system. Executing it without a structured methodology means exposing the organisation to risks that materialise months after the conversion — often during an audit or a year-end close.
The Problem Nobody Sees Until It's Too Late
SAP manages the fiscal year through a set of customising tables — primarily T009, T009B, and T009Y — which define not only the structure of periods, but also how every single accounting document was posted over time. This data is not separate from the transactional history: it is intertwined with it.
When the fiscal year structure changes, all previously posted documents continue to carry references to the old schema. If the conversion is not handled correctly, the result is a database in which:
- open item balances do not reconcile with source documents,
- intercompany reconciliations generate unexplained differences,
- ageing and due date reports produce incorrect values,
- audit trails become discontinuous.
None of these issues is immediately visible. They surface in the weeks that follow, once closing processes start running against the new schema.
Why Complexity Is Systematically Underestimated
There are three structural reasons why this type of project is consistently underestimated during planning.
First reason: the distinction between normal and shortened fiscal years. SAP handles a standard fiscal year (twelve months) and a shortened one (for example, a nine-month transitional period during a migration) in fundamentally different ways. The tables involved, the conversion logic, and the preventive controls required all vary depending on which type of year exists in the historical data. An analysis that does not make this distinction produces an incomplete conversion plan.
Second reason: the order in which records are updated. When the same document number (BELNR) exists across multiple fiscal years, the update of key fields must follow a precise order — ascending by fiscal year — to avoid temporary primary key collisions at database level. This is a technical detail that does not appear in SAP customising manuals, yet it causes silent dump errors in systems with a high volume of historical documents.
Third reason: the conversion may be partial — and that changes everything. In a SAP system with multiple company codes, the fiscal year is not necessarily uniform. Some entities may already be operating on the new schema while others are still on the old one. The conversion may therefore apply to a single company code, a subset of organisations, or the entire client. This distinction is not an operational detail: it determines the scope of data to be converted, the intercompany dependencies to be managed, and the risk of misalignment between entities that share clearing documents or intercompany counterparts. A plan that does not explicitly map which organisations are in scope — and which are not — almost always produces reconciliation anomalies at group level in the weeks following the conversion.
What a Serious Pre-Conversion Analysis Must Cover
Before planning any conversion activity, a diagnostic analysis is required that answers at least four questions:
1. What is the actual fiscal year history of the current system? How many fiscal years have been posted in the system? Are there shortened years in the history? What is the document volume per year? Without this mapping, any estimate of effort and risk is arbitrary.
2. Which customising objects are involved and what is their current state? Tables T009B and T009Y must be analysed not only in their current structure, but in relation to the historical documents. A field that appears insignificant may be critical to the consistency of a subset of documents from prior years.
3. Is document number range coverage (NRIV) adequate? The number range interval table must correctly cover all document types that will be redistributed under the new schema. Incomplete coverage produces posting errors in the first weeks after the conversion.
4. Which closing processes are underway or imminent? A fiscal year change cannot be executed in any arbitrary time window. The analysis must identify dependencies with monthly closings, intercompany reconciliations, and reporting deadlines to the parent company or regulatory bodies.
The Inquaero Approach to Fiscal Year Change
The Veloce FY Change service by Inquaero is structured in two distinct phases, with a validation gate between them.
The analysis phase produces a comprehensive diagnostic report of the current system: structure of historical fiscal years, document volume and distribution per year, state of customising tables, NRIV coverage, dependencies with closing processes, and identification of all fields that are candidates for conversion. This report is the basis for any subsequent decision — including the decision not to proceed, if the risk is too high at a given point in time.
The conversion phase follows a validated execution plan, with scripts tested on a quality client that replicates the volume and distribution of production data. Before execution in production, a full backup of the affected tables is taken, with a documented and verified restore procedure. Execution takes place within a time window with an active posting freeze: no documents are posted against the new schema until post-conversion checks are complete. All script operations are tracked via BAL logging with timestamp, technical user, and record count per table — producing an audit trail that is readable by both internal reviewers and external auditors.
What This Means for a CFO
A fiscal year change is not an IT project. It is a financial project with technical implications. The relevant decisions — timing relative to closings, management of historical data, consistency of reports towards the consolidation — are decisions that belong to the Finance function, not IT.
Delegating it to an unstructured execution means accepting a data integrity risk that materialises at the worst possible moment: during an audit, a due diligence, or a year-end close.
The cost of a poorly executed conversion is not the cost of the project. It is the cost of weeks of forensic data analysis, manual adjustments, delayed closings, and — in the worst case — the loss of system credibility with auditors.
Next Steps
If your organisation is considering a fiscal year change — or if you have already planned a conversion and want an independent validation of the analysis scope — the first step is a diagnostic assessment of the current system.
Request a free preliminary analysis to understand the real complexity of your scenario and which risks are worth addressing before starting any conversion activity.
Inquaero is a SAP partner specialised in high-complexity projects on live SAP systems. The Veloce FY Change service is designed for organisations that cannot afford accounting anomalies after conversion.
.png&w=3840&q=75)
.png&w=3840&q=75)