SAP S/4HANA Finance Migration: Where Projects Fail and How To Fix It

Learn how to identify and resolve SAP S/4HANA finance conversion risks, prepare accounting data, and validate financial results before go-live.

Imagine that your company has just completed a test conversion to SAP S/4HANA. The system is running, users can log in, and the initial technical checks look promising. Then the finance team starts comparing the numbers. A report no longer matches its previous output, an asset value needs investigation, or a familiar closing procedure produces an unexpected result.

The production go-live date is getting closer, and another testing cycle could put the schedule under pressure. What initially looked like a minor accounting discrepancy now requires attention from finance, IT, and the implementation team.

For finance teams, these discrepancies can have consequences beyond the migration schedule. Accountants need to establish whether the underlying transactions are correct, whether financial statements remain reliable, and whether the company can complete its next reporting cycle without unexpected problems.

The short answer: The main SAP S/4HANA finance migration risks concern source data quality, FI/CO integration, Universal Journal reporting, custom code, parallel accounting, financial reconciliation, user readiness, and Asset Accounting. Companies can reduce these risks by assessing their existing configuration, resolving mandatory conversion prerequisites, testing accounting scenarios, and establishing clear financial acceptance criteria before go-live.

In this article, we'll focus primarily on converting an existing SAP ERP system to SAP S/4HANA. We'll look at the problems companies encounter, the SAP tools that can help identify them, and the decisions finance teams need to make along the way.

Why SAP S/4HANA Finance Migration Requires Special Attention

Finance migration requirements vary by transition approach. A system conversion retains the existing SAP ERP environment and converts its financial data and configuration, while new implementations and selective data transitions involve different decisions about which data to transfer. For a comparison of these approaches, see our SAP S/4HANA migration, conversion, and transition guide.

For an SAP ERP system conversion, much of the finance work concerns data and accounting logic already in place. SAP S/4HANA uses the Universal Journal to bring financial and management accounting information into a common line-item model. Certain reconciliations between FI and CO become unnecessary, but accountants must still verify the relevant general ledger and subledger information, asset values, and financial reports.

Existing custom reports, posting logic, and ledger configurations also need review. They may depend on accounting structures or settings that behave differently after conversion, even when the underlying financial data has been retained.

The wider SAP S/4HANA migration project brings cost and scheduling pressures. In SAPinsider's 2025 SAP S/4HANA Migration Benchmark Report, 62% of 170 surveyed SAPinsider community members cited high project costs as a migration barrier, while 55% pointed to project duration and 43% to the complexity of existing implementations. The survey, conducted between December 2024 and February 2025, covered SAP S/4HANA migrations generally, rather than finance projects alone.

For finance teams, unresolved accounting problems can add to those pressures. An unexpected balance, incompatible enhancement, or failed migration activity may require investigation, correction, and another round of validation before the project can proceed.

What Happens During an SAP S/4HANA Finance Conversion?

Financial conversion requires preparation before technical installation, migration activities during the conversion, and validation before productive accounting operations resume. These activities overlap in practice, and their exact sequence depends on the source configuration and target SAP S/4HANA release.

The following table shows the main areas of work.

There are important dependencies within these activities. In particular, some Finance migration tasks take place after the technical installation of SAP S/4HANA.

The move from Classic to New Asset Accounting provides a good example. SAP's migration guidance distinguishes between preparation required beforehand and subsequent migration of configuration and transaction data. Planning all Asset Accounting activities as tasks to be completed in ECC would therefore be incorrect.

Eight Common SAP S/4HANA Finance Migration Risks and How to Address Them

Risk #1: Incomplete financial data preparation

An SAP ERP system can operate for years with unresolved data inconsistencies. During an SAP S/4HANA conversion, these issues can affect mandatory checks, financial migration activities, and the subsequent validation of accounting results.

Consider a company whose general ledger and subledger balances do not fully reconcile. Accountants may have established procedures for handling these differences, but conversion preparation can reveal issues that require investigation and, where necessary, correction before the project proceeds.

What needs to be checked?

Start with the accounting records and activities that can affect conversion:

