SAP Data Readiness for AI

SAP data readiness for AI means that a defined set of SAP business records can be extracted through an appropriate supported route, interpreted correctly and used by the intended people for a specific task. It does not follow from the presence of an SAP connector or a large historical dataset. The assessment must preserve business-document relationships, organisational scope, units, status meaning, timing and the difference between a record and a completed business event.

This guide focuses on a hypothetical SAP S/4HANA customer-returns review assistant for a Saudi distributor. The assistant prepares a factual returns-status brief for authorised staff. It does not approve refunds, post goods movements or change accounting records. The example makes data prerequisites concrete within an enterprise data and AI readiness assessment while keeping SAP ECC, S/4HANA editions and other SAP products distinct.

Name the SAP product and business object precisely

Record the product, edition, release, deployment and business process involved. “Our data is in SAP” does not establish whether the available interface belongs to SAP ECC, S/4HANA on-premise, S/4HANA Cloud Private Edition or S/4HANA Cloud Public Edition. A view or API documented for one context should not be assumed available in another. Ask the application owner to identify the actual interface and its supported use.

Then define the business object. A customer returns request, a returns delivery, a goods movement and a financial adjustment are related records with different meanings. A general status brief may need several of them, but the assessment should not assume that one document’s status proves the completion of the whole returns process. Map the intended question to the object that can actually answer it.

Keep the first use narrow enough to assess. For example, “summarise the recorded delivery and inspection evidence for specified return items as of the stated snapshot” is more tractable than “manage returns.” The latter may imply eligibility decisions, customer communication and financial actions that require additional authority and operational evidence beyond the data assessment.

Verify the extraction capability, not just the view name

SAP’s S/4HANA Cloud Public Edition data-integration documentation explains that only a subset of CDS views supports extraction and distinguishes full from delta capabilities. Verify the selected view, release and communication route in the actual environment. A readable view does not automatically establish that the planned consumer can use it as a supported incremental data source.

Request the interface specification, enabled capability, authentication principal, authorised scope and operational owner. If the proposed source is a custom view, document its joins, filters and derivations as well as its technical availability. “Custom” does not mean unsuitable, but it does mean that the organisation needs evidence of what the view represents and who maintains that meaning when upstream structures change.

Separate an initial full load from the ongoing update path. The full load may support a static assessment while the delta path remains unresolved. State that limitation rather than describing the dataset as continuously current. Record how corrections, reversals and deletion-related events reach the consumer and what evidence confirms that an interrupted extraction can resume without losing or duplicating business changes.

Map the returns question to an evidence chain

Illustrative evidence map for a read-only returns-status brief

Business question	Evidence to identify	Inference to avoid
What did the customer request to return?	Authoritative request item, quantity and unit	Treating the request as physical receipt
What was recorded in a returns delivery?	Applicable delivery and item relationship	Treating a header status as every item’s final outcome
What was received or reversed?	Defined movement events and reversal relationships	Adding all events without their direction or status
What was accepted after review?	Approved inspection or disposition evidence for the task	Equating warehouse presence with acceptance
What financial action is confirmed?	The relevant authorised financial record, if in scope	Inferring a refund from delivery completion

The exact sources depend on the customer’s configured process and supported interfaces. The table is a business mapping exercise, not a claim that one CDS view exposes all these fields. Ask process owners to identify the authoritative object and relationship for each answer. If an inspection decision sits outside SAP, make that boundary visible rather than silently filling the gap from a delivery status.

The source authority and meaning assessment provides a framework for resolving which event governs a statement. In this SAP-specific task, the useful evidence is a signed-off field and relationship map that a functional owner can explain. A technically successful extraction is insufficient if the business team disagrees about what “returned,” “received” or “accepted” means.

Preserve header, item and event grain

State what one row represents before joining data. A delivery header, delivery item and movement event have different grains. Joining a header to several items repeats header attributes; joining items to several events can multiply rows again. An AI assistant using the resulting dataset may produce confident totals even when the duplication was introduced upstream.

For an illustrative check, suppose a header records a gross weight of 18 kilograms and has two items. A flat join produces two rows carrying the same header weight. Summing that repeated field gives 36 kilograms, which is not a new physical measurement. The correct treatment depends on the intended measure: keep the header-level fact once or use legitimate item-level measures where available, rather than dividing arbitrarily.

