Introduction
Anyone who ever fixed a paper CoC knows the reflex: wipe the error, print a new sheet. Digitally it works differently. An eCoC (IVI 2.0) is a sealed version of the technical identity of one VIN at one production stage. Once submitted to certain national access points, “delete and redo” is often not allowed.
That sounds strict. For audit and Conformity of Production (CoP) it is clear: you show what changed, when, and who did it.
Version number = do not overwrite
Each IVI carries a version number per combination of VIN and production stage:
- Version 1 — first eCoC for that VIN and stage.
- Version 2+ — correction or update.
You do not overwrite a file. You create a new, qualified sealed version. Authorities use the highest valid version. Earlier ones remain as history — not as the “active” truth.
After submission: some NAPs do not allow delete
After submission to some NAPs — including the KBA under IVI 2.x — you can no longer delete an eCoC. You correct it with a new version for the same VIN.
That is not an On-Road rule; it is how those access points work. Say it honestly:
- Not: “every NAP forbids delete.”
- Yes: “at some NAPs, including the KBA under IVI 2.x, you correct via a new version.”
For routes via other NAPs (for example in an RDW/EUCARIS context): know the local practice, and work with versions anyway. Your dossier stays consistent when registration crosses borders.
What changes versus paper?
On paper, “destroy and reprint” was often the quick fix. Digitally the eCoC is tied to a VIN, a stage and a seal. The registration chain (NAP → EUCARIS → registration) relies on that chain of versions. So the safe habit is the same everywhere: correct = new version, even if a specific NAP technically still allows more.
For trailer builders and bodybuilders that means: plan a “correction step” into your process, the way you plan a re-inspection. Not improvising in a folder named final_final_v3.xml.
Why this matters for CoP and audits
CoP under (EU) 2018/858 asks you to show that production matches the type approval. A digital eCoC archive is not a full shop-floor CoP module — but it is evidence of:
- which data you issued per VIN;
- which corrections followed;
- who signed and when.
Without version history, a correction becomes an argument (“which file was valid?”). With versions, it is a timeline.
On-Road keeps that history and audit log, with a 10-year archive at Ballistix.digital — in line with the retention duty for electronic CoCs.
Practical flow when something is wrong
- Before signing: validate against IVI 2.0 XSD and current ICM (now 3.1). Fix what you can here.
- After signing, before submission: if needed, a new draft version, re-validate and re-sign.
- After submission (where delete is not allowed): new sealed version for the same VIN; submit it; keep references for both.
Never: silently overwrite the old file and hope nobody notices. That clashes with how NAPs and audits work.
Multi-stage: errors propagate
In bodybuilding (chassis + body), each significant stage issues its own eCoC. An error in the base stage flows into later stages. Correcting there often means: fix the base version and realign the bodybuild eCoC. Version numbers per stage keep that manageable — if you use them consistently.
Tip for SMEs working with fixed bodybuilders: agree who issues which version and where the history lives. That avoids two “version 2” files in two mailboxes with no shared audit.
What On-Road does here
On-Road (Certiflow BV) is live SaaS: you create, validate, sign via eID Easy, submit via an EU NAP on the platform, and archive. On a correction you create a new sealed version; the previous one stays visible in history. No overwrite, no silent delete. The platform is built in Belgium with Ballistix (part of Vandelanotte).
Short takeaway
Digital eCoCs are built on versions, not on erasers. At some NAPs — including the KBA under IVI 2.x — delete after submission is not an option. Build the habit: validate before signing, correct with a new sealed version, keep history.
CTA: Want to see the version flow on your own type? Demo — create, check, sign, submit via NAP, archive.