From Excel and ERP exports to a reviewed battery passport

Most of the data for a battery passport already exists in your company: in production spreadsheets, ERP exports, data sheets and with suppliers. The way to a reviewed passport is not retyping but four steps: separate model and battery data, import serial numbers and measurements, close gaps with evidence, and approve every value before it goes public. Connect the ERP once this process works.

This guide follows a manufacturer of stationary storage. The obligations behind it are covered in Battery passport for stationary storage.

Where does the data for a battery passport live today?

Annex XIII of the Battery Regulation lists what goes into the passport. Hardly any of it has to be collected from scratch; it just sits in different places and formats.

The "level" column decides how much work there is. Model data you maintain once; battery data arrives with every battery. That is why importing pays off most for battery data.

Which information belongs to the model and which to the individual battery?

Article 77(2) requires both: information on the battery model and information specific to the individual battery. A "battery model" is a version whose units share the same relevant characteristics and the same model identifier (Art. 3(1), point 19). For the individual battery, Annex XIII, point 4, requires among other things the values for performance and durability "when the battery is placed on the market and when it is subject to changes in its status": in practice, the end-of-line measurements of every unit.

BatteryPass therefore keeps three levels apart in testing:

• Battery model: the commercial product with name, model identifier, GTIN and category.
• Model version: a technical revision with a start date, for example after a cell change. This is where chemistry, composition, performance characteristics and the declaration of conformity live. A unit without an explicit version gets the one valid on its manufacturing date.
• Unit: the individual battery with serial number, manufacturing date, plant, status and its measurements.

This is how our field registry splits the identification data of a stationary storage system:

What does a spreadsheet need to look like for the import to work?

One row per battery, one column per piece of information. That is all. The import reads UTF-8 CSV files separated by semicolon, comma, tab or vertical bar, and XLSX files, up to 10 MB, 10,000 rows and 200 columns per file.

German and English column names are recognised, as are common variants such as "EAN" for the GTIN. Columns the import does not know stay unmapped and do no harm. For exports from SAP, Business Central, Odoo and NetSuite there are ready import presets that map those systems' columns.

Most errors do not happen in the import but earlier, in Excel:

• Lost leading zeros. Excel reads a 14-digit GTIN as a number and drops the leading zero. Format the column as text or export CSV straight from the ERP.
• Several header rows and totals. A spreadsheet for people has title rows, merged cells and a totals row; an import spreadsheet has exactly one header row and otherwise only batteries.
• Mixed units. If one plant reports in Wh and another in kWh, the values belong in two columns with the unit in the name, not in one.
• Dates as numbers. If Excel exports a date as a serial number, the column format is wrong.

What does the import check before a battery is created?

After the upload you first see the mapping: which column belongs to which field, and in which unit. Then BatteryPass checks every row with the same rules as entry in the portal and writes a report with row, column and reason in testing.

Only after you have read the report does a member commit the import. The units are created as drafts, their values with the source "import" and a reference to exactly this file.

How do imported values become approved values?

An imported value is recorded but not yet reviewed. With hundreds of batteries and a dozen measurements each, approving value by value is not feasible. A reviewer therefore approves the values of a committed import in one step in testing.

The rules of a single approval still apply to every value. These stay open:

• values whose automatic check fails;
• values without the evidence the registry requires for that field;
• values with an import warning, such as the suspect unit;
• values the reviewer recorded personally, if your organisation has the four-eyes principle switched on.

The approval report says how many values stayed open and why. You review those individually.

How do you close gaps without chasing people by phone?

After the import, BatteryPass shows for every model version and unit what is missing, based on the requirement status in the field registry: required, conditional, not applicable with a reason, or later required. A field such as the carbon footprint, which only becomes mandatory with a future act, does not show up as a gap.