Preserve compound identifiers and source-system context. A document number without its system, client or relevant organisational boundary may not be globally unique in a multi-system landscape. Do not merge records merely because their display numbers match. Record join cardinalities and unmatched keys, and have the functional owner review unexpected one-to-many or many-to-many relationships before admitting the flattened dataset.

Read SAP status fields in their actual scope

The documented S/4HANA on-premise Customer Returns Delivery Document view, I_CustomerReturnDelivery, includes distinct delivery-related status attributes and requires shipping-point display authorisation. Its documentation also identifies extraction capabilities. These details apply to that documented view and release context; they do not establish the behaviour of every SAP returns interface or downstream extractor.

For the assessment, build a status dictionary for the fields actually consumed. Include the source code, business label, object scope, allowed transitions and any “not relevant” or initial state. Ask whether a completed header status can coexist with a partial or exceptional item state in the intended process. Preserve unknown values instead of mapping every unfamiliar code to a convenient success label.

Separate a status description from a recommendation. “The delivery-related process status is recorded as complete” is narrower than “the customer should receive a refund.” The latter requires additional evidence and a permitted decision process. The assistant’s output contract should use language that stays within the records assessed, including the date and any unresolved item-level exceptions.

Worked return: quantities belong to different stages

Consider a synthetic return item with eight units requested, five units recorded as received and an inspection record showing three accepted units while two remain under review. The assistant should report these as different stage-specific quantities. It should not say that eight units were physically received, that all five were accepted or that three units were financially credited without the corresponding evidence.

Now consider another item requested as two cartons, with a documented conversion of six units per carton for that material and context. One carton has been received. The received quantity can be represented as six units under that approved conversion, while the requested quantity is 12 units. Preserve the original quantities and units alongside any derived form. Do not use a conversion borrowed from another material or packaging version.

Do not add quantities from unrelated materials into a misleading “units returned” total merely because both can be expressed as units. State what the aggregate is intended to mean and whether it is useful for the task. The assessment should test the assistant’s ability to keep item identity, quantity basis and stage together, rather than judging only whether the arithmetic is numerically correct.

These figures are illustrative, not SAP field defaults or a client result. Their purpose is to expose the evidence the proposed brief needs. If the chosen extraction cannot preserve the stage and unit relationships, the next step is to repair the data contract or narrow the output, not to ask the model to infer the missing distinctions.

Handle reversals and late changes explicitly

A recorded movement can later be reversed or corrected. Define whether the assistant reports gross events, net recognised movements or the current process state. Those are different measures. In a simple illustrative event set, a receipt of five units followed by a valid reversal of two units yields a net three under the agreed event definition. Summing absolute event quantities would produce a different and misleading result.

Preserve the link between the original event and its reversal, along with relevant dates and status. A negative number alone may not explain the business event, and a missing reversal can make a historical snapshot appear current. Test an authorised synthetic correction through the extraction path and verify that the downstream representation changes as expected. Record the latency and any manual reconciliation step.

Distinguish business-effective time, posting time, extraction cut-off and downstream availability. A brief requested at 10:00 cannot rely on a movement first recorded at 10:20 unless it is explicitly a later reconstruction. The as-of and temporal data assessment develops this boundary for historical and predictive tasks. Even a descriptive assistant needs a clear statement of the time its evidence represents.

Reconcile a sample across source and consumer

Proposed SAP returns-data reconciliation protocol

Check	Evidence	Unresolved result
Object population	Eligible document and item identifiers under the agreed cut-off	Missing or extra records require selection-rule review
Relationships	Header-to-item and item-to-event links	Unexpected multiplication or unmatched keys blocks affected summaries
Quantities and units	Original values, conversion rules and derived values	Unknown conversion remains unconverted
Status interpretation	Owner-approved dictionary and exceptional examples	Unmapped code remains an explicit unknown
Change propagation	Controlled correction or reversal observed downstream	Stale representation needs an owned refresh remedy
Permitted scope	Allowed and denied test identities and records	Unenforced boundary prevents that pilot scope

Use a representative selection mechanism if the aim is to estimate data-quality prevalence. Use a separately labelled challenge sample to inspect partial returns, reversals, mixed units and exceptional statuses. Report which purpose each sample serves. A handful of familiar documents chosen by the implementation team can explain the process but cannot establish that all business units or periods share the same quality.

