Ingesting SAP ERP Data Into a Knowledge Graph

SAP ERP data is spread across records, business rules and custom workflows. Connecting an AI model to those records is only part of the job. The model also needs to understand how a purchase order, supplier, payment term and cost center relate, and which source supports each answer. A knowledge graph can make those relationships explicit.

Relational databases store both records and relationships through keys, constraints and joins. But the complete business meaning often spans several systems, custom code and process documents. For example, a payment term, purchase order and cost center may be linked in the database while the reason for an exception remains in an email or a controller’s experience. Graph modeling brings those sources together in a shared business model.

An LLM needs more than a list of table names to answer business questions reliably. Vector search can retrieve relevant passages; a graph can expose relationships between records, policies and events. Neither technique alone proves that one event caused another. If a project delay appears alongside a margin decline, the system still needs evidence before presenting the delay as the cause.

What a knowledge graph adds to SAP data, and what it does not replace

A knowledge graph's real contribution is the ontology beneath it: a formal model that fixes standardized terms, hierarchies, and rules across the business, so "customer" means the same thing in finance as it does in sales, and "delivery date" isn't three different fields depending on which module you're in. That ontology is what makes the graph legible to a person and a machine at the same time, rather than just something a query engine can chew through.

One common graph format is RDF, which expresses facts as subject–predicate–object triples: “Purchase Order 4500123 references Vendor 100234.” Property graphs are another option. In either approach, record the source and validity of each relationship. A stored edge may come from a verified record, a rule or an inference; those are different kinds of evidence.

A vector database finds items with similar meaning. A knowledge graph records explicit connections between things. Think of the first as finding relevant pages and the second as following the links between the people, orders and policies on those pages. Traceability requires the system to retain sources and retrieval steps; a graph does not supply that automatically.

Vector and graph retrieval can work together. Compare each approach on representative business questions, measuring answer quality, traceability, response time and operating cost. Use the combination that improves the workflow.

A graph does not repair incomplete, stale or contradictory records by itself. Resolve conflicting supplier identities, outdated policies and missing fields during ingestion, and preserve unresolved uncertainty in the graph. Otherwise, a well-structured answer can still be wrong.

SAP's native graph architecture in HANA Cloud and its implications for ingestion design

Ingestion design starts with where the graph will run and how it will stay current. An external graph service requires a supported path for extracting data or metadata and a plan for synchronization. A native graph capability may reduce some data movement, but its supported sources and operations still need to match the workflow.

SAP’s Q1 2025 release highlights describe native RDF storage and SPARQL querying in SAP HANA Cloud’s knowledge graph engine, alongside support for graph-based retrieval-augmented generation. This gives teams a documented option for querying graph data within HANA Cloud. Check the supported query and integration features for the deployed release.SAP release highlights.

Keep the products distinct when planning an implementation. SAP HANA Cloud’s knowledge graph engine is a database capability; SAP Knowledge Graph, SAP Datasphere and SAP Business Data Cloud have their own roles, interfaces and release status. A capability announced for one product should not be assumed available in all of them.

Mapping SAP's table structure to a graph ontology, the core modeling decisions

Start with supported business views and metadata before extracting raw tables. SAP Core Data Services (CDS) views can carry semantic annotations and associations that help describe business entities. Use those definitions where available, then validate them against the customer’s custom fields and processes.

Deciding which connections become edges in the graph is harder. Foreign keys are the obvious first signal, and they'll get a modeling team most of the way to a usable skeleton. But plenty of business-critical relationships were never encoded as a foreign key. They live in a custom function module that runs during document posting, or in a process document sitting on some internal document-sharing site, describing a workflow nobody ever normalized into the schema.

For example, a billing document may relate to a delivery through document-flow records and intermediate objects. Verify the actual path for the relevant SAP process before turning it into a graph relationship. A business owner should confirm that the modeled relationship means what the workflow assumes it means.

Ingestion patterns, how SAP data physically moves into the graph

Use metadata to define the graph, then choose how to load and refresh business records. These are complementary steps rather than three interchangeable ingestion methods.

Metadata-first ingestion reads definitions and associations before loading transactional records. This lets the team validate the model on a small sample and catch mismatched meanings early.

Batch ingestion loads records on a schedule through supported data products, exports or connectors. It suits workflows that can tolerate a delay between a source update and its appearance in the graph. Confirm the objects and refresh options available in the relevant SAP service.

Change data capture (CDC) updates the graph as source records change. It is useful when operational decisions need fresher data. Plan for deletes, replay, schema changes and missed events, and compare the operating cost with the freshness the workflow actually needs.

Non-SAP integration is a product-specific question. SAP Datasphere documents connections to SAP and non-SAP sources, including cloud and on-premises systems. Supported operations differ by connection type. Check the required sources, objects, access method and refresh rate for the workflow rather than relying on an old roadmap date.SAP connection documentation.

Master data quality belongs in the ingestion plan. Resolve duplicate Business Partner records, incomplete material records and conflicting hierarchies before they distort graph relationships. SAP completed its acquisition of Reltio on 7 May 2026 and describes it as part of making SAP and non-SAP data ready for AI. Check the release status of any specific integration you intend to use.SAP acquisition announcement.

How the graph enables AI agents to act reliably on SAP data

GraphRAG uses graph relationships to supply context for an LLM’s response. A system can combine relevant text with entity links, hierarchies, dates and policy information before asking the model to answer. That supplies useful context; it does not make every relationship verified or every answer correct.

For a question such as “Which orders are overdue?”, the system needs an agreed definition of overdue, the relevant order and delivery records, and the user’s access permissions. The graph can help identify those relationships. Test the answer against known cases, including partial deliveries, changed dates and exceptions.

Following several relationships can connect a supplier, order, financial posting and governing policy in one investigation. This is useful when the question crosses business functions. Preserve the source and date of each link so a reviewer can check how the system reached its answer.

Governance, traceability, and the SAP API policy constraint

SAP API Policy v.4.2026a, section 2.2.2, restricts API integration with autonomous, semi-autonomous or generative AI systems that plan, select or execute sequences of API calls. It explicitly excepts uses within SAP-endorsed architectures, data services or service-specific pathways identified for those purposes. Assess the intended API use against the relevant documentation and permitted pathway; an intermediary does not remove the policy’s controls.SAP API Policy.

For an agent that can act, define its permitted operations, approval conditions and audit trail before enabling writes. Check the applicable SAP service documentation and contractual pathway for both retrieval and action. Keep read access, write authority and the ability to delegate a sequence of actions separate.

The EU Data Act includes rights concerning data from connected products and related services, alongside separate rules for switching between data-processing services. Those provisions do not establish unrestricted permission to invoke any enterprise API. Determine which provisions apply to the data and service at issue. SAP’s API policy also preserves legally required export and other data-egress obligations. EU Data Act.

Connected Layer is a publication commissioned by Nodes. This article was prepared with AI assistance and edited for accuracy and clarity.