News & Blogs

Published - 6 October 2026 - 5 min read

Connecting ERP Systems To Digital Battery Passports: From Business Data To Compliance

A Digital Battery Passport (DBP) does not exist separately from the systems that already manage a company's battery data. For manufacturers and OEMs, relevant information may already be distributed across enterprise resource planning (ERP), product lifecycle management (PLM), manufacturing, procurement, quality, sustainability and service systems.

The challenge is connecting that existing information to the Digital Battery Passport without creating another isolated data silo.

In our recent article, How To Handle Missing Historical Battery Data, we looked at what organisations can do when lifecycle information is incomplete. ERP integration addresses the other side of the problem: ensuring the data that already exists inside an organisation can be identified, connected, validated, and transferred into the appropriate Battery Passport processes.

From 18 February 2027, Battery Passports will be mandatory for relevant electric vehicle (EV) batteries, light means of transport (LMT) batteries and industrial batteries above 2 kWh placed on the EU market or put into service. The European Commission states that detailed battery information will remain decentralised and under the responsibility of the relevant economic operator.


Why Does ERP Integration Matter For Battery Passports?

An ERP system can contain some of the information needed to support a Battery Passport, particularly around products, suppliers, materials, manufacturing locations, orders and organisational information.

However, an ERP system is rarely the only source.

A battery's technical specifications may originate in engineering or PLM systems. Production information may come from manufacturing execution systems (MES). Quality systems can contain test and conformity information, while sustainability platforms may hold carbon footprint or recycled-content data. Battery management systems can generate operational information during use.

The Battery Passport therefore needs to connect information from multiple sources rather than simply import an entire ERP database.

This is why integration should begin with the data requirements, not with the question of which ERP connector to install.


Start With A Battery Passport Data Map

Before building an integration, identify which Battery Passport data points are required for the relevant battery category and where those values currently exist.

For each data point, IT and data teams should establish:

Question

Example

What information is required?

Manufacturing location

Where does it originate?

ERP or manufacturing system

Who owns it?

Operations or supply chain

What identifies the record?

Product, batch or battery ID

How is it validated?

Master data or quality checks

How often does it change?

Per production event or periodically

Who can access it?

Internal or authorised external users

BASE's How To Map Existing Business Data To Battery Passport Requirements explores this process in more detail. The objective is to establish a clear relationship between regulatory requirements, existing business data and the systems responsible for maintaining it.


What ERP Data Can Feed A Battery Passport?

The exact information required depends on the battery category and applicable requirements. However, an ERP environment may provide useful information about the battery and its value chain.

For example, ERP and procurement systems can contain supplier information, manufacturing locations, material records and organisational data. Product master data can provide identifiers and product relationships, while inventory and production records can help connect components, batches and finished products.

Other information will normally need to come from other systems.

Business System

Potential Battery Passport Data

ERP and procurement

Suppliers, sourcing and organisational information

PLM and engineering

Technical specifications, chemistry and component information

MES

Production dates, batches and as-built information

Quality and laboratory systems

Test results and conformity evidence

LCA and sustainability systems

Carbon footprint and environmental information

Battery Management System

State of Health, capacity and operational information

Service systems

Repairs, replacements and lifecycle events

This distinction matters because the ERP should generally be treated as one trusted source within a wider data architecture, rather than as the Battery Passport's master database by default.


Connect The Right Data To The Right Battery

One of the most important integration challenges is identity.

An ERP may identify a product using a material number or stock-keeping unit. A manufacturing system may use a production order or serial number. A Battery Passport needs a reliable relationship between the relevant battery and its digital identity.

If these identifiers cannot be connected, information from several systems may be difficult to associate with the correct battery.

A practical integration architecture therefore needs an identifier strategy covering products, batches, components and, where required, individual batteries.

For example:

ERP Product ID → Production Batch → Battery Serial Number → Battery Passport Identifier

The exact relationship will depend on the organisation's manufacturing and data model, but the principle is consistent: every data exchange needs enough identity information to prevent records from being attached to the wrong battery.


Use Integration To Preserve Data Lineage

An ERP-to-Passport connection should also make it possible to understand where published information came from.

Consider a battery manufacturing date. The value may originate in a manufacturing system, pass through an ERP or data integration layer, undergo transformation into the Passport's required format and then become part of the published record.

A reliable integration should preserve that relationship.

This connects directly with Battery Passport Data Lineage: From Source System To Published Passport. Data lineage allows organisations to trace important Passport information backwards through transformations and systems to its source.

For IT teams, this provides visibility into the integration architecture. For compliance teams, it provides a route for checking how a published value was established.


Validate Data Before It Reaches The Passport

Connecting two systems does not automatically make their data compatible or reliable.

An ERP may contain outdated supplier information, inconsistent units or records that were never intended for external reporting. A Passport integration therefore needs validation rules before information is published.

