In this guide 6 sections
Excel works for a while. That while ends once you build several models in small batches, and an ERP earns its place when firmware, certificates and serial numbers must link to each unit shipped. Switch when a field fault cannot be linked to its build within minutes, or a certificate lapses unnoticed during a quiet month.
Where a spreadsheet still does the job
A small charger company can run on a bill of materials sheet, a stock sheet and a dispatch list kept by the person who solders, flashes and ships. Three people know every file. Nobody needs a screen.
That holds while you ship one or two models in batches of a few dozen, because a new revision of the power board is a message to the floor. Memory covers the gaps.
The trouble starts when the same charger leaves in three hardware revisions and four firmware builds, and a unit returns with a fault that one combination causes. The sheet still lists the parts. It no longer says which unit got which.
- One model, one revision, one supplier per part
- One person who builds and ships every unit
- No certificate tied to a specific variant
- Service calls handled by the founders themselves
Firmware and hardware revisions need a link to the serial number
A charger is hardware running code. The controller board, the energy meter, the contactor and the cable assembly each carry a part revision, and a supplier can change any of them without telling you. Firmware carries its own version. It can change after the build.
A spreadsheet can hold a firmware column. It cannot stop someone flashing build 2.3 onto a unit built for 2.1 hardware, nor show the flash date, the operator or the test result that followed.
With serial tracking, each flash becomes an event against the unit, so when a protocol bug surfaces you filter by firmware and list every affected charger in one query.
Certification records belong beside the product, not in a folder
Chargers ship with a pile of paper: a safety test report, an EMC report, an ingress protection result, a grid or utility approval, a marking label proof. Each covers one variant.
A shared folder of PDFs works until a buyer asks for the certificate covering the 22 kW wall unit with the tethered cable. Someone then opens eleven files. A quiet change to a supplier part can void a report, and a sheet has no way to warn you before the next batch ships.
In an ERP the certificate is a record with an issue date, an expiry date, the test lab and the part numbers it covers. Change a covered part and the system flags the certificate for review, so the next batch cannot reach the line until someone has decided whether the report still stands.
- Variant and part list each report covers
- Test lab, report number and expiry
- Label artwork version printed on the unit
- Open actions after a design change
Field service is where the two approaches part ways
A charger fails at a car park three hundred kilometres away, and the caller gives you a site name, not a serial number. In a spreadsheet world someone phones the installer, hunts through dispatch notes and guesses which hardware revision to load on the van.
With serials, installs and service visits in one system, the answer is already on screen: the build, the firmware, the swapped parts and the last visit. The technician carries the right spare.
Repeat faults show up as a pattern, one relay lot, one cable gland or one firmware release, but spreadsheets hide it because each visit sits in a different file.
A sensible way to decide and move
Count what you cannot answer in ten minutes. Be honest. Which units run this firmware? Which certificate covers this variant? Which contactor lot went out last month? Three unanswered questions is a clear signal.
Do not migrate everything at once. Start with serial numbers, firmware events and certificates because they carry the risk, and leave purchasing and accounts alone until that first part is steady.
Pick the next batch of chargers and record every serial, board revision, firmware flash and test result in the new system while the old sheets run alongside. Compare after the batch ships.
Charger build record sheet
Each unit gets its own row. The columns are serial number, model, hardware revision of each main board, firmware version flashed, flash date and operator, end-of-line test result, certificate reference, dispatch date and installer site. A second block lists open design changes against the certificates each one touches, naming the engineer responsible and the date it falls due for review.
Open a blank worksheet to printQuestions owners ask
Can a spreadsheet track serial numbers for chargers?
Yes, for a small run. It gets weak once units ship with several hardware revisions and firmware builds, because nothing stops a mismatched entry from being saved. Nobody can query the history quickly.
When does an ERP make sense for a charger company?
When a field fault takes more than minutes to link to its build, or certificates and variants drift apart, or only one person remembers each batch’s board revisions. A linked record pays back then.
Do we need a full ERP or just traceability?
Often traceability comes first, since serials, firmware events and certificates carry the most risk, while purchasing and accounts can follow once those records are steady.
What about firmware stored in a code repository?
Keep it there. The ERP only needs to record which firmware version went on which serial number, on what date and by which operator, because that link is what spreadsheets lose.