Reading the S/4HANA Simplification Item Catalog
A simplification item is SAP's documented record of one specific incompatibility between ECC and S/4HANA, covering business impact, technical impact, relevance conditions, and required or recommended remediation actions. Reading only the title or headline classification is the single most common misreading; the relevance logic and required action detail are usually conditional and change between S/4HANA releases, so a copy pasted from an older project is not reliable evidence for a current one.
This page covers how simplification items are structured, why the same item can look different depending on the target release, and how to read the catalog entries correctly during a system conversion. It focuses on the practical reading discipline an architect needs, not on cataloguing individual items.
Published 16 Sept 2026· 1,376 words
What it is
A simplification item is the unit SAP uses to document a specific incompatibility or mandatory change between ECC and S/4HANA. Each one covers a data model or process change in a given functional area, for example customer and vendor master data being replaced by business partner, or the removal of certain materials management index tables. Every catalog entry has several sub-sections: a business impact description, a technical description, a relevance condition, and a set of required and recommended actions. Most of the confusion around simplification items comes from consultants reading only the title or the business impact line and skipping the relevance logic, which is usually conditional on something in the actual system, such as a configuration switch or a table having entries. The catalog itself is versioned per S/4HANA release. Content behind a given simplification item number can be broadened, narrowed, or retired between releases, so a screenshot or extract taken from an earlier project is not dependable evidence for a conversion running against a later release.
When to use it
Use the simplification item catalog during Prepare and Explore of an ECC to S/4HANA system conversion. The Readiness Check output, which filters the full catalog against the actual system's usage data, becomes the scoping backbone for both the technical and functional teams, and each item on that filtered list should be assigned to a workstream owner. It is also the right tool when reviewing custom code impact ahead of a conversion, and when building the cutover runbook that maps each relevant item to a remediation task. It is the wrong tool for greenfield implementations, where scope should be built from the target process design rather than from a gap list against an ECC system that will not be carried forward. Using the catalog to justify functional design decisions in a new implementation, rather than as a conversion gap list, is a recurring misuse.
How it fits the stack
Above the catalog sits the SAP Activate conversion methodology and the Readiness Check tool, which runs the full catalog against a system's actual usage data and produces the filtered, project-specific list architects actually work from. Below the catalog sit the concrete objects each item points at: dictionary tables, configuration entries, and custom code that reference the old data model. The catalog does not replace functional requirements gathering; it supplements it for conversions by identifying what breaks structurally, not what the business wants going forward. Downstream of the catalog, during the technical execution of the upgrade itself, the actual object-level adjustments are carried out through the standard ABAP Dictionary and program adjustment transactions used in any release upgrade, which handle the object-level conflicts the simplification items only describe at a functional level.
A worked example
An architect scoping a conversion opens the Readiness Check report and finds the business partner simplification item flagged as relevant. Opening the catalog entry, the business impact section states that customer and vendor master data is merged into the business partner model. The technical description states that the customer/vendor integration conversion becomes mandatory and that direct dependency on the old customer and vendor master tables is no longer supported going forward. The relevance condition explains that this item triggers because the system holds customer and vendor master records that have not yet been linked to a business partner. The required action points to running the business partner conversion cockpit; the recommended action flags data cleansing of duplicate or incomplete master records before conversion. The architect then cross-checks the custom code impact list for any custom reports or interfaces reading the old master tables directly, since those will fail after conversion even though the catalog entry itself does not enumerate them by name. That cross-check, not the catalog entry alone, produces the real remediation task list.
How to choose
- Trusting the automatic relevance flag versus manually verifying it: an item marked not relevant means the detection condition was not met in the system scanned, usually a sandbox or a copy with thin data; if production holds records the sandbox does not, the flag can be wrong and needs a manual second look before it is closed out.
- Reading the full item text versus the headline mandatory/optional tag: the tag is a convenience label, the actual scope and exceptions live in the technical description and relevance condition, and teams that scope off the tag alone routinely miss conditional exclusions or partial applicability.
- Matching the catalog version to the target release, not the source release: the item text an architect should be reading is the one published for the S/4HANA release the system is converting to, since content behind the same item number shifts across releases.
- Cross-referencing the custom code check output against each item's required action: the catalog describes the standard object change, not which custom objects reference it, so the two lists have to be reconciled manually or the remediation backlog will understate the real effort.
- Sequencing dependent items: some items cannot be closed until a prerequisite item is resolved, and this dependency is not always spelled out in the catalog cross-references, so the sequencing has to be worked out by the architect rather than assumed from list order.
Common pitfalls
- Treating the filtered simplification item list as a complete technical gap analysis; it covers standard object incompatibilities, not custom-code-only breakages that never touch a standard table the catalog checks for.
- Copying item text into project documentation early and never refreshing it; the catalog content for a given item number can change scope between the release checked at project start and the release actually installed at go-live.
- Reading a not relevant flag as no impact rather than as no automatic detection; a table empty in the checked system but populated in production will flip the real-world relevance without changing the report.
- Assuming the required action fully covers the business process change; the catalog documents the technical remediation step, not organisation-specific configuration or process redesign that the same change forces further downstream.
- Missing dependencies between items where resolving one changes the relevance or scope of another; the catalog does not always make this cross-linkage explicit, and teams that work the list in isolation rework the same object twice.
ECC, S/4HANA and clean core
The simplification item catalog exists specifically for the ECC to S/4HANA conversion path; it has no direct equivalent for greenfield implementations, where there is no prior system to check against. It intersects with clean core indirectly: the moment custom code is flagged against a simplification item because it references an object the item retires or restructures, that is also the natural decision point for whether the code is rewritten against a released API or CDS view instead of being patched to keep working against the new data model. Direct table access patterns that the catalog flags are now generally discouraged in favor of released interfaces, without this page asserting a specific release number for when that guidance took effect.
Whose problem this is
The architect owns overall review and sequencing of the filtered item list and its dependencies. Functional consultants own the business impact and required action detail within their module. Developers own remediation of any custom code flagged against an item. The handover artifact is a spreadsheet mapping each relevant item to a workstream owner, plus the custom code worklist with remediation status against it.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/simplification-items-and-how-to-read-themERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.