Source and Verification Policy | S/4HANA 2025 Knowledge Base

In 30 seconds

What it is Every SAP-sourced statement on this knowledge base carries a citation and a verifiedAt date, is re-checked on a six-month cycle, and follows six editorial rules set out in this site's catalogue analysis. This page states those rules as commitments so you know exactly what to trust and what to re-verify yourself.

You use it when You need to know how much weight to put on a fact in this knowledge base, why a page is still marked In review, or what 'verifiedAt' and a supplied transaction code actually promise you.

Guide covers Migration / Start Here

Why this policy exists

This knowledge base makes claims about SAP Fiori apps, transaction codes and S/4HANA capability. Those claims come from a specific, dated export and from named SAP sources, not from general knowledge. This page states the rules that govern how those claims are recorded, cited and re-checked, so you can decide how much weight to put on any one statement.

Two different sources, and why the difference matters

Pages in this knowledge base draw on two things, and they are not the same kind of evidence.

The SAP export is the app list exported from the SAP Fiori Apps Reference Library in September 2026 for product 2025 (Private Cloud). It contains app records and nothing else: App ID, app name, description, UI technology, application component and its description, Line of Business, lifecycle status, backend stack, a transaction code where one is supplied, and the release label. A count derived from those records — 3,185 apps, 20 IS-U apps, 85 Deprecated — is an export fact.

This site’s catalogue analysis is the site owner’s own working document, SAP-Fiori-2025-Catalogue-and-Upgrade-Blueprint.md, which reads those records and draws conclusions from them: interpretation notes, corrections, selection implications, the before / during / after upgrade decisions, the enrichment record structure and the data rules. All of that is editorial. It is never “SAP says,” never “the export says,” and never “the export’s guidance.” The document is not published, so it is named here rather than cited as a reference with a URL.

On a page, the rule follows from that split: a kb-fact block holds export facts only, plus the sentence recording the snapshot date and that it has not been revalidated. Guidance, recommendations and readings of the data sit in prose or in a kb-note, attributed to this site’s catalogue analysis.

The six rules below are themselves editorial: they come from that analysis and from this knowledge base’s own editorial standard.

These rules matter most exactly where the specialist scope is smallest. The September 2026 export lists only 20 IS-U apps and 72 FI-CA and Convergent Invoicing apps for S/4HANA 2025 (see the Utilities and the FI-CA app catalogue pages). Against a catalogue that size, one shortened App ID or one transaction code read as a replacement instead of an association can misdirect a large share of a billing or contract-accounting team’s shortlist, not just a single row lost in a much longer list.

The primary source behind blueprint-backed pages is the SAP Fiori Apps Reference Library export snapshot taken in September 2026 for product 2025 (Private Cloud): 3,185 application records across 668 application components, all eleven source columns preserved, of which 20 records sit in IS-U components and 72 in FI-CA components. The export has not been independently revalidated against the live SAP Fiori Apps Reference Library.

The six editorial commitments

Every page in this knowledge base follows these six rules:

App IDs keep their suffixes. F2596A and F1515_IL_2 are never shortened to F2596 or F1515. A suffix identifies a distinct record.
A supplied transaction code is an association, not a proven replacement. SAP’s export lists a transaction code next to an app because the export supplies that relationship. It is never presented as evidence that the app replaces the transaction.
“Not supplied” is never converted to “No.” An empty field in the source means the export did not supply a value, not that the answer is negative.
“SAP Fiori elements for CoPilot” is a UI technology label, not evidence of Joule support. The label describes how an app was built, not what AI capability it has.
No SAP Note number, release claim or Joule capability is stated without a cited source. If a page cannot cite where a claim like this comes from, the claim does not appear.
Successor relationships are not inferred from similar names or ID suffixes. An app is only called a successor to another app when a cited SAP source states that relationship directly.

These six rules exist because Fiori app catalogues invite exactly these shortcuts: a shared transaction code looks like a replacement, a blank cell looks like a “no,” and a similar app name looks like a successor. On past projects, each of those shortcuts has cost someone a week of rework after go-live. Reading a page here should not require you to already know to be suspicious of the data; the rule is applied before you get to it.

How references and verifiedAt work

Every cited source on a page appears in that page’s references field, with a title, a url, and where relevant a publisher, a version, and a verifiedAt date. verifiedAt records the date this knowledge base last confirmed the source said what the page says it says. It is a freshness marker for this knowledge base’s own citation, not a claim about when SAP last changed the underlying product or document.

The six-month re-verification cycle

Sources are re-verified on a six-month cycle. The repository script check:kb-freshness lists every knowledge base page whose newest references[].verifiedAt is older than 183 days, or which carries no references at all, so a stale citation surfaces before a consultant relies on it.

Review status is separate from sourcing

Citing a source correctly and having project-tested guidance are two different things. Every page in this knowledge base starts at reviewStatus: needs-technical-review, shown as “In review” on the journey map. A page only becomes “Verified” on the map, with a “Technically reviewed” label on the page itself, after the site owner reviews it against live project experience and sets reviewStatus: approved; no page sets its own review date, and no page moves itself out of “In review.”

How to Use the S/4HANA 2025 Knowledge Base — the four callouts and the page shape this policy applies to.
The Fiori 2025 Source Snapshot: Coverage, Gaps and What the Data Cannot Tell You — what the September 2026 export does and does not cover.
Fiori Enrichment Record Template — how gaps in the supplied export get tracked without overwriting the source.

Frequently asked questions

What does verifiedAt actually mean?

It is the date this knowledge base last confirmed a specific source against what that source stated at the time. It is not the date SAP last updated its own documentation, and it is not a promise that nothing has changed since. Treat it as the freshness clock, not a guarantee.

If a page cites a source, is the guidance on that page verified?

No. A citation tells you where a fact came from and when it was last checked; a page's reviewStatus tells you whether the guidance built around that fact has been signed off. A page can cite sources correctly and still carry needs-technical-review because nobody has yet checked it against a live project.

How do I know which pages are due for re-verification?

The repository script check:kb-freshness lists every knowledge base page whose newest reference verifiedAt date is older than 183 days, or which has no references at all. It is run against the repository, not from this page.