• General ledger and subledger consistency
• Open items, clearing status, and account assignments
• Completeness and consistency of financial master data
• Customer and vendor data required for Business Partner integration
• Applicable period-end and year-end closing activities
• Findings from SAP consistency and conversion checks

Customer and vendor master data deserve particular attention because SAP S/4HANA uses the Business Partner approach. During an SAP ERP system conversion, Customer/Vendor Integration (CVI) must be prepared to synchronize customer and vendor master records with Business Partners according to SAP requirements.

The preparation also needs to account for applicable contact-person records and customer or vendor records marked for deletion. Missing mandatory fields, incorrect mappings, and synchronization errors may prevent the required conversion activities from completing.

For the relevant records, check whether CVI mappings are correct, synchronization errors have been resolved, and the resulting Business Partner records and roles support accounts receivable and accounts payable processes. SAP explains the requirements in its Business Partner and Customer/Vendor Integration documentation.

Which SAP checks can help?

SAP Readiness Check helps companies identify relevant simplification items, custom code dependencies, and other preparation work. It supports project planning but is not itself a mandatory technical conversion check.

The Simplification Item Check (/SDF/RC_START_CHECK) is mandatory for system conversion and checks relevant simplification requirements and system consistency. Software Update Manager (SUM) can execute the check automatically during conversion. SAP also supports a manual execution mode as an alternative to the automatic SUM-triggered check. Once the findings are available, finance and technical specialists can identify which problems require accounting corrections, configuration changes, or other preparation activities. Record the affected objects, assign responsibility, and repeat the relevant checks after remediation.

A conversion rehearsal is a useful opportunity to confirm that corrections have produced the intended results. Problems left unexplained at this stage can become considerably harder to manage when the production conversion is already scheduled.

Risk #2: Misalignment between financial accounting and controlling

SAP S/4HANA brings FI and CO information closer together through the Universal Journal. This affects how certain accounting and controlling relationships are represented, but companies still need correct account assignments, controlling objects, and allocation logic.

Problems can arise when the existing configuration or custom developments do not produce the expected management accounting results after conversion.

Imagine a manufacturer that collects overhead costs by cost center and then allocates them according to established rules. The financial postings may be present in SAP S/4HANA, yet the management reports could show unexpected figures if the corresponding account assignments or allocation logic are incorrect.

The investigation should start with the transactions involved, including the relevant G/L accounts, cost centers, internal orders, profit centers, and settlement or allocation processes.

Preparing FI/CO configuration

Finance and controlling specialists should review the existing relationships against SAP S/4HANA requirements. Primary and secondary cost elements are represented through G/L account master data in SAP S/4HANA, which also matters for custom logic and reporting.

Testing needs to cover business scenarios that generate the relevant postings. It should be possible to establish which accounts and controlling objects were used, whether allocations produced the expected results, and how the transactions appear in management reporting.

When discrepancies appear, examine the source transaction and its assignments before changing a report. Otherwise, a reporting adjustment could conceal a problem in the underlying accounting process.

What about Material Ledger and Product Costing?

Companies managing valuated inventory should also examine Material Ledger and Product Cost Controlling, where applicable. Material Ledger is mandatory in SAP S/4HANA, while Actual Costing remains optional. Companies converting from SAP ERP need to review their existing material valuation configuration, currencies, and inventory-related financial data.

During system conversion, companies need to complete the Material Ledger migration activities and checks applicable to their source configuration and target SAP S/4HANA release. For manufacturers operating multiple plants or using Actual Costing or parallel valuations, these checks should also cover the consistency of material values and the implications for inventory valuation and cost reporting.

Risk #3: Underestimating the Universal Journal's impact on reporting

A company may migrate its financial data successfully and still find that a familiar report no longer produces the same result.

The Universal Journal brings financial and management accounting line items into a common structure, with ACDOCA as its central table. This changes how certain financial reporting dimensions and calculations are represented. After conversion, a report may use different ledger, currency, or account selections than the business expects, producing figures that require explanation even when the underlying accounting data is correct.

Distinguishing reporting differences from data errors

Suppose a management report shows higher expenses after conversion than it did in SAP ERP. The immediate concern may be that something went wrong during financial migration.