Validation can check whether:

  • the required field is populated;
  • the value uses the correct unit and format;
  • the battery identifier is valid;
  • related records are consistent;
  • the value falls within an expected range; and
  • supporting evidence is available where required.

The process described in our How To Validate Battery Passport Data Before Publication article is particularly relevant here.

The objective is to prevent poor-quality source data from being transferred automatically into a compliance-facing system.


Decide How the Battery Passport Data Should Move

There is no single integration method that will suit every manufacturer.

Some organisations may use APIs to exchange information between ERP, data platforms and Battery Passport services. Others may require event-driven integration, scheduled synchronisation or an intermediary data layer that combines information from several systems.

The appropriate approach depends on factors such as data volume, update frequency, system capabilities, security requirements and the number of downstream users.

APIs are particularly relevant where information needs to be exchanged between organisations or lifecycle actors. BASE previously explored this in the Battery Passport APIs: How Authorities And Recyclers Will Exchange Compliance Data Across The Battery Lifecycle article.

The important point is to design the integration around the information flow rather than forcing every Battery Passport requirement directly into the ERP's existing data model.


Keep ERP Systems And Battery Passports In Their Roles

An ERP system and a Digital Battery Passport serve different purposes.

The ERP is primarily designed to manage business processes such as procurement, production, inventory, finance and supply chain operations. The Battery Passport provides structured information about a battery for authorised users across its lifecycle.

Trying to make the ERP perform every Battery Passport function can create unnecessary complexity.

A better architecture can allow the ERP to remain the authoritative source for the business information it manages, while a dedicated data or Passport layer handles the transformation, validation, access and publication requirements.

This approach also makes future changes easier to manage. If Battery Passport requirements, standards or service providers change, organisations can modify the integration layer without redesigning the underlying ERP.


Manage Updates And Lifecycle Changes

Integration also needs to account for change.

If a supplier changes, a manufacturing location is updated, a battery specification is corrected, or new lifecycle information becomes available, the relevant Passport information may need to change.

An automated connection should therefore define which system is authoritative for each data point, when changes are detected and how updates are validated before publication.

This is particularly important for lifecycle information that does not originate in the ERP. Repair, reuse, repurposing and operational data may be generated elsewhere and need to be connected with the existing Passport record.

Our article on How To Manage Changes To Battery Passport Data Over Time explores how versioning and controlled updates can help maintain the history and integrity of changing Battery Passport information.


Protect Sensitive ERP Data

Connecting an ERP to a Battery Passport does not mean exposing the ERP itself.

ERP systems can contain commercially sensitive information, including supplier relationships, pricing, inventory, purchasing and internal operational data. Only the information required for the relevant Passport and access rights should be transferred.

A well-designed integration should therefore use data filtering, access controls and appropriate authentication between systems.

The European Commission notes that the Battery Passport operates through a decentralised system and that information is accessed according to applicable user roles.

This makes the integration boundary important: organisations need to determine exactly what leaves the internal business environment, where it is stored and who can access it.


How BASE Connects Business Data With The Digital Battery Passport

The BASE project is developing, validating and implementing a trusted and interoperable Digital Battery Passport framework designed to connect battery information across the value chain.

This makes integration with existing enterprise systems an important part of the wider BASE approach. Rather than treating the Battery Passport as a standalone repository, BASE's work addresses how information from different sources can be connected, validated, traced and exchanged while supporting data authenticity, privacy and interoperability.

For manufacturers and OEMs, this means the path towards a Digital Battery Passport can build on existing business data. ERP systems, production platforms, engineering tools and other sources can remain part of the organisation's wider data architecture while relevant information is structured and connected to the Passport.


Build The Bridge Before You Build The Passport

ERP integration can make Battery Passport implementation considerably more manageable, but the technical connection should come after the data requirements and ownership have been understood.

The practical sequence is:

Identify Requirements → Map Existing Data → Define Identifiers → Establish Data Ownership → Validate Information → Integrate Systems → Control Access → Publish And Maintain

For IT teams, this provides a roadmap for integration. For manufacturers and OEMs, it reduces unnecessary duplication of data and systems. For compliance teams, it creates a clearer path from business records to the information made available through the Battery Passport.

The goal is not to turn an ERP system into a Battery Passport. It is to build a reliable bridge between the systems that already hold battery information and the Digital Battery Passport ecosystem that will use it.


The BASE project has received funding from the Horizon Europe Framework Programme (HORIZON) Research and Innovation Actions under grant agreement No. 101157200.

References & Resources

European Union - Regulation (EU) 2023/1542: https://eur-lex.europa.eu/eli/reg/2023/1542/oj

European Commission - Digital Product Passport: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en?prefLang=sv

European Commission - Digital Product Passport for Batteries: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/batteries_en

European Commission - Guidance to Support Preparations For The Digital Batteries Passport: https://single-market-economy.ec.europa.eu/news/guidance-support-preparations-digital-batteries-passport-2026-08-21_en

Regulation (EU) 2024/1781, the Ecodesign for Sustainable Products Regulation: https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng