Simplification Item Check: Fix Return Codes 7, 8 and 12

The Simplification Item Check (report /SDF/RC_START_CHECK) gives every relevant simplification item a return code. Return code 4 is a warning. Return codes 8 and 12 block the conversion, and you have to fix them. Return code 7 also blocks the conversion, but you can either fix it or exempt it in client 000. Fixing it is almost always the better choice, because an exemption means you accept the risk that comes with it, and someone has to sign for that risk.

This guide covers how to set up and run the check, how to read each return code, why SUM can stop on an item that looked "only" like a 7, and how to turn the results into test scope. For where the check fits in the whole program, see our end-to-end ECC to S/4HANA migration guide.

What the SI-Check is, and why you can't skip it

The check has three parts. The Simplification Item Catalog is the single source of truth for simplification items. The Simplification Item Check runs relevance and consistency checks based on that catalog. SAP Readiness Check and the Software Update Manager (SUM) both call it (SAP Community, SAP blog).

A relevance check answers "does this item apply to us?" A consistency check answers "is our data in a state that will convert cleanly?" The Business Partner item is a good example. It counts as relevant when there is data in KNA1 or LFA1, and the consistency check is then done by class CLS4SIC_LO_MD_BP, which is delivered through SAP Note 2502552 (SAP Community).

The Conversion Guide for SAP S/4HANA 2025 (document version 3.0) says this step is mandatory and that SUM triggers it again. Readiness Check is "highly recommended" but optional. The SI-Check is not optional. SUM runs it in two phases: RUN_S4H_SIF_CHECK_INIT during extraction and RUN_S4H_SIF_CHECK_EXEC during preprocessing, before downtime. SAP says this run cannot be skipped (SAP Community, SAP blog).

1. InstallNotes 2399707 and 2502552 (TCI) in DEV, via SNOTE
2. RunRelevance and consistency check as a background job in client 000
3. TriageSort RC 12, 8, 7 and 4 and assign each to an owner
4. Fix and re-runRe-check single items until the blocking errors are gone
5. SUM INITRUN_S4H_SIF_CHECK_INIT during extraction
6. SUM EXECRUN_S4H_SIF_CHECK_EXEC; unexempted RC 7 now stops SUM

Set it up so the results hold

Most "the check is lying to me" tickets come from setup problems, not from the data. Do it in this order:

1. Implement SAP Note 2399707. This note delivers the check report itself. Then implement SAP Note 2502552, which delivers the check classes through transport-based correction instructions (TCI) plus its prerequisite notes (SAP Community, SAP blog). Use SNOTE, and before you start, check that your SPAM/SAINT level supports TCI.
2. Pull the latest note versions every time you re-run. SAP updates both notes often. The check framework is part of the ST-PI component. If you implement a new version of 2399707 after an ST-PI support package upgrade, you can get "not all corrections applied" warnings or syntax errors, and SAP has published fixes for this (SAP Community, SAP blog).
3. Run in client 000 as a background job. Choose the new relevance and consistency check, select your target S/4HANA version, and watch the job in SM37. Check classes read all related data in the system and mostly can't exclude data up front, so on a large ECC box this takes a long time. SAP's runtime advice includes deleting clients you no longer use (SAP Community).
4. Freeze the content before you convert DEV. Before the DEV conversion starts, download the local catalog with "Download Local Simplification Item Catalog". For QAS and PRD, use the transport of the final 2399707/2502552 implementations from DEV (SAP Community). If you skip this, PRD can be checked against different content than the content you tested against.

What each return code means

Return code	Meaning	Blocks conversion?	What you do
0 / grey	Not relevant, or the item has no consistency check (true for most items)	No	Nothing, but still review relevant items for business impact
4 (yellow)	Warning	No	Read the item's note. There may be follow-on work after conversion
7 (red)	Skippable consistency error	Yes, unless exempted	Fix it, or exempt it in client 000 with a documented risk acceptance
8 (red)	Consistency error	Yes	Fix it as described in the application-specific note in the log
12 (red)	Check class not implemented, or the check aborted	Yes	Implement the note named in the log, then re-run

Source: SAP Community, "Simplification Item Check: How to do it right". To see the details, use the "Display Consistency Check Log" button.

Why SUM stops on an item that showed as a 7

The check framework uses return codes 0, 4, 7, 8 and 12. SUM only knows 0, 4 and 8, so it maps them, and the mapping is different in the INIT phase and the EXEC phase (SAP Community; SAP KBA 3141617). In practice, SUM can stop in RUN_S4H_SIF_CHECK_EXEC with a return code 8 on an item that showed only a 7 in RUN_S4H_SIF_CHECK_INIT, because nobody exempted or fixed it in between (SAP KBA 3425038). Teams that read the INIT result as "yellow, fine" find this out during their first mock conversion.

Clearing errors by type

Return code 12

Usually this just means the check class isn't in the system yet. The log names the SAP Note that delivers it. Implement that note and re-run. If the SUM batch job for /SDF/RC_START_CHECK fails with "Target product version and stack cannot be read", look at the stack file before you look at the data (SAP KBA 3046780).

Return code 8

