Connecting the battery passport to SAP, Business Central and Odoo securely

Your ERP should feed the battery passport, but never decide on its approval. SAP, Microsoft Dynamics 365 Business Central and Odoo know the product master, the serial numbers, the production confirmations and the deliveries, and that is what the units in the passport are made from. The declared passport values, with their evidence and review, do not come from the ERP. The connection is secure when a dedicated technical user with minimal rights works in the ERP, an API key can only stage and read, and people commit, approve and publish.

How to start with spreadsheets and exports is covered in From Excel and ERP exports to a reviewed battery passport. This article is about the next step: connecting the ERP automatically and keeping that connection safe. The basics of the passport obligation are in our guide to the battery passport. Everything below describes integration patterns over the BatteryPass API, not ready-made connectors.

Which passport data lives in the ERP, and which does not?

The battery passport holds information on the battery model and on each individual battery (Art. 77(2)). The ERP mainly feeds the second level: every battery bears a model identification and a batch, serial or product number (Art. 38(6)), and that is exactly what the ERP posts during production or at goods receipt.

What the ERP lacks are the declared values: detailed composition, critical raw materials and hazardous substances, performance and durability values, dismantling and safety information, the declaration of conformity. Even if your material master carries characteristics such as capacity or cell chemistry, someone has to stand behind those values with evidence (Art. 77(4)). They belong in the review process, not in an automatic sync. Which fields exist and at which level is shown on the data fields page.

Two pieces of information travel the other way: the GS1 Digital Link and the passport status. They belong on the serial number record in the ERP, so labels and delivery papers carry the right link.

What does the integration pattern over the BatteryPass API look like?

Between the ERP and BatteryPass sits a middleware: a small service run by your IT team, your integration platform or, with SAP S/4HANA Cloud, usually SAP Integration Suite. It fetches data from the ERP and calls the BatteryPass API with an organisation key. BatteryPass does not connect to your ERP today; every connection starts at the middleware.

1. The ERP posts. A production confirmation or goods receipt creates serial numbers. An outbox table records the posting, so nothing is lost while the middleware is down.
2. The middleware stages. It writes a CSV file in the format of an import preset and uploads it with a key that has only the import scope. BatteryPass validates every row.
3. People decide. A member reads the validation report and commits the import, a reviewer approves the values, and only then is anything published.
4. The middleware writes back. A second key with the read scope follows the change feed and stores link and status on the serial number record.

Import presets map the columns of SAP serial number lists, Business Central item ledger entries and Odoo lots in testing. The interfaces are described on Developers.

What can an API key do, and what can it not do?

A key belongs to the organisation, not to a person. It has one to three scopes and can never do more than they allow in testing.

No scope allows a key to publish or withdraw passports or to manage members, keys or settings. This is deliberate. The economic operator placing the battery on the market ensures that the passport information is accurate, complete and up to date (Art. 77(4)), and Article 78, point (f), requires the rights to introduce, modify or update information to be restricted. An ERP user changing a record at night should not be able to change a published passport. Declared data therefore enters the passport only through a member's decision, and through two people when the four-eyes principle is switched on. Why that matters is explained in Provenance and four-eyes review.

Further limits catch mistakes in the middleware:

• A key only sees the imports it staged itself.
• The commit applies exactly the state the member reviewed. If the key changes the mapping afterwards, the commit fails.
• By default, the keys of an organisation together may have at most 20 open imports from the last seven days, upload 200 MB per day and run one validation at a time.
• All keys together may make 600 requests per minute; above that the API answers 429 with Retry-After.

One limit is still missing: a key cannot be restricted to particular models or units. Handing a service provider a key with condition lets it report condition data for every unit of the organisation.

How do SAP, Business Central and Odoo differ at the interface?

The systems differ less in the data they hold than in how you fetch it and how you sign in. The table summarises our ERP registry, based on the vendors' documentation as we read it on 24 and 25 October 2026; where only community sources exist, the table says so.

