What is the SAP Simplification Item Check, and why does it stop an S/4HANA conversion?

What the SI-Check actually is, and what it is not

S/4HANA is not a new release of ECC. It removed, merged, or replaced a long list of functions and data structures, and SAP documents every one of those changes as a simplification item: a numbered entry in the Simplification List with a description, the affected application area, the SAP Note that explains the change, and the action a customer must take. The Simplification Item Check is the program that walks that list against a live ECC system and tells you which entries apply to you and whether your data is ready for them.

It is one of three pre-conversion instruments that projects routinely confuse. The SI-Check tests functional and data preconditions. The custom code check, run through the ABAP Test Cockpit with the S/4HANA readiness variant, tests your ABAP against the same simplification items and is a separate exercise. The SAP Readiness Check is the analytical dashboard that consumes the output of both, plus usage statistics and sizing, to give management a picture. Only the SI-Check has teeth: its errors are what the Software Update Manager will refuse to proceed past.

How it runs: relevance first, then consistency

The check is delivered by SAP Note 2399707 (the framework) and SAP Note 2502552 (the check content, which SAP updates continually, so the note must be reapplied before each run), and it depends on a current ST-PI add-on. You execute it with report /SDF/RC_START_CHECK in the source system, selecting the target S/4HANA release, and it produces a results list you can revisit and re-run.

The first pass is the relevance check. Each simplification item has a relevance rule: does this system use classic credit management, does it have vendor master records without a business partner, does it run SD foreign trade, is there a material number longer than the old limit anywhere in the data. Items whose rule matches are marked relevant; the rest are filtered out, which is what makes the results specific to your estate rather than a copy of the Simplification List.

The second pass is the consistency check, and it runs only against relevant items. It tests the data preconditions each item defines and returns a finding with a severity. Warnings are informational and do not block. Errors mean a precondition is not met and the conversion will not proceed until the condition is fixed in the source system or, where the specific check class allows it, an exemption is recorded with a justification. Exemptions are not a loophole: SAP restricts which checks may be skipped, and the exemption is logged.

The findings that actually stop conversions

Most of the several hundred simplification items are informational for a given estate. A handful account for nearly all the errors that stall a SUM run, and every one of them is a business-process change wearing a technical label.

• Business Partner and Customer-Vendor Integration. In S/4HANA the business partner is the leading object and every customer and vendor master record must be synchronized to one before conversion. The SI-Check counts the unconverted records; the fix is the CVI project, which is data cleansing work measured in weeks, not a configuration switch.
• Financial data consistency. The move to the universal journal (ACDOCA) requires that FI, CO, and asset accounting totals reconcile in the source system. The check runs reconciliation reports and raises an error on differences, because migrating inconsistent balances would produce a ledger nobody can close. Clearing these often means resolving postings that were tolerated for years.
• Classic asset accounting. New asset accounting (EA-FIN) is mandatory in S/4HANA, and if the source system still runs the classic version the check flags it. Activating new asset accounting in ECC is itself a mini-project with its own period-close constraints.
• Add-ons and business functions without an S/4HANA equivalent. Any installed add-on that is not certified for the target release, or an activated business function that S/4HANA does not support, is a hard stop until it is uninstalled or the vendor delivers a compatible version.
• Functional replacements: classic credit management to FSCM Credit Management, SD foreign trade to GTS or the S/4HANA international trade functions, SD rebates to settlement management via condition contracts. Where the source data depends on the old function, the check demands the migration step be done or planned according to the item's note.

Why the check belongs at the start of the project

Run in the last month before cutover, the SI-Check is a list of surprises with no time to absorb them. Run in the first month, it is the most honest process-change inventory a migration can get for free, because every relevant item is a place where S/4HANA does something differently and the business has to decide how to respond. The CVI finding is really a question about master data ownership. The credit management finding is really a question about whether the credit policy encoded in a user exit survives the move to FSCM. The rebate finding is a question about how sales agreements will be settled.

This is where the SI-Check meets fit-to-standard work. On a reference estate, a live ECC system we use to validate the method rather than any customer's result, the relevant simplification items line up closely with the custom objects that a fit-to-standard analysis flags for retirement, because both are reading the same underlying fact: the business implemented a rule in ECC that S/4HANA now delivers as standard. Reading each relevant item alongside the custom code and configuration that sits behind it turns a technical error list into a set of process decisions with owners. A customer's findings come from their own system.

That reading is exactly the kind of work an agent can prepare. The relevance rules are queries against live tables; the affected custom objects are a where-used question; the business rule inside each object is a source read. Our agents perform those reads through governed, read-only tool calls against the live system and attach the evidence to each simplification item, so the process owner sees a decision rather than a note number. Where the decision is target configuration, the agent drafts a governed customizing transport and the customer's change board decides whether it lands; development systems only, never touching production on its own. A functional-testing agent that would prove each replaced function handles the volume the old one carried is in build and design preview, not shipped.

A working sequence

Apply the current versions of the two SI-Check notes and confirm ST-PI is at a supported level. Run /SDF/RC_START_CHECK for the target release in a recent production copy, not the development system, because the consistency checks are about production data. Export the results and treat the relevant-item list as the backbone of the process-change register. For every error, name a business owner and a resolution path before anyone estimates the technical effort. Re-run the check monthly as CVI, finance reconciliation, and functional migrations progress, and again on the actual production system before each SUM rehearsal. By the time the conversion runs, the check should be confirming a state the project already knows rather than discovering one.

SAP's own direction points the same way. The agent-led transformation capabilities SAP announced at Sapphire 2026, with a stated reduction of more than 35% in migration effort (SAP News), automate the analysis and remediation layer that the SI-Check feeds. Whether a customer takes that path inside RISE with SAP or runs comparable agentic tooling on their own S/4HANA estate on AWS, the check itself does not change: it remains the list of what S/4HANA will require of the business, and the sooner it is read as such, the cheaper the migration is.