Before resubmitting an eCoC, establish whether the previous record was rejected, accepted or left with an unknown delivery outcome. Each state needs a different response. Repeatedly uploading a file without reconciling the vehicle, stage and receiving-system status can create duplicate records while leaving the original error unresolved.
Sources checked: 16 October 2026. The workflow below is a recommended operational model. Follow the current schema guidance and your selected NAP or VCA submission contract.
Rejection, correction or retry: which problem are you solving?
Scroll the table horizontally to view all columns.
| Observed state | First investigation | Controlled next action |
|---|---|---|
| Local validation fails | Field, unit, code or approval mismatch | Correct source data and validate before release |
| Destination explicitly rejects the file | Exact error, submitted version and account context | Resolve the cause and use the destination’s resubmission rules |
| Destination accepts, then a value is found wrong | Affected data, vehicles, stages and possible downstream use | Approve and submit a traceable correction |
| Connection times out or response is missing | Whether the destination already created a record | Reconcile status before retrying |
| Same VIN appears more than once | Stage, approval and version for each record | Distinguish legitimate records from actual duplicates |
Keep the raw error response and submitted file. An operator’s description such as “XML problem” removes the evidence needed to identify whether the failure arose in source data, validation, signing, account permissions or delivery.
Schema version and certificate version are different
The EReg IVI 2.0 guidelines, section 1.12, distinguish the XSD version from a corrected IVI message. Their correction rules use a new reference ID, increment the IVI version, update the issue timestamp and retain the original XSD version. Confirm that the applicable destination contract and current schema guidance match your case.
Do not solve a vehicle-data correction by silently migrating to another schema. Keep a separate change process for software or schema upgrades, including regression samples and destination tests. Otherwise, an engineering correction can become entangled with a technical migration.
The VCA guidance also explains revised IVI submissions using IviVersionNumber. A filename change alone is not a revision strategy.
A seven-step eCoC correction workflow
- Identify the record. Capture VIN, manufacturing stage, approval reference, destination and the last known submitted version.
- Preserve evidence. Retain the original signed XML, validation report, transaction reference and receiving response.
- Find the source cause. Trace the wrong value to the source system, mapping, manual entry or approval configuration.
- Assess impact. List affected vehicles and review whether another stage or downstream party needs notification.
- Authorise the revision. Record the reviewer, changed values and reason; apply the destination’s version rules.
- Validate, sign and submit. Check the final output and use the intended environment and manufacturer account.
- Reconcile and close. Link the destination’s result to the new file and retain the earlier history.
Correct the source where appropriate before regenerating the document. Patching one XML file while leaving the wrong ERP mapping active can reproduce the same defect in the next production batch.
Worked example: a mass value copied with the wrong unit
Illustrative case: an import mapping treats a technical value in one unit as if it were already in the required unit. A reviewer discovers the error after some records have been accepted. The team freezes the affected mapping and identifies all vehicles processed under that mapping revision.
Engineering confirms the correct values; homologation checks the approved configuration; the release owner approves the affected-record list. Operations then processes corrections according to each destination’s rules. Closure requires receiving-system evidence for each revised record and a mapping test that prevents recurrence.
This approach produces two deliverables: corrected conformity records and a repaired production process. An upload success message proves neither by itself.
How do you avoid duplicate submissions after a timeout?
Maintain an internal submission identifier and store the destination transaction reference as soon as it is returned. If a connection fails, inspect the available destination status or portal record before sending again. Where a service offers idempotency or a dedicated retry contract, use it exactly as documented; do not invent a universal rule across NAPs and VCA.
Keep the business state “outcome unknown” visible until reconciliation. It is safer operationally than labelling every timeout “failed” and allowing automatic reissue. Define an escalation route for cases that cannot be resolved through the available status functions.
How do IVI, AVI and later manufacturing stages relate?
EUCARIS terminology distinguishes initial vehicle information from subsequent actual vehicle information. A corrected IVI, a later vehicle-data change and a new manufacturing-stage record still need to be classified using the applicable technical process. Do not rename every correction “AVI” without checking the contract.
For multi-stage vehicles, trace the effect of a correction across the handover chain. Ask whether the later manufacturer used the affected value, whether its output changes and who must close the downstream action. Preserve the assessment even when the decision is that no later-stage change is required.
What should the correction register measure?
- Open cases by cause, owner and vehicle programme.
- Records with an unknown destination result.
- Time to identify the source error and time to confirm the corrected result.
- Repeated defects under the same mapping or template revision.
- Corrections awaiting another manufacturer or authority response.
Use those measures to find process weaknesses. Avoid measuring success only by the number of files uploaded; a rising upload count may reflect repeated retries rather than completed vehicle records.
Frequently asked questions
Can we overwrite the old XML in our archive?
Preserve the original and corrected files with their relationship. Overwriting removes the evidence of what was signed, submitted and accepted at each point.
Does the same VIN always mean a duplicate?
No. Check manufacturing stage, approval and record version before deciding. The vehicle identifier alone does not describe the full record history.
Should every rejection increment the IVI version?
Apply the receiving system’s rule for the actual state. A rejected technical attempt and a correction to an accepted record should not be assumed to follow identical version handling.
When is a correction complete?
When the source issue is addressed, the authorised replacement is linked to its evidence, the destination result is reconciled and any consequential downstream actions have been closed.
Review your exception process
Combine this workflow with the multi-stage handover guide and the submission guide. Ask Anemon Engineering to review a redacted rejection or correction case and define a repeatable closure process.
Summary
Correct the source of the error, preserve the previous evidence and confirm the new destination result. A closed correction links the vehicle, stage, changed data, authorised revision, signed file and receiving-system record without losing the history.