These are real data or configuration problems, and the business has to help fix them. SAP's step-by-step blog points to these notes for the most common cases: 2245333 for Finance pre-transition check messages, 2618023 for FI-AA preparatory checks, and 2679566 for the MM-IM data model (SAP Community). Expect the FI and asset accounting errors to take the longest, because they often mean cleaning up open items, incomplete postings or configuration your controllers have to approve.

Return code 7

Work it the same way as an 8 first. Exempt it only if the item's note says acknowledgment is all that's needed, or if the business owner accepts the documented impact.

Re-checking a fix

When you fix an error, the overview doesn't update by itself. Re-run the check for that one item rather than the full catalog. Being able to do that is one of the things the SI-Check offers that Readiness Check does not (SAP Community). For a check that runs too long, use report /SDF/RC_TROUBLE_SHOOT to run it in the background (SAP Community).

"Skipped because manual check is needed"

Some relevant items get skipped in the consistency check because they need a manual check (SAP KBA 3371146). These items don't show up red, so they're easy to miss. Put each one on your tracker with a named owner.

1. Can the underlying data or configuration be fixed before conversion?Yes → fix it and re-run the single item · No → next question
2. Does the item's SAP Note say acknowledgment is sufficient?Yes → exempt in client 000 and log the acceptance · No → next question
3. Has the process owner read the note and accepted the post-conversion impact in writing?Yes → exempt, and add tests for the impact · No → treat as blocking; escalate to the steering committee

Exemptions are sign-off decisions

SAP's own guidance is to resolve consistency errors where you can, and to use the exemption only when an item really just needs acknowledgment. Once an item is exempt, it no longer blocks the conversion (SAP Community Q&A, SAP answer). An exemption won't make SUM fail, but SAP warns that the underlying issue can still seriously affect the system, and that you accept that effect when you exempt (SAP Community).

Exemptions also apply only to one target stack. If you move your target (say from S/4HANA 2023 to 2025) partway through the project, the exempted 7s come back, and you have to decide on each of them again.

Turn the results into test scope

The SI-Check result is also one of the best scoping inputs your test lead will get. Every relevant item tells you which process changes. Export the overview after each run and keep it with the conversion cycle it belongs to.

• Map every relevant item to the business processes it affects and to the test cases that cover them, using the Simplification Item Test Impact Tracker.
• Turn the follow-on work from return code 4 items into post-conversion test steps, so they aren't left to hypercare.
• For every return code 8 you fixed with data cleanup (open items, asset data, customer and vendor records), add reconciliation evidence to the Data Migration Reconciliation Checklist.
• Re-run the full check before each mock conversion and keep a record of the result in the Mock Cutover Rehearsal Tracker. A clean run in DEV says nothing about PRD data.
• Run the check against a recent production copy. Data-driven errors only show up on production-like data.

Our phase-by-phase migration testing plan shows where these artifacts plug into SIT, UAT and the go/no-go. The same check runs again on every later S/4HANA release upgrade, so keep the tracker. You'll use it again in your post-go-live upgrade regression.

Frequently asked questions

In which client do I run /SDF/RC_START_CHECK?

Run it in client 000, as a background job, with your target S/4HANA version selected. You also set exemptions in client 000. The check still reads data from all clients, so unused clients add to the runtime and can add findings too.

What is the difference between return code 7 and return code 8?

Both block the conversion. You can exempt a return code 7 if you accept the impact described in the item's SAP Note. A return code 8 can't be exempted and has to be fixed. In SUM, a 7 that was never exempted shows up as a blocking error in phase RUN_S4H_SIF_CHECK_EXEC.

Is SAP Readiness Check enough, or do I still need the SI-Check?

You still need the SI-Check. The Conversion Guide lists Readiness Check as recommended and the SI-Check as mandatory, and SUM runs the SI-Check itself. The SI-Check also lets you re-check single items and set exemptions, which Readiness Check doesn't do.

Do exemptions carry over if we change the target release?

No. Exemptions only apply to one target stack. If you change the target release partway through the project, the exempted return code 7 items come back. You'll need to review each one and record a new sign-off.

Sources

1. Conversion Guide for SAP S/4HANA 2025, Document Version 3.0, SAP SE (SAP Help Portal), 2026-10-07
2. SAP S/4HANA Simplification Item Check: How to do it right, SAP Community (SAP blog), originally 2018, updated
3. Simplification Item Catalog, Simplification Item Check and SAP Readiness Check for SAP S/4HANA, SAP Community (SAP blog)
4. S/4HANA Conversion: Simplification Item Check Step by Step, SAP Community (SAP blog), 2020
5. SAP Note Simplification Item Check implementation problems, SAP Community (SAP blog)
6. How exemption works in report /SDF/RC_START_CHECK, SAP Community Q&A
7. KBA 3425038: How to set up exemptions for Simplification Items with return code 7, SAP Support
8. KBA 3141617: Different return codes between Simplification Item Check framework and SUM, SAP Support
9. KBA 3046780: SUM error in phase RUN_S4H_SIF_CHECK_EXEC, SAP Support
10. KBA 3371146: Items skipped for consistency check because manual check is needed, SAP Support
11. Using the SUM Prerequisite Check Extended to prepare your conversion to SAP S/4HANA, SAP Community (SAP blog)