If your product data lives in SAP, you have two realistic paths to a Digital Product Passport: an SAP-native add-on project, or a lightweight connector that reads your existing master data over the API and generates passports outside your ERP. The first path is a 12-plus-month IT project. The second takes weeks. This article explains where DPP-relevant data sits in a typical SAP landscape, how both paths work, and how to decide between them.

The good news: the data is already in SAP

ESPR (Regulation (EU) 2024/1781) requires manufacturers to make defined product data publicly available, category by category, as delegated acts arrive. Look at what a passport needs and then look at a grown SAP system:

The data exists. The question is only how it becomes a public, standards-conformant, registry-registered passport. The EU's central DPP registry has been live since 19 July 2026, so "how" now has a concrete technical meaning.

Path 1: the SAP-native route

SAP's own sustainability portfolio is growing, and system integrators offer DPP add-ons inside the SAP stack. The upside is architectural purity: everything stays in one vendor's world. The downsides are the classic ones. These are IT projects with scoping, licensing, customizing, and release dependencies. Budgets start in the six figures, timelines start around a year, and every delegated act that changes data requirements becomes a change request.

For a corporation with a large SAP center of excellence and DPP volumes in the millions, that path can be right. For a mid-sized manufacturer with a compliance deadline and no free IT capacity, it rarely is.

Path 2: the connector route

The alternative treats SAP as what it is, the system of record, and leaves it untouched. A connector reads product data over SAP's standard interfaces (OData services on S/4HANA, BAPIs or IDocs on older ECC systems), maps it to the DPP schema, validates it, and generates QR-coded passports on a platform built for exactly that. The pattern is the same one we use for PIM systems, described in creating a DPP from PIM data:

1. Sync: material master changes flow to the connector via OData polling or event-based triggers
2. Mapping: a configuration maps SAP fields and classification characteristics to DPP fields
3. Validation: products with missing required fields get flagged with a work list your team can process
4. QR and write-back: the passport URL can be written back to a material master field or handed to your label management

No SAP customizing, no transport requests, no release dependency. Your SAP team's involvement is limited to providing API access and joining one mapping workshop.

The honest comparison

One nuance to be fair about: SAP landscapes vary more than PIM systems do. A clean S/4HANA system with disciplined classification maps in days. A 20-year-old ECC with custom Z-fields takes a discovery phase first. That is why our SAP projects run three to five weeks instead of the two to three we quote for Akeneo. The comparison across all platform types, including the consulting route, is in the DPP software buyer's guide.

How to decide

Ask two questions. First: does your category timeline leave room for a year-long project? Check the DPP timeline, and remember that data cleanup consumes the buffer faster than expected. Second: do you want the passport to do anything beyond compliance? If QR codes should carry manuals, service requests, or spare parts ordering, you want a platform where that layer exists, not a compliance add-on where it would have to be built.

Next step

Book a 30-minute strategy session and bring someone who knows your SAP landscape. We will tell you within the call whether your setup is a three-week case or needs a discovery phase, and what both would cost.

Book your strategy session