Create a battery passport yourself or use software?
The regulation does not prescribe software, it prescribes outcomes. Here you can read when a self-built solution holds up, when it tips over and how to make the decision cleanly.
The short version
From 18 February 2027, LMT batteries, electric vehicle batteries and industrial batteries above 2 kWh in the EU need a digital battery passport (Art. 77 of Regulation (EU) 2023/1542). Nowhere in this regulation does it say that you must buy software for it. A fully self-built system is legally permissible. So the question is not whether you are allowed to build it yourself, but whether that is the more viable route for your situation.
This page is a decision aid, not a sales page. We build battery passport software ourselves and still say openly: sometimes a self-build is the more sensible choice. The basics are explained in what is a battery passport?. The deadlines in detail are in battery passport duty: from when?. Below you find the requirements both routes must meet, the typical tipping points, the cost logic and a checklist with six questions.
What the regulation actually requires
The Battery Regulation prescribes outcomes, not tools. Anyone placing a battery subject to the passport obligation on the market must ensure from the deadline onwards: every single battery has an electronic passport. A QR code on the battery leads to this passport (Art. 13(6) and (7) as well as Annex VI Part C). The contents follow Annex XIII and are divided into three access levels: public information for everyone, restricted information for persons with a legitimate interest and for the Commission, plus an authority level for test reports. And the battery must be entered in the EU registry as soon as the registration obligation takes effect.
How you achieve these outcomes is up to you. A self-developed system on your own infrastructure meets the regulation just as well as a purchased solution. There is also no certification obligation for battery passport systems and no official seal, neither for providers nor for self-built systems. Anyone selling you such a seal is selling something that does not exist.
Guidance does exist, though. On 15 August 2026 the Commission published version 2.0 of its guidance with 71 data points, ordered by category. DIN SPEC 99100 describes seven working steps to the passport as a guideline. EN 18222 defines a standard for the data interfaces, the final DIN version has been announced. The DPP standards harmonised in summer 2026 create a presumption of conformity only under the Ecodesign Regulation (ESPR), not for the battery passport. All of this applies equally to self-built systems and software: these are working foundations, not mandatory tools. The technical terms from the regulation and the standards are explained in the glossary.
What a self-built system has to deliver
If you build it yourself, you are not building a form or a product page, you are building a system with six tasks. Each of them is doable, but each of them means permanent operation.
A data model per battery type
Annex XIII defines the contents, the Commission guidance counts 71 data points with categories and visibilities. The decisive point: the required fields differ by battery type. An EV battery needs different information than an LMT battery or a stationary storage system. A self-built system therefore needs a type-dependent data model with its own required-field logic per type, otherwise you check completeness by hand permanently.
Separate access levels server-side
The three levels from Annex XIII must be technically separated. Merely hiding restricted fields in the interface is not enough: what the server delivers can be retrieved. A self-built system must therefore decide already at the data query which level the caller sees. On top of that there is an open item: the implementing act on legitimate interest (Art. 77(9)) has not yet been adopted. The access check must be designed so that it can be adapted later without rebuilding the system.
QR codes that last for years
The QR code is printed or lasered onto the battery and lives as long as it does. The URL behind it must not break over the entire lifetime: the link has to survive domain renewals, hosting migrations, company renamings and system replacements unscathed. If you build it yourself, you make this availability promise yourself, including backups, monitoring and an answer to the question of who is responsible when the person who built the system leaves the company.
Schema validation instead of visual checks
Passport data is read by third parties by machine. Errors in units, formats or required fields then show up at the readers' end, not at yours. A self-built system should therefore validate every passport against a machine-readable schema before publication, for example against the Battery Passport Data Model. Maintaining this validation yourself means: following up on every schema change.
Versioning and evidence
A battery passport is not a one-off document. Data changes through corrections, repairs and new mandatory information. You must be able to prove which version was public when and who changed what. That requires versioning and a reliable history, if need be for the market surveillance authorities.
Watch the open legal acts
The legal position is moving. The carbon duties are not triggered despite passed fixed dates, because methodology and format acts are missing. The registry regulation (EU) 2026/1778 has been in force since 6 August 2026, the sandbox since 20 July 2026. Battery registration is still blocked on the EU side. The semantic catalogue and APIs are announced for Q4 2026. The registration duty starts on 18 February 2027 and requires an eIDAS-verified economic operator. Building it yourself needs a named person tracking these movements. The details are in EU battery passport registry. All six tasks apply from the first passport onwards.
The item people overlook: where the data comes from
In self-build calculations the software is almost always center stage: form, database, passport page, QR code. The effort rarely sits there. It sits in gathering data from systems already in the house. Master data and identifiers are usually in the ERP, text and images in the PIM. Technical values and bills of materials sit in the PLM. Test reports and life cycle assessments come from test houses and service providers. The due diligence policy report under Article 52(3) is drawn up by the economic operator themselves. Suppliers and test houses only deliver the evidence and the verification.
Why this hits a self-built system twice
Building it yourself means carrying this integration work twice. Once for the initial filling, when all mandatory entries per model have to come together. And once permanently, because the passport lives on after placing on the market. Under Article 77(4) the economic operator keeps the data accurate, complete and up to date. Annex XIII point 4 requires values that change at every change of status. Off-the-shelf software does not solve that part automatically. But it supplies the interface you connect to.
How long it takes
Nobody outside can give you a credible monthly figure. Too much depends on your system landscape. What can be estimated are the items. Those are the 71 data points of the Commission guidance per battery model. Plus the six tasks of a self-build named above. Plus the number of your models and battery types. And the number of source systems you pull data from. These four figures are not a formula but the items for your own assessment. An estimate derived that way carries further than any rule of thumb from the internet. You can name every assumption in it. The lead time can then be argued in months instead of guessed. It starts not with the build but with the data collection.
More important than the duration is the end point it hangs on. In law the duty attaches to placing on the market or putting into service from 18 February 2027. In practice your own end date comes earlier, because the QR code is applied in manufacturing: count backwards from the day the first affected battery leaves the line with its marking, not from the deadline itself.
Where building it yourself holds up and where it tips over
Where a self-built system holds up
A self-built system is a realistic option when three things come together: a single battery model or very few models, data that rarely changes, and an in-house developer team that takes permanent responsibility for operations. Then the passport is a manageable undertaking: one data model, one public page, one stable link, one change process. Companies that already run their own software do not take on an additional dependency this way.
Where it tips over
It becomes critical in three places. First, model variety: every additional model and every additional battery type brings its own required fields and its own maintenance. Second, suppliers: as soon as cell, material or manufacturing data comes from third parties, you need a structured supplier process with checks and tracking; email attachments do not scale. Third, movement in the standards: every new guidance document, every implementing act and every schema change means development work. The one-off project then turns into a permanent product with its own backlog. This tipping point rarely shows on day one; it arrives with the second model, the first supplier or the first schema change.
In between lies an honest gray area: a company with two or three models, a small developer team and supplier data in motion. Here the deciding factor is less the technology than the organization. If the battery passport gets a fixed owner in your company with a budget and a stand-in arrangement, building it yourself can work. If it remains a side project of a single person, it becomes a risk on exactly the day that person does something else.
The cost logic of both routes
There are no serious flat figures for either route, too much depends on the number of models, the data situation and the team. The logic behind it can be described cleanly, though.
With a self-built system, the start is a development effort: data model per type, access logic, QR infrastructure, validation, versioning. After that, the real cost block begins, and it is permanent: operations, domains, monitoring, security updates, regulatory monitoring and retaining the people who can do all of this. These running costs are incurred whether a lot or a little moves in a given year.
With software you pay a running fee that spreads development, operations and regulatory monitoring across many users. An honest comparison therefore calculates both routes over the same period of several years and includes the staff hours for the self-built system. A detailed look at the costs with the items of both routes can be found under Battery passport costs; our own prices are openly listed on the pricing page.
One item is regularly forgotten in self-build calculations: the cost of waiting. Every developer hour that flows into the passport is missing from your own product. And if the self-built system starts in autumn 2026 and gets delayed, the deadline still stands on 18 February 2027. These two figures belong in the same table as the license fee and server costs.
Decision checklist: six questions
Six questions decide the matter in most cases. Answer them in writing and honestly; a general checklist of battery passport obligations is additionally available under Battery Passport Checklist.
- How many battery models and types do you have? One model with stable data speaks for building it yourself. Several models or several battery types mean several sets of required fields and ongoing maintenance.
- Do you have a developer team with permanent responsibility? This is not about the project but about operations until well beyond 2030. If the responsible person leaves, the passport must keep running.
- Who watches the open legal acts? CO2 methodology, the access act under Art. 77(9), registry APIs: several building blocks are not yet final. Someone has to follow this and build in the changes.
- Do suppliers contribute data? As soon as cell or material data comes from third parties, you need a structured supplier process with checks and status, not just email attachments.
- Can you guarantee QR availability over the battery's lifetime? Domain, hosting, redirects, backups: the printed code must still lead to the passport many years from now.
- What does a year of delay cost you? Calculate the self-built route realistically through to 18 February 2027, including testing and corrections. The deadline does not move because an internal project stalls.
If the majority of your answers land on the demanding side, building it yourself is not wrong. But it is then a product you operate permanently, not a project you complete. You do not have to make this decision final: the middle path below keeps both routes open.
Two requirements regularly overlooked when building it yourself
Integrity and traceability
Article 78(g) requires authenticity, reliability and integrity of the data. Point (h) demands a high level of security and privacy and the prevention of fraud. In a self-built solution that means more than a login. You need a history showing which version was published when and who changed it. And you need it years later, when market surveillance asks under Article 79. A field overwritten by the last write does not deliver that. The effort is not the storing but separating draft, published version and correction. Technically it comes down to two building blocks you supply yourself. First a cryptographic signature per published version, so tampering can be detected. Second a tamper-evident audit trail with timestamp and author per change. Whether you use verifiable credentials for that or something else is up to you. The Battery Regulation does not mention the term once, it requires the result. Which identifiers you need is explained on the partner overview.
The time before the first passport
The second underestimated item is data collection. The public block under Annex XIII point 1 pulls data from several sources. Those are Annex VI Part A, the declaration of conformity under Article 18 and the due diligence report under Article 52(3). Plus the recycled content documentation under Article 8(1). This data rarely sits in one hand. Test reports are at the lab, cell chemistry at the supplier, recycled content at the supplier of the supplier. How long the lead time runs depends on your supply chain, not on the software. Plan procurement separately from the tool. Start with the entries that have to come from outside.
Neither point argues against a self-build. They just belong in the calculation before you decide. The collection arises on both routes. Proof management is the part of a self-build that keeps running after the first release.
The middle path: start with software, keep your data
Building it yourself or software is not a one-way street, as long as one condition is met: your data belongs to you, in open formats and exportable at any time. Then you can start with software, gain experience with the data model on real passports and still build it yourself later, without starting from scratch.
That is how our software is built. A type-specific editor leads through the mandatory fields of five battery types in seven steps, along DIN SPEC 99100. Before publishing, a publish gate checks the GS1 identifiers, the mandatory organization data and all seven steps. Schema validation against Battery Passport Data Model v2.0 blocks faulty versions. Suppliers contribute through share links without an account of their own. Existing data comes in by CSV import. For extraction there is JSON in Data Model v2.0, DIN SPEC JSON and PDF in German and English. Plus a REST API aligned with EN 18222. Moving away from us stays possible at any time, including to your own system.
If you want to settle the basics first, the battery passport hub gathers the topics in one place. Prices are on the pricing page, features on battery passport software. Getting started needs no meeting. You create an account and build the first passport free permanently. On your own data you see whether the structure holds. Which providers exist is in the software comparison.
Frequently asked questions
Can I test for free before deciding?
Yes. One passport is free forever, with no trial period and no time pressure. You use it to create a real passport for one of your models and see from your own data whether the structure holds up. All further prices are openly listed on the pricing page; there is no sales call with us.
Am I locked in with software?
That depends on the provider and should be checked before any purchase. With us you can export JSON in the Battery Passport Data Model v2.0, DIN SPEC JSON and PDF in German and English at any time; the REST API is aligned with EN 18222. If you later decide to build it yourself after all, you take your data with you in full.
Do I have to develop something of my own for the EU registry?
Nobody can answer that conclusively today. The registry regulation (EU) 2026/1778 has been in force since 6 August 2026. Battery registration is still blocked on the EU side. The semantic catalogue and APIs are announced for Q4 2026. What is certain: only the eIDAS-verified economic operator may register. No service provider takes that verification off your hands. Whether self-build or software, the registry connection only becomes concrete with the published APIs.
Is a PDF or a product page on our website enough?
No. The passport must exist individually per battery, be reachable via the QR code on the battery, reflect the access levels from Annex XIII and remain updatable. A static PDF or a general product page cannot do that. Both can supplement the passport, but not replace it.
How quickly is a first passport ready if we use software?
The technology is rarely the bottleneck here. The editor shows per step which required fields are missing for your battery type, and validation reports errors before publication. The real work is collecting the data, above all from suppliers; for that there are share links without a login. Ahead of the 18 February 2027 deadline, the scarce factor is usually the data situation, not the tool. An early first passport therefore shows you one thing above all: which data you are still missing.
Do I need a blockchain for an in-house build?
No. The Battery Regulation prescribes no particular technology. The words blockchain and distributed ledger do not appear once in the official text. Required are the QR code under Article 13(6) and retrieval of the passport under Article 77(3). Plus the contents under Annex XIII. How you store that is your decision. What you really need: a permanently reachable address across the life of the battery. Plus versioning, so earlier states stay traceable. And a clean access separation for the three levels. Self-builds fail on that more often than on database technology.
Try it first, then decide
Set up an account, choose your battery type and capture your first passport in the guided editor. One passport is free forever.