Correcting a submitted eCoC is a controlled revision, not an edit to an archived file. Identify the exact submitted record, determine whether it was rejected, accepted or already used for registration, correct the accountable source and follow the receiving route's version and notification rules. Preserve the original artifact and every subsequent result.
Manufacturers discover errors at different points: an invalid value may be rejected before storage, while an incorrect technical fact may emerge after registration. Those situations require different decisions even when the same VIN is involved.
First establish what happened to the original submission
| Known state | First action | Evidence to retain |
|---|---|---|
| Rejected before acceptance | Read the rejection, correct its cause and use the documented resubmission process. | Rejected input, error detail and corrected attempt. |
| Accepted; no registration use confirmed | Ask which revision or replacement procedure applies. | Acceptance reference, prior version and new receiving result. |
| Already used for registration | Coordinate with the responsible authority on correction impact and notifications. | Registration context, correction reason and authority instructions. |
| Outcome unknown | Reconcile the existing attempt before sending another file. | Operation reference, submission time and status enquiries. |
Separate IVI format version from record revision
An IVI schema family and an individual record's revision are different concepts. The EReg NAP demonstration FAQ discusses corrections in the same IVI format version as the original eCoC, including older records. That does not mean the corrected business record keeps its previous revision number.
VCA identifies the IviVersionNumber field as the mechanism used to accommodate updated files and check duplicate submissions. Follow its current schema and instructions. Do not invent a cross-market revision convention and assume that every NAP, national database and VCA interprets it identically.
Correct the source and regenerate the artifact
Suppose a fictitious record V-001 contains a technical value copied from the wrong vehicle configuration. Homologation confirms the correct value and approval evidence. Update the controlled source, identify other records that inherited the same error, then generate a reviewed candidate through the applicable mapping.
Retain the original value, corrected value, reason, source reference, reviewer and affected vehicle list. This lets the team distinguish a single-vehicle problem from a template problem. Editing only the XML would leave the source wrong and make the next generation repeat the error.
Do not modify the submitted signed file
A submitted artifact is part of the evidence history. Keep it immutable. Produce the corrected candidate separately, validate it, obtain the required authorization to sign or seal and verify the returned artifact. Associate that artifact with the correction request and later response.
Signature integrity and factual accuracy answer different questions. A cryptographically valid file can contain a wrong vehicle fact; a corrected fact inserted into a signed artifact can invalidate its signature. The XML signing guide explains why the exact candidate matters.
Account for downstream distribution and registration
EUCARIS describes correction notifications distributed through the network. Its implementation guidance also distinguishes receiving a notification from the national process that assesses a correction's impact. A local software status therefore cannot establish that every downstream registration record has been amended.
Ask the operator what confirms receipt, technical acceptance and completion of the correction procedure. If the vehicle was already registered, identify the responsible registration authority and the consequences of the changed field. Avoid promising a universal deletion or cancellation function: retention and correction mechanisms are route-specific.
Rehearse retries without creating conflicting revisions
A delayed response is not automatically a rejection. If a correction times out after transmission, check the receiving record before sending another revision. Preserve the operation reference and exact file identity so an operator can reconcile late responses without confusing the original, corrected and retried artifacts.
Use a pilot containing one rejected correction, one accepted revision and one unknown-outcome case. For each, require the team to explain which source changed, which candidate was signed, what the receiver reported and which action remains open. These are editorial test recommendations, not official error codes.
Keep a correction register that another team can audit
- Vehicle and approval context; original artifact and revision.
- Discovery date, error reason, corrected source and accountable owner.
- Schema package, new candidate, validation and signing evidence.
- Submission route, operation reference and receiving response.
- Registration impact, authority instructions and closure decision.
Digital CoC brings certificate history and workflow follow-up together so the team can associate preparation, signing and delivery work with the appropriate record. Discuss the certificate management workflow using your actual correction scenario. For a record that cannot be retrieved, first follow the missing eCoC investigation before assuming its contents need revision.