Before drawing that conclusion, accountants and developers should compare the reports using the same company codes, ledgers, fiscal periods, currencies, and account selections. They should then examine whether the calculations and reporting definitions have changed. If the underlying journal entries and relevant balances reconcile, the discrepancy may lie in the report's logic rather than in the migrated financial data.

What should happen to existing finance reports?

Identify the reports used for statutory reporting, period-end closing, and management decisions. For each important report, establish the intended accounting definitions, including ledger and currency selections, account scope, and relevant calculations. These definitions provide the basis for comparing reporting results before and after conversion.

Finance users should then confirm whether the reports answer the same business questions in SAP S/4HANA. Some reporting requirements may be met through supported SAP S/4HANA capabilities, while others require adjustments to existing reports. Technical changes to custom developments should be assessed separately as part of custom code remediation.

Risk #4: Ignoring custom code and legacy enhancements

Finance-related custom code can depend on application interfaces, transactions, and data structures that have changed in SAP S/4HANA. Posting enhancements, batch jobs, interfaces, and custom applications need compatibility assessment and, where necessary, remediation.

A technical check may identify incompatible code, but successful execution does not guarantee the correct accounting result. Both the technical dependencies and the business behavior of affected developments need to be tested.

Where should the review begin?

Finance-related developments can include posting enhancements, interfaces with external applications, batch jobs used during closing, and programs that depend on legacy accounting structures.

SAP provides custom code analysis capabilities, including ABAP Test Cockpit and SAP S/4HANA-specific compatibility checks, to help identify developments that need technical investigation.

Usage information is useful too. It can help determine which programs are still active, although finance process owners should confirm whether a development remains necessary for their work.

A practical example

Consider a custom enhancement that assigns accounting attributes to automatically generated postings. Compatibility checks may reveal a dependency on changed interfaces or unsupported logic. A developer updates the enhancement and verifies that the posting process can execute.

Finance then needs to examine the resulting documents. Are the correct accounts and controlling assignments being used? Do the postings support the intended accounting treatment?

These checks matter because technical execution alone does not prove that the enhancement works correctly from an accounting perspective. A useful remediation process moves from code inventory and compatibility analysis to correction and business regression testing. Developments with no remaining business purpose can be considered for retirement once their dependencies have been assessed.

Risk #5: Incorrect parallel accounting and ledger configuration

Multinational companies often maintain financial information for more than one accounting framework. Group reporting may follow IFRS, while local entities need financial statements prepared under national requirements.

Their SAP environments must represent the appropriate accounting principles, valuations, ledgers, and currencies.

During system conversion, companies need to assess whether their existing General Ledger configuration meets SAP S/4HANA requirements. If the source system uses Classic G/L, the conversion includes the necessary migration of accounting data and configuration to the SAP S/4HANA General Ledger. Introducing additional capabilities or redesigning the ledger structure is a separate decision that may require further transformation work.

A standard system conversion does not automatically activate Document Splitting. Historical information held only in classic Profit Center Accounting (EC-PCA) or Special Ledgers may also require separate assessment and migration activities if it is needed in the target reporting model. Companies relying on these structures should verify how profit center balances, segment reporting, and historical financial information will be supported after conversion.

What should be validated?

Consider a multinational company that reports under IFRS at the group level and local GAAP in its subsidiaries. If a transaction is posted to an unintended ledger group, the affected entity may report an incorrect balance under one accounting principle even when its consolidated figures appear reasonable.

Validation should therefore cover the relevant company codes, ledgers, currencies, and accounts individually. A reconciliation limited to consolidated totals may overlook errors affecting local statutory reporting.

Can the company change its ledger design during conversion?

That depends on the existing configuration, target SAP S/4HANA release, and proposed changes. Companies should not assume that a standard system conversion allows them to redesign currency settings, accounting principles, or ledger assignments freely. Certain changes may require separate transformation activities or a different project sequence.

Group accounting, local finance teams, and SAP specialists should review the intended design together. Once the supported approach is established, they can define representative postings and reporting scenarios for testing.

This assessment is particularly important before productive transactions begin. Corrections made after go-live may have consequences for accounting data already recorded.

Risk #6: Weak reconciliation and validation