Three details that cost time in projects:

• Business Central: the standard API returns item ledger entries without serial or lot numbers, so you need a custom API page as an AL extension. Insert, modify and delete can be switched off on such a page, which keeps it read-only.
• SAP S/4HANA Cloud: our registry notes, citing SAP Note 3772443, that with serialisation level 1 creating a serial number through the API reports success but creates nothing. Reading is not affected. Let production create serial numbers and only read them.
• Odoo: the lot (stock.lot) has no manufacturing date. The middleware adds it, for example from the end date of the manufacturing order. Every JSON-2 call runs in its own transaction.

All 17 systems we describe patterns for are listed under Integrations, for example SAP S/4HANA Cloud, Business Central and Odoo.

How do you set up the technical user in the ERP?

One integration, one technical user, exactly the rights its workflow needs. The “units from production” workflow only reads in the ERP; the way back only writes link and status to the serial number record.

• SAP S/4HANA Cloud Public Edition: a communication arrangement of its own per integration, with exactly the APIs it needs. Prefer OAuth 2.0 client credentials or an X.509 certificate to user and password.
• SAP S/4HANA on-premise and Private Edition: X.509 rather than basic authentication. The system stays in your own network; the middleware reaches it through SAP Cloud Connector or a reverse proxy, never directly from the internet.
• SAP Business One: the Service Layer only knows sessions with user and password. That makes a dedicated user with restricted authorisations all the more important, and the middleware logs out when it is done.
• Business Central: sign in as an application through Microsoft Entra ID (service to service). Microsoft does not allow the SUPER permission set for such applications and advises granting only the permissions the integration needs.
• Odoo 19: a dedicated bot user, as Odoo recommends for integrations. Every call is checked against that user's access rights and record rules.

Where do keys and passwords belong?

In a secrets vault, not in ERP customising. A BatteryPass key in a Z table, in AL code, in an Odoo system parameter or a server action can be read by anyone who sees the customising or the code, and it travels with transports, backups and system copies into test systems.

• Secrets live with the middleware: in the secret store of the integration platform or your infrastructure, separate for test and production.
• One key per integration and environment. An organisation can have up to 25 active keys. Each is shown only once; BatteryPass stores only its hash.
• Plan rotation. BatteryPass keys do not expire: you create a new one, switch over and revoke the old one. Odoo API keys and client secrets in Microsoft Entra ID do have a lifetime. If their expiry is not in the operations plan, the integration stops one morning.
• Secret addresses are secrets. A webhook address that is itself the protection belongs in neither tickets nor logs.

How should you handle events and webhooks from the ERP?

As a prompt, not as a data source. According to our ERP registry, none of the five systems signs its events. A middleware should therefore only conclude from an event that it needs to look, and then read the data through the API with its own credentials. A forged call then causes nothing worse than an unnecessary read.

• SAP S/4HANA: in the cloud, business events such as “product changed” arrive through SAP Event Mesh as CloudEvents with a thin payload. On-premise, the material master can arrive as a MATMAS IDoc through ALE change pointers.
• SAP Business One: without documented webhooks, the middleware polls at fixed intervals.
• Business Central: when a subscription is created or renewed, Business Central checks the receiving address with a validation handshake. Notifications name only the resource and the kind of change and carry the clientState, which Microsoft describes as a shared secret for verifying them. Subscriptions expire after three days and must be renewed in time.
• Odoo: outgoing webhooks from automation rules send an unsigned payload. Treat the middleware's receiving address as a secret.

Check a signature wherever a vendor offers one. With these five systems, what remains is the handshake, the clientState, a secret address and, above all, reading the data back through the API. BatteryPass itself does not send webhooks yet; the change feed covers the way back into the ERP.

Why use the change feed instead of polling everything?

Because otherwise the middleware would have to read every unit regularly to find the one whose passport changed. The feed reports, in the order changes become visible, what happened to which object: unit created, passport published, re-published or withdrawn, model version approved, import committed or approved, event recorded, condition data accepted in testing.