• Tasks with owners. Missing required values become tasks assigned to a person.
• Evidence on the value. Data sheet, test report or supplier declaration are attached to the value they support, with their own access level.
• Supplier requests. A supplier gets a link for exactly the requested fields, uploads evidence and needs no account in testing. Their answers are reviewed like all others.

A typical example: the cell supplier knows the composition of cathode, anode and electrolyte; you do not. Instead of emailing a spreadsheet template and retyping the answer, you request exactly those fields. The answer arrives with the source "supplier" and the uploaded evidence on the value, and waits for your review.

Why does it matter who entered which value?

Because responsibility lies with the economic operator. It ensures that the passport information is accurate, complete and up to date (Art. 77(4)), and Article 78 requires that the authenticity, reliability and integrity of the data are ensured (point (g)) and that rights to modify information are restricted (point (f)). If you cannot say where a value came from when market surveillance asks, you have a problem even if the value is right.

BatteryPass therefore stores the provenance of every value in testing:

A change inserts a new revision and marks the old one as superseded, so it stays clear who changed what and when. How we protect the data itself is described on Security.

How does the ERP export arrive without manual work?

Once the spreadsheet process works, your middleware can deliver the file itself. The flow looks like this:

1. The ERP posts the production confirmation or goods receipt and writes the serial numbers to an outbox table.
2. The middleware collects them and writes a file in the format of an import preset.
3. An API key with the scope import uploads the file and starts the validation.
4. A member reads the validation report in the portal, commits the import and approves the values.
5. The passports are published.

A key cannot commit, approve or publish: those steps stay with members of your organisation, so declared data only enters the passport through a person's decision.

We describe these connections as integration patterns over the published API, not as ready-made connectors. For common systems we record interfaces, sign-in and the state of our check:

Two examples of why the details matter: the standard Business Central API returns item ledger entries without serial or lot numbers, so a custom API page is needed. And Odoo 19 offers the JSON-2 API with API keys as bearer tokens, while XML-RPC and JSON-RPC are deprecated. More on the Business Central and Odoo pages, and every system under Integrations.

How do the passport link and status get back into the ERP?

Through the change feed. A key with the scope read regularly asks what has changed: unit created, passport published, re-published or withdrawn. The entries carry no values and no people, only what changed on which object; the middleware then reads the object itself. That way it writes the GS1 Digital Link and the passport status to the serial number record in the ERP, and labels and delivery documents carry the right link. The interfaces are described on Developers.

Condition data from the BMS goes the other way, into the passport: a key with the scope condition reports measurements with their measurement time. They count as measurements, not declarations, and are accepted without a second person; BatteryPass skips measurements older than the stored one.

Which data should never leave your ERP?

The battery passport needs data about batteries, not about people. Keep in the ERP:

• names, addresses and order numbers of customers;
• names of employees and service technicians;
• prices, margins and supplier terms;
• location or operator data of a battery in the field.

The serial number is enough to connect a passport, an event or a measurement with the record in the ERP.

When is a passport ready to publish?

When no required value is missing and every value is approved. Before that, BatteryPass does not allow publication. Before publishing you see the passport as the public, persons with a legitimate interest and authorities would see it. Publishing signs the passport version and makes it reachable through its GS1 Digital Link; the example battery passport shows what that looks like.

Then maintenance begins: Article 77(4) requires up-to-date information. Every later change goes through the same review and creates a new passport version; earlier versions stay readable with their date.

Where do you start?

1. Pick one model, ideally the one with the most units.
2. Export a serial number list with GTIN, manufacturing date and plant.
3. Create the model version and enter the values from the data sheet and the Article 10 documentation.
4. Request supplier data for composition, critical raw materials and hazardous substances.
5. Name reviewers and decide whether the four-eyes principle applies.
6. Import, read the report, commit, approve.
7. Check the preview and publish.
8. Automate once the process runs: the import first, then the way back into the ERP.

By 18 February 2027 this process should have run end to end at least once. What else BatteryPass does is on the product page.