A technically completed conversion can still leave finance with unanswered questions. Perhaps migration activities finished without a blocking error, but certain open items require investigation. Or the balances match, yet a critical accounting process has not been tested.

A completed technical migration step does not establish that the resulting accounting information is correct. Finance still needs to reconcile the relevant balances, investigate discrepancies, and test critical transactions before the results can be accepted.

What should be reconciled?

Depending on the company's configuration and accounting requirements, the scope may include general ledger and subledger balances, accounts receivable and payable open items, asset values, intercompany transactions, and information used for management or group reporting.

For each comparison, define the relevant date, company code, ledger, currency, and account selection. Material or unexplained differences must be investigated. Any remaining exceptions should have a documented explanation and be reviewed and approved by the responsible finance process owners in accordance with the company's accounting requirements.

This detail can save considerable investigation time. Two reports using different posting periods or currency selections may show different totals even when neither report contains an error.

How to investigate finance migration errors

In applicable SAP ERP to SAP S/4HANA system conversions, transaction FINS_MIG_STATUS helps specialists monitor financial data migration and investigate errors associated with individual migration activities. SAP identifies it as a starting point for troubleshooting in its Finance Migration documentation. When a step fails, review the relevant messages and logs to identify the affected migration activity and accounting objects.

The next step depends on what the error reveals. A failed consistency check may require correcting source data, while another message may point to an accounting configuration issue or a problem during technical processing. SAP Knowledge Base Article 2714344 covers frequently encountered financial migration errors and provides references for further investigation.

Once the cause has been established, the responsible specialists should apply the appropriate correction and repeat the checks or migration activities specified for that scenario. Finance then needs to confirm that the resulting accounting information is consistent, particularly when the correction affects postings or balances.

Keep the original error messages, remediation decisions, and subsequent test results. This record helps the team distinguish resolved issues from findings that still require investigation during later conversion rehearsals.

Who decides whether the results are acceptable?

Finance process owners must review the reconciliation results and approve the treatment of any documented exceptions. Technical specialists provide supporting evidence and investigate system issues, while accounting sign-off remains with the responsible finance owners.

Risk #7: Underestimating the finance process and user readiness

People who have worked in SAP ERP for years usually know how to complete their daily tasks. They remember the transactions they need, the reports they trust, and the steps required during financial closing.

Moving to SAP S/4HANA can affect these established routines. The extent of the change varies: a conversion that retains most existing processes will differ from a project that also introduces new reporting applications, approvals, or shared services. Still, the finance team needs to know what will work differently after go-live.

What changes for finance users?

Depending on the implementation scope, employees may encounter new SAP Fiori applications, different reporting procedures, revised approval flows, or updated access rights.

Responsibilities can change as well. A centralized finance team may take over activities previously performed by local accountants, or the company may introduce common processes across several entities.

Training should reflect these circumstances. An accounts payable specialist needs to understand the procedures involved in processing invoices and resolving exceptions. An asset accountant may have different priorities related to depreciation and period-end work. General SAP S/4HANA training cannot replace preparation for those specific responsibilities.

How to prepare the team

Bring finance process owners and key users into design discussions and testing early enough for their observations to influence the solution. Ask them to complete representative activities, examine the accounting results, and identify steps that need new instructions or approvals. User readiness should be confirmed by having key users perform their assigned transactions independently, with the intended access rights and procedures. The exercise should also show whether they can recognize exceptions and follow the agreed escalation process.

Before cutover, update the relevant work instructions, access rights, and escalation contacts. Where regions retain different accounting procedures, document these differences and explain how they fit the broader operating model.

Plan additional support for the first accounting cycles. Some questions only arise when employees begin processing real transactions under production conditions.

Risk #8: Overlooking new asset accounting requirements

Classic Asset Accounting is no longer available in SAP S/4HANA. Companies still using it in SAP ERP must prepare for the applicable New Asset Accounting migration requirements.

This involves more than checking whether existing asset balances look correct. The source configuration determines which preparatory activities, migration steps, and subsequent checks apply.

One misconception deserves particular attention: companies do not universally have to complete every New Asset Accounting migration step in ECC before installing SAP S/4HANA.

