The S/4HANA Reconciliation Decision: Inside SAP or on an External Platform

A UK-headquartered group consolidating its ERP estate onto S/4HANA is making architecture decisions that will hold for the next decade. Most of them are deliberate and well governed. One that often slips through by default is where financial reconciliation runs once the migration settles, and where the financial data it works on actually lives.

The migration is the moment that choice is cheap to make and expensive to defer. Reconciliation either gets designed into the target architecture, or it gets bolted on afterwards once the programme has moved on and the budget has closed.

Two places reconciliation can run

For a multi-entity SAP group, there are two broad models.

One runs reconciliation on an external cloud platform. The platform extracts general ledger, sub-ledger and transaction data from SAP on a schedule, reconciles it in its own cloud, and posts the results back. It is a separate system with its own data store, its own access model, and its own connection to SAP.

The other keeps reconciliation inside SAP as a certified add-on. The matching logic runs within the existing SAP boundary, against data that never leaves SAP’s security and authorisation framework. There is no second copy of the financial data and no separate platform to connect.

Both clear the same items at the end of the day. The difference is everything around the edge: where the data sits, who can see it, how many systems the auditor has to follow, and what happens at the next release.

Should SAP reconciliation run inside SAP or on an external platform?

For a group already standardising on SAP, keeping reconciliation inside SAP avoids a category of repeated work that an external platform creates. An in-SAP add-on uses the SAP logins and authorisations the team already holds, keeps the full audit trail in one system, and travels with each entity as it migrates to S/4HANA. An external platform adds a second data location to secure, a separate residency position to defend in each country, and an integration to re-validate at every S/4HANA release. The external route can still be the right one where a group reconciles across many non-SAP systems, but for an SAP-centric finance estate it solves the same problem with more moving parts.

What the external route costs a multinational

The cost of the external model is not in the licence. It is in the work that repeats.

Data residency repeats by country. When SAP data is copied to an external platform, the group has to answer where that copy sits and under whose rules, separately for each jurisdiction it operates in. An entity in Germany and an entity in Poland are different conversations, and each one is reopened when the platform or its hosting changes.

The security review then runs twice. A second platform holding financial data is its own thing for internal security and external auditors to assess, with its own access paths to grant and revoke. Every joiner and leaver now touches two systems instead of one.

Integration re-validation repeats by release. The connection between SAP and the external platform has to be tested again at every S/4HANA upgrade, and re-established for every new entity brought onto the platform. A programme that runs for years and migrates entity after entity pays that cost each time.

None of these is fatal on its own. Together, across dozens of company codes in several countries, they become a standing maintenance load that grows with the estate rather than shrinking as the migration was meant to deliver.

The cross-entity work standard SAP still leaves manual

Underneath the platform decision sits a gap standard SAP does not close on its own, whichever route a group takes.

Standard SAP has no automatic clearing of open items across company codes. The automatic clearing program operates within a single company code, so cross-company items are cleared by hand or routed through intercompany accounts that someone configures and maintains. At a handful of entities that is a minor recurring task. Across dozens of company codes it becomes a fixed manual load on every close, and it is usually the last thing to agree before the group can consolidate.

Standard SAP also has no supplier statement reconciliation. The same global supplier is reconciled separately by each country team, in its own format and currency, with no shared record. The work multiplies with every entity that trades with that supplier.

Both are the kind of high-volume, rules-based matching that belongs inside the system of record rather than on a copy of it. Solving them in SAP means the result posts through the same documents and authorisations the team already uses, and the evidence sits where the auditor already looks.

Where BEST fits the consolidation path

BEST is a specialist SAP add-on vendor. Its reconciliation modules are SAP-certified and run inside SAP, using existing SAP logins and authorisations, with the full audit trail held in SAP and no data duplicated to an external system. The company is ISO 27001 certified for information security.

The certifications map to the consolidation path itself. BEST holds SAP certification for the S/4HANA Cloud Private Edition Add-On for RISE with SAP, certificate #22988, which is the deployment model most large UK groups are migrating into. It also holds certification for the SAP Business Technology Platform integration scenario, certificate #25513, alongside its NetWeaver 7.50 ABAP add-on certification, #21468, for estates still on ECC. A group part-way through migration runs both worlds at once, and the capability is certified for both.

Two modules carry most of the multi-entity weight. Open Item Clearing automates the clearing of open items across multiple company codes and account types, the gap standard SAP leaves at the seams between entities. Vendor Recons reconciles supplier statements against accounts payable inside SAP, which standard SAP has no native function to do. Both run inside the SAP boundary, so neither adds a second data location or a separate integration to maintain.

What to decide before the migration locks

Once the S/4HANA programme finishes and the finance architecture is locked around it, moving reconciliation from an external platform back inside SAP becomes a project in its own right rather than a design choice. The cheap moment is during the migration, not after it.

The decision worth making deliberately is whether reconciliation belongs inside the SAP boundary or alongside it. Keeping it SAP-native means the residency, security and integration questions are answered once and travel with the migration, rather than being reopened for every country and every release.

If a consolidation programme is live or being scoped, the two module pages worth reading against your own company-code map are Open Item Clearing for cross-entity clearing and Vendor Recons for multi-country supplier statements. A short technical walkthrough against your estate is the quickest way to test the fit: book a demo.

Sources: SAP Help Portal (automatic clearing, program SAPF124); BEST module pages (Open Item Clearing, Vendor Recons) and the BEST SAP certification register (#22988 RISE S/4HANA Cloud Private Edition, #25513 BTP, #21468 NetWeaver 7.50 ABAP add-on).