Reconcile with the authoritative SAP view or report under a comparable identity and time boundary. Differences may result from access filters, reporting logic or extraction timing rather than a simple missing row. Preserve the comparison conditions. The data quality assessment helps define denominators and exclusions so the reconciliation does not turn into an unexplained percentage.

Test the extraction identity and the assistant audience

The source extraction principal may have broader access than the people using the assistant. Identify which organisational dimensions and record attributes are needed to narrow downstream retrieval. Do not assume that SAP screen permissions automatically apply to an exported dataset or a separate search index. The actual enforcement point must be visible in the architecture and in the test evidence.

Use authorised synthetic cases to show that a permitted user can retrieve an in-scope return while an out-of-scope record remains undisclosed. Include snippets, citations and cached summaries in the check. If the dataset lacks the attributes required to enforce the approved boundary, treat that as a prerequisite gap. A prompt asking the model to respect business-unit boundaries is not a substitute for access enforcement.

Keep read access distinct from action authority. A user allowed to inspect return evidence is not automatically allowed to post a movement, change a disposition or approve a financial action. Any future write capability needs the separate action-readiness assessment, including validation and independent confirmation in the target system. This page’s data conclusion should not imply that those actions were tested.

Preserve Arabic labels without changing SAP keys

Saudi teams may ask in Arabic while source field labels, product descriptions or process documentation are in English. Provide a reviewed business glossary for the intended brief, particularly for requested, received, accepted, reversed and credited states. These terms should not collapse into one Arabic word for “completed.” The language layer must preserve the distinctions established by the functional owner.

Keep technical identifiers and source codes stable even when display labels are translated. A translated shipping-point name or product description is not a new key. Where multiple language texts exist, record how the application selects a display value and what it does when a translation is missing. Test mixed Arabic questions containing document numbers and material identifiers.

Review the generated brief against the structured evidence, not just for grammatical fluency. A natural Arabic sentence can still incorrectly imply physical receipt or financial settlement. Include source references and the as-of boundary so a reviewer can verify the claim. If the required explanation cannot be expressed without unresolved ambiguity, narrow the brief until the source meaning is settled.

Assess a mixed snapshot before accepting a complete brief

A brief can combine a fresh delivery extract with an older inspection file. Each component may have completed its own pipeline successfully, while the combined statement describes no single consistent business point in time. Record the cut-off and availability of every contributing source. Decide whether the task permits an explicitly dated combination or requires the sources to be reconciled before the assistant presents a consolidated status.

Use a controlled example where the delivery record changes before the inspection feed arrives. The expected behaviour may be to show both dated observations and state that the inspection information has not yet caught up. It should not silently treat the missing update as rejection, acceptance or zero quantity. The source owner should define the permitted interpretation of an absent related event and distinguish it from an extraction error.

Test recovery after one extraction fails. A successful rerun of a single feed should not cause the consumer to mix old and new records without preserving their provenance. Record how the pipeline identifies accepted snapshots and how the application knows whether a combined brief is complete enough for the task. This is a data-readiness dependency even when the individual connectors are working.

Revisit the contract after a release or extension change

Maintain a small, owned set of semantic regression cases covering partial returns, reversals, units and permission boundaries. Re-run the relevant cases when a source release, custom extension, extraction definition or status mapping changes. Technical compatibility does not independently prove that the downstream interpretation remains correct. Ask the functional owner to confirm any changed meaning and preserve the previous assessment boundary so the new evidence can be compared with it.

Keep assessment findings separate from delivery commitments

A useful readiness decision identifies the SAP context, approved objects, supported extraction route, tested population, field semantics, access boundary and evidence date. It says whether the dataset is suitable for an exploratory analysis or a controlled read-only assistant, and which unresolved issues prevent broader operation. It should not certify the whole SAP landscape or promise that every historic record is AI-ready.

Estimate remediation by named dependencies rather than a generic connector installation. A missing unit conversion owner, unsupported delta route or disputed status definition can matter more than moving data. Assign each issue a responsible team and an observable completion condition. The assessment remains a decision about prerequisites; implementation and ongoing operation require their own scope and acceptance evidence.

Discuss SAP data readiness for AI with Open for AI using a masked process description, the exact SAP edition and release, candidate interface documentation and examples of normal and exceptional records. The discussion can establish which data relationships already support the intended brief and which require further evidence before a bounded pilot. It should preserve the business meaning that makes SAP records useful in the first place.