Where do conversion problems occur?

For Asset Accounting, conversion prerequisites can include applicable depreciation calculations, periodic postings, and reconciliation activities. SAP also specifies conditions concerning open fiscal years and relevant currency settings. These requirements need to be checked against the company's source configuration before technical installation.

For systems using Classic Asset Accounting, SAP also requires the Financials Extension (EA-FIN) to be activated before installing SAP S/4HANA, if it is not already active. The new depreciation calculation must be implemented as a separate preparatory workstream. Both requirements need to be addressed before technical conversion.

After technical installation, the migration process includes the relevant Asset Accounting Customizing and transaction data activities. SAP also specifies checks related to journal entries and initial depreciation values.

These steps follow a defined sequence. According to SAP's Classic to New Asset Accounting migration guidance, new Asset Accounting postings can resume after the required migration has been completed successfully.

What should the project team do?

Establish the source Asset Accounting configuration and applicable conversion scenario during the readiness assessment. The migration plan should account for required closing activities, relevant depreciation area and ledger settings, asset values, and the specific checks needed at each stage.

SAP describes activities such as Check Migration of Journal Entries, Calculate Initial Depreciation Values, and Check Initial Depreciation and Total Values. Their applicability and execution sequence must be confirmed against the relevant target release and conversion scenario.

During rehearsals, asset accountants should examine the results and confirm that the required values and postings are consistent with the intended accounting treatment.

How can you validate asset accounting before SAP S/4HANA migration?

Explore common reconciliation issues, depreciation inconsistencies, and the checks required to prepare asset data for conversion.

Read the asset migration guide

How to Keep SAP S/4HANA Finance Migration Under Control

By now, the range of possible problems should be clear. Some are found through mandatory system checks; others become apparent when accountants review transactions or compare financial results. The next challenge is organizing the work so that teams know what needs attention, who can make decisions, and which findings could affect the conversion schedule.

Separate mandatory prerequisites from other findings

Start by separating mandatory SAP conversion prerequisites from findings that require further business or technical assessment. A failed mandatory check can prevent the conversion from proceeding, while other issues may affect reporting, custom processes, or operational readiness without blocking the technical migration. Classifying findings by their consequences helps the team prioritize work and identify risks to the conversion schedule.

Make time for rehearsals and repeated validation

Use conversion rehearsals to test whether the planned sequence, resources, and downtime assumptions are realistic. Findings from each rehearsal should inform the next migration plan, particularly when an issue requires additional preparation or changes to the conversion schedule. Reserve enough time between rehearsals for investigation and remediation rather than assuming that one successful technical run establishes production readiness.

Agree on financial acceptance criteria

Before production conversion, establish the evidence required to approve the financial results. The following examples illustrate project-level acceptance criteria; their final scope depends on the company's accounting requirements and conversion scenario.

A completed technical conversion does not automatically satisfy these criteria. Any remaining exceptions need an accounting justification and formal approval; unexplained material discrepancies cannot be treated as acceptable simply because they fall within a project tolerance.

The SAP Activate methodology provides a broader framework for implementation, testing, deployment, and stabilization. Financial acceptance requirements must still be defined for the company's specific accounting environment.

What Should Finance Teams Validate During Cutover and the First Close?

The final transition to SAP S/4HANA brings its own challenges. Accounting data has to be evaluated at an agreed reference point, critical processes need to resume, and finance must prepare for the next reporting deadlines. This work requires coordination between accountants, technical specialists, integration teams, and the people responsible for the cutover decision.

Establish the financial position at cutover

Before switching productive operations to SAP S/4HANA, confirm which source balances, open items, and other records form the basis for financial validation. A clear cutoff matters because transactions posted at different times can affect comparisons. If the source and target reports use different reference points, the resulting discrepancy may reflect timing rather than incorrect data.

The applicable posting freeze and downtime arrangements depend on the technical conversion approach. Finance should understand which activities are restricted, when postings can resume, and who confirms the relevant results. After conversion, check the agreed accounting information and ensure that the critical finance transactions can be processed.

Check that financial interfaces can resume processing

