Palantir and SAP: How Foundry Works on Top of Your ERP

Palantir Foundry works on top of SAP and leaves it in place as the system of record. Foundry reads SAP data through an add-on installed on the SAP application layer, combines it with data from the systems around the ERP, models the result as business objects such as contracts, purchase orders, and assets, and lets users act on those objects in applications that write decisions back to the source systems. Foundry becomes the place where a process that crosses SAP and three other systems can be seen and run as one workflow. Companies reach for this pattern when the work that hurts lives between systems: a contract approved in a procurement tool and paid in SAP, or a work order in SAP that depends on sensor data SAP never sees.

How does Palantir Foundry connect to SAP?

Palantir's SAP documentation describes the connection as an ABAP add-on, the Palantir Foundry Connector 2.0 for SAP Applications, installed in the SAP system. The connector supports SAP ECC, S/4HANA, Business Warehouse, and SLT Replication Server. Four design points in that documentation matter to an SAP Basis team and a security reviewer.

The add-on is installed with SAINT, the standard SAP add-on installation tool, and exposes a web service through SICF so that Foundry requests data over HTTPS. Access runs through the SAP application layer with no direct database access, so standard SAP security policies apply to what Foundry can read. The tables, filters, and schedules for each transfer are defined in Foundry and executed by its data connection service. The connector also checks system load before an extraction starts and aborts the extraction if its criteria are not met, which matters during period close.

The objects available for extraction include application tables, functions and BAPIs, BW InfoProviders, BEx queries, ERP extractors, and CDS views. The documentation's capability table lists bulk import and webhooks as generally available and streaming import as beta.

What does HyperAuto add?

Raw SAP tables are hard to use. Field names are abbreviations, and a single business concept is spread across many tables. Palantir's HyperAuto, also called Software-Defined Data Integration, is a set of capabilities that provides data integration out of the box for common source systems. The documentation lists SAP, Salesforce, and Oracle NetSuite as the most widely used systems it supports, and says the current version, HyperAuto V2, supports SAP sources only and adds real-time streaming.

HyperAuto shortens the first weeks of an SAP program, and the design decisions stay with you. A generated model of sales orders and materials is a starting point. The work that determines adoption is choosing the objects, links, and actions that match how your teams make decisions.

What does the ontology add on top of the ERP?

The ontology is Foundry's model of the business: objects, their properties, and the links between them, plus the actions users are allowed to take. Our explainer on the Palantir ontology covers the mechanics. For an ERP program, its value is that one object can draw on several systems. A contract object can carry its commercial terms from a procurement suite, its financial postings from SAP, and its approval state from a workflow tool, and every application built on that object sees the same contract.

That is the difference between Foundry and a data warehouse fed from SAP. A warehouse gives analysts a copy of the data to query. An ontology gives operators an object to act on, with the permissions and the write path attached.

How do decisions get written back to SAP?

Users act through applications built in Workshop, Foundry's application builder for operational users, which reads from the object layer and uses actions for writeback. An action can call a webhook, and Palantir's webhook documentation names SAP and Salesforce as examples of the external systems a webhook can modify.

The documentation defines two modes, and the choice between them is a control decision.

Only one writeback webhook can be configured on an action. The documentation also notes the remaining gap: the external request can succeed and the Foundry change can still fail, so a design that posts to SAP needs a reconciliation check. For anything that touches the general ledger, we keep the posting logic in SAP, have the action call SAP through the connector's webhook capability, and treat Foundry as the place where the decision and its approval trail are recorded.

What about the systems around SAP?

Few processes live in SAP alone. Procurement often runs in a suite such as Coupa, customer data in a CRM, maintenance in a separate work management tool, and plant data in historians and sensor platforms. Foundry connects to each through its own connector or API, and the ontology is where they meet.

A reinsurer's finance operation is a good example. SAP held the financials, Coupa held spend and supplier management, and contract approvals ran between the two by email and reconciliation. The team built one governed model of the contract on Foundry, with rules that route a contract for extra review when it crosses a financial threshold or departs from standard terms, and a Workshop application that shows status, approval history, and required actions to both teams. The build reached deployment readiness in about four weeks, and neither SAP nor Coupa was replaced. The full account is in our contract operations case study.

What changes if you are moving from ECC to S/4HANA?

Many SAP customers are partway through a move from ECC to S/4HANA, and they ask whether a Foundry program should wait for it. The connector supports both, so the extraction layer does not force the question. The design choice that helps is keeping business logic out of the extraction step. If the ontology defines what a contract, a purchase order, or an asset is, and the pipelines map source tables to those definitions, then the migration changes the mapping and leaves the objects, applications, and user training alone. Programs that hard-code ECC table structures into every application pay for the migration twice.

Who needs to be involved on the SAP side?

Four roles decide how fast the SAP work moves. A Basis administrator installs the add-on and manages the transport path. A security lead designs the authorizations the connector holds, which sets the ceiling on what Foundry can read. A functional owner for each module explains what the tables and custom fields mean in your configuration. A process owner signs off on any write path and on the reconciliation report that checks it. Programs stall when the first of these four is booked after the Foundry team has already started.

Where do SAP programs on Foundry go wrong?

Four problems account for most of the trouble we see.

• Extracting everything. Teams sync every table they can reach, then spend their time on data nobody uses. Start from one decision and pull the tables that decision needs.
• Ignoring custom fields. Z-tables and custom fields often hold the logic that makes your SAP different from the template. Inventory them with the functional team before trusting a generated model.
• Skipping the authorization design. The connector follows SAP security policies, and Foundry has its own access model. Decide early which one governs each object, especially for HR and pricing data.
• Writing back without an owner. Every write path into SAP needs a named process owner, a test in a non-production client, and a reconciliation report.

How long does a first SAP use case take?

BD Emerson planning range: 4 to 10 weeks for a first use case on an existing Foundry environment, driven by the number of source systems, how much custom SAP configuration is involved, and whether the use case writes back. The SAP side usually sets the pace. Installing an add-on needs a transport path and a Basis team with time, and that scheduling should start in week one.

If you do not have a Foundry license yet, the first use case does not have to wait for one. As part of Andersen Consulting, BD Emerson can build a proof of value on Andersen Consulting's Foundry environment and move it to your license once the result is measured, which our article on a Palantir proof of value explains. To scope an SAP use case, talk to our Palantir Foundry implementation team.