• Thin entries. No values, no people, no personal data. The middleware then reads the object with the same key, so an intercepted feed reveals nothing.
• No gaps. An entry appears only once every older transaction has finished, so a cursor never skips a change that commits late.
• Filtered. The types parameter limits the feed to, say, passport changes.
• At least once. The middleware stores the cursor only after the ERP has accepted the change. After a database restore a cursor can become invalid (cursor_reset); the middleware then starts from the beginning.

Polling about every five minutes is usually enough for labels and delivery papers and spares the request limit.

How do you make the connection safe to repeat?

Networks fail, services restart, postings arrive twice. Every step therefore has to tolerate a retry.

What should you log?

Enough to answer any question later, and nothing that gives a secret away. BatteryPass logs every change a key makes with the key as the actor: the staged import, the validation it started, the reported event, the accepted condition data. BatteryPass does not log reads by keys or by signed-in members; reads of restricted tiers through a grant per email address are logged.

The middleware's log should hold, per run, the import id, the number of rows, warnings and errors, the stored feed cursor and, on errors, the code and request_id of the error response. It should not hold keys, passwords, tokens, webhook addresses, passport content or customer data. The middleware should raise an alert on 401 and 403 (key revoked or scope missing), on failed validations, on a cursor_reset and on subscriptions or keys about to expire.

Which workflows fit which system?

Our registry describes five workflows that do not depend on a particular ERP:

• Units from production

  Serial numbers from the production confirmation or goods receipt are staged as an import; members review, commit and approve before any passport appears.

• Passport links back into the ERP

  The middleware follows the change feed and writes the GS1 Digital Link and the passport status to the serial number record in the ERP, so labels and delivery papers carry it.

• Condition data from BMS and service

  A battery management system or a service tool reports measurements such as capacity fade or cycles; BatteryPass accepts newer measurements and publishes according to the organisation's policy.

• Returns and repairs as lifecycle events

  Completed repairs, inspections and component replacements from service or return orders appear as events in the unit's history.

• Product change leads to a new model version

  A change to the product master in the ERP triggers a notification; a member creates a new model version in BatteryPass. Declared data is never written automatically.

Condition data rarely comes from the ERP. It comes from the battery management system, which for stationary storage already has to hold the Annex VII data (Art. 14(1)). In BatteryPass it counts as a measurement, not a declaration. A product change, by contrast, never writes to the passport automatically: the middleware notifies the person responsible, who creates the new model version and has it approved.

What is ready, and what is planned?

• API keys with three scopes, import by key and the change feed are in testing.
• The integration patterns for 17 ERP systems are in testing. They are patterns over the API, not ready-made connectors; your IT team, IT service provider or integration platform builds the connection.
• Managed ERP connections, starting with Odoo, are planned. We do not give a date.

BatteryPass holds no certification for any of these systems and has no agreement with their vendors. The check date in the registry is the day we read the documentation, not a test by the vendor. Responsibility for the passport data stays with the economic operator. The Commission points out that the Battery Regulation does not regulate solution providers and that relying on one is entirely the economic operator's decision (FAQ 10.3). What to look for when choosing is covered in Choosing battery passport software; whether building your own pays off, in Build or buy.

Where do you start?

1. Run the process once without the ERP: export, import, validation report, approval, publication.
2. Pick the counterpart in the ERP: which posting creates the serial number, and where should link and status go?
3. Create a technical user with read access to product, serial numbers and production and write access only to the link and status fields.
4. Create two keys: one with import, one with read, per environment.
5. Put the secrets in the middleware's vault and schedule rotation around expiry dates.
6. Set up the outbox and the cursor, so nothing is lost and nothing arrives twice.
7. Set up logging and alerts for 401, 403, failed validations and cursor_reset.
8. Go live with one model and only then connect further models and plants.

By 18 February 2027 this process should have run with real serial numbers.