Financial operations also depend on information exchanged with other applications. Depending on the system landscape, the relevant interfaces may handle bank statements, billing transactions, procurement data, payroll postings, or information sent to external financial systems.

These connections need attention during cutover, even if they passed earlier technical testing. The team should confirm that transactions reach their intended accounting destinations, failed messages can be identified, and support responsibilities are clear.

For example, a bank statement interface might be technically available while imported transactions still encounter posting errors. The cutover checks need to cover the accounting outcome as well as the connection itself.

Prepare for the first financial close

Successful go-live testing does not guarantee that every closing procedure will work correctly in production. Consider a company whose initial financial balances reconcile after conversion, but whose first closing cycle reveals inconsistencies in intercompany transactions. The issue may involve integration timing, account assignments, or differences in how transactions are processed across company codes. Investigating it can require input from local finance teams, group accounting, and technical specialists.

Before go-live, identify the closing activities that need testing and rehearse representative scenarios, with particular attention to those that could affect financial reporting. The first productive close also needs defined support arrangements for investigating discrepancies and resolving issues before reporting deadlines.

Decide what happens if the cutover cannot proceed

The cutover plan should define the conditions that require a pause, escalation, or no-go decision, along with the people authorized to make that decision. The available response depends on when a problem is discovered. Before production conversion begins, unresolved mandatory prerequisites or critical readiness failures may justify postponing the cutover. During technical conversion, the team must follow the agreed escalation and recovery procedures for the affected systems and conversion activities.

Once productive transactions have resumed, the situation changes. The company needs to assess how an incident affects accounting data already recorded in SAP S/4HANA and which recovery or corrective options remain feasible. Returning to the previous environment should not be assumed to be a simple or universally available procedure. The recovery plan should identify the relevant escalation contacts, decision authority, and procedures to be tested before production cutover.

What Business Value Can a Well-Prepared Finance Migration Deliver?

A controlled migration helps a company maintain accounting continuity and enter SAP S/4HANA with financial information that users can verify. It also reduces the likelihood of spending the first weeks after go-live investigating problems that could have been discovered during preparation.

Further improvements depend on what the organization chooses to do with its finance processes. Companies may introduce more efficient closing procedures, improve access to reporting information, or reduce manual reconciliation work.

These benefits require appropriate functionality, process changes, and reliable data. They should be evaluated separately from the technical success of the conversion.

Our guide to finance transformation with SAP discusses opportunities to develop reporting, automation, closing, and other financial capabilities beyond the initial system transition.

How LeverX Supports SAP S/4HANA Finance Migration

LeverX works with companies on SAP S/4HANA transformation projects involving financial processes, accounting data, reporting, and system integrations.

The starting point is an assessment of the customer's existing environment and the work required for the selected migration approach. Finance specialists and technical teams need a shared understanding of which problems could affect conversion and how the business intends to validate the results.

Depending on the project scope, our work can include:

• Finance readiness assessment: Reviewing accounting configuration, data quality, relevant conversion findings, and risks requiring preparation.
• Process and integration assessment: Examining critical finance processes, custom developments, and interfaces that may need changes or additional testing.
• Migration and validation planning: Defining finance-specific activities, reconciliation requirements, test scenarios, and acceptance criteria.
• Cutover and stabilization support: Preparing the transition to productive operations and helping investigate issues during the initial accounting cycles.

A broader transformation program may also involve changes to ledger design, reporting, or established finance processes. Such decisions need to reflect the business requirements and the capabilities supported by the target SAP S/4HANA environment.

Finance process owners remain responsible for accounting decisions and approval of financial results, while implementation specialists handle the corresponding technical work.

Conclusion

Many SAP S/4HANA finance migration problems begin long before the technical conversion. They grow out of accounting configurations, data inconsistencies, and custom processes that have become part of daily operations.

Preparing for the transition means understanding how these dependencies will behave in SAP S/4HANA and resolving the ones that could affect financial reporting or essential business transactions. The quality of that preparation becomes most apparent when accountants begin working in the converted environment, and the company completes its first financial close.

A successful migration leaves finance teams with a system they can rely on, accounting results they can explain, and established procedures for handling the issues that may still emerge after go-live.

FAQ