Parallel run in an SAP exit: how a monthly data sync lowers the risk

Your accounting team closes the month in the old SAP system, and the new ERP (Enterprise Resource Planning) system is already running alongside it. Then someone notices that the trial balance doesn't match in the two systems. Nobody knows whether the error lies in the data transfer, in the account mapping, or in a posting that was recorded in only one system. This costs days of follow-up questions, ties up key users and tax advisors, and undermines trust in the new system before it goes live.

Parallel operation only reduces this risk if it is planned: with a fixed reconciliation rhythm, named owners, and an exit criterion that is set in advance. This article shows you how to define these three elements.

What Actually Runs in Parallel

First, clarify what you will maintain in two places. Two variants are common:

• Fully parallel: All postings are recorded in both systems. This is labor-intensive and prone to errors, because users have to enter every transaction twice.
• SAP leading, new system following: SAP remains the leading system. The new system receives the data periodically via import and is checked against SAP.

For most user companies, the second variant is more viable. The departments keep working as usual, and each month the new system is repopulated from SAP and checked.

Decision rule: If your users cannot bear the double workload across several month-end closings, choose "SAP leading, new system following." For each area (sales, purchasing, accounting), check individually when it will switch to the new system. A project that goes live area by area keeps parallel operation manageable for each area.

The Monthly Reconciliation: The Process After Month-End Close

The accountant has closed the month in the SAP system. Now the reconciliation begins:

1. Freeze the data state: Export the balances and documents of the closed month from SAP. From this moment on, this state serves as the reference.
2. Import into the new system: Load the export. With Simplify-ERP, for example, a monthly reconciliation of the SAP data import against the trial balance is carried out; the monthly payroll journal is transferred from the SAP text export to Odoo.
3. Trial balance against trial balance: Compare account by account. Deviations are not a malfunction; they are the result parallel operation exists to produce.
4. Classify deviations: Is the cause an incorrect account mapping, a missing document, a rounding or cut-off date difference, or an error in the import?
5. Fix the cause and re-import: Correct the rule, not the individual number. Otherwise the same error will reappear next month.
6. Document and approve the reconciliation: Record what deviated, why, and who reviewed it.

If a deviation occurs that you cannot assign to one of the classes in step 4, the reconciliation counts as failed, and the following month does not count toward the exit criterion.

Example: Vehicles as a Master Record

A transit operator keeps vehicles in SAP separately as an asset, a maintenance object, and a cost center. In the new system, the vehicle is a single master record that the asset, maintenance object, and cost center refer to. The reconciliation then shows: the total of the assets matches, but individual vehicles are missing from the cost center report. This is a master data mapping problem. It can only be made visible in a monthly rhythm, before real postings run on top of it.

Example: Third-Party Systems That Affect Postings

Sales data from ticket terminals and the statements from the payment service provider must be made available and posted in the new system. In the reconciliation, check whether the revenue from these sources lands in the same accounts in both systems and whether the payment service provider reconciles against the bank account.

Data Sequence: What Moves First

The order of migration determines what you can check in the reconciliation at all:

1. Configuration (chart of accounts, taxes, cost centers)
2. Master data (business partners, assets, items)
3. Balances
4. Documents

A structured approach works in waves and reconciles between the waves. Slyy Migrate proceeds this way: the DART migration (DART is the SAP tool for data extracts for tax audits) runs in waves of configuration, master data, and documents, with a reconciliation report in between. Every account mapping there is a proposal that accounting approves; mappings that have not been approved block loading. Faulty rows are collected as findings instead of aborting the run.

Regardless of the tool, you can adopt the principle: no wave starts until the previous one has been reconciled and approved by the business side.

Define Responsibilities

Without names, the reconciliation gets left undone. Put the following in writing:

• Accounting: checks the trial balance and account mapping and approves the reconciliation.
• Key users per area: check the master data and documents of their area; they will later support the new system in-house.
• IT: delivers exports, runs imports, and resolves technical causes.
• Tax advisor: clarifies questions about the opening balance sheet, account mapping, and data flow to the firm.
• Project management: keeps the log and decides on escalation and the exit criterion.

Check question: Can each deviation class from the reconciliation be assigned to exactly one person? If not, a responsibility is missing.

The Exit Criterion: When Parallel Operation Ends

Define the end before the start, not in a dispute shortly before go-live. A robust criterion consists of several conditions:

• The trial balance matches over several consecutive month-end closings without unexplained deviations. You agree on the number within the project.
• At least one quarter-end or year-end closing run, if relevant for your company, has been replicated in the new system.
• All interfaces to specialist systems (payroll, cash registers, payment service providers, bank) post correctly in the new system.
• The data flow to the tax advisor works.
• The key users have approved their areas in writing.
• A fallback plan is described: What happens if an error occurs after the switchover?

Decision rule: If a condition is not met, extend parallel operation. Do not move the criterion. Take into account the end of SAP ECC standard maintenance: it sets a frame for planning and budget. Clarify in good time how long your maintenance contract runs and what an extension of parallel operation costs.

Typical Mistakes in Parallel Operation

• Correcting individual numbers instead of rules: The error returns with the next import.
• No fixed cut-off date: Both systems contain different states, and the comparison is worthless.
• Documents without master data checks: Faulty partners or assets multiply in the documents.
• Reconciliation by IT alone: Without the business side, it remains unclear whether a deviation is correct from a business perspective.
• Exit criterion by gut feeling: Deadline pressure decides instead of test results.

Your Next Step

Take the trial balance of the last closed month and answer three questions today: Who in your company would reconcile it against a new system? Which deviation classes would you accept, and which not? And which conditions would have to be met for you to switch off SAP? Write the answers on one page. Wherever you cannot enter a name or a condition, you have found your first planning gap.