Multistage eCoC: Complete, Incomplete and Completed Vehicles

The EUCARIS Release Notes dated September 5, 2026 changed a set of mandatory-field conditions so that they apply only when StageOfCompletion=C. This matters for incomplete chassis, converted vehicles and vehicles completed through multistage manufacture. Official documents

The following guidance uses the ICM 3.0 release notes alongside the ICM v3.1 document and its version history. After initial onboarding, manufacturers still need to track technical releases and receiving-system requirements and update the affected systems.

C, I and V have different meanings

The official Messagebook defines the completion-stage codes as follows:Messagebook download

Code	Meaning	Template implication
C	Complete	Apply complete-vehicle conditions
I	Incomplete	Further manufacturing stages are required
V	Completed	The vehicle was completed through multistage manufacture

A completed vehicle uses a different code from a complete vehicle. Establish the status from formal approval documents. Vehicle category and completion stage are separate dimensions: two M3 or N3 vehicles may still require different templates.

Version history: what has kept changing

The IVI 2.0 message name does not mean its supporting field definitions and validation conditions are frozen. The following table summarises dated entries in the official ICM v3.1 workbook's VersionInfo sheet and the checks manufacturers should consider. Official documents

Official entry date / ICM version	Main changes	Manufacturer review
2026-02-27 / 2.3	Added version information, rule-code explanations and vehicle-type definitions; completed category-level field indications	Retain a dated rule baseline with field catalogues and validation configurations
2026-03-04 / 2.4	Changed the N1 twin-wheel axle count from forbidden to mandatory	Check N1 templates, upstream data and missing-field feedback
2026-03-09 / 2.5	Changed NRTC fields for N3 from forbidden to optional	Ensure older validators do not reject newly permitted data
2026-03-25 / 2.6	Changed O1/O2 steering-axle and O3/O4 combination-mass rules; relaxed certain electric-power requirements where consolidated power is present	Recheck category prohibitions, alternative power fields and test cases
2026-04-17 / 2.7	Corrected test-family error descriptions and added national or traffic-regulation context conditions for in-service masses	Check mass context and whether error messages match the applicable rules
2026-05-08 / 2.7	Added an O-category air-suspension requirement, changed axle-group, lift-axle and test-family format checks, added coupling approval fields and revised tyre values	Review trailer and coupling mappings, axle-group membership and enumerations
2026-05-18 / 2.8	Changed M2/M3/N1 seating-count treatment and clarified that second-stage manufacturers need not enter first-stage manufacturer addresses	Review seating definitions and previous-stage address conditions
2026-06-14 / 2.9	Added signer-field documentation, corrected hybrid configuration and coupling grouping, and referenced the June 10 XSD	Check signer data, hybrid configurations and XML hierarchy; a documentation addition does not establish when a field first existed
2026-09-05 / 3.0	Made a set of requirements conditional on stage C; corrected multistage approval-number, mass, tyre-indicator and technical-number checks	Validate C/I/V templates and boundaries such as equal masses and zero numbering values
2026-09-28 / 3.1	Changed powered/loadable axle, in-service axle-mass context and parent-bodywork checks; the associated XSD extended emission values	Review affected axle configurations, parent-table generation and enumerations against the receiving NAP's release

Version 2.7 has two different dated entries in the official document, both retained here. These summaries do not replace the complete category, stage and cross-field conditions. Changes include tighter requirements, relaxations, prohibitions and bug fixes.

These are dates recorded in the rule document, not uniform NAP activation dates or a separate legislative amendment for every row. They do not establish that every old template fails or that every vehicle needs the same additional fields.

Track XSD, ICM and Messagebook separately

The supporting documents have independent versions and dates. For example:

• June 10, 2026: the later ICM 2.9 entry references this XSD date. The Messagebook change overview records V2.8 on June 10, including stage-applicability changes for coupling fields.
• September 5, 2026: ICM records version 3.0, while the Messagebook change overview records V2.9, with hierarchy and stage-applicability corrections.
• September 28, 2026: ICM records version 3.1, Messagebook records V3.0, and the XSD is dated September 28. The emission-enumeration additions can be checked across these documents.

See the official ICM VersionInfo and Messagebook ChangeOverview sheets. Download entry point Record the IVI message version, XSD date, ICM, Messagebook and receiving NAP's acceptance and cutover arrangements. “Supports IVI 2.0” alone does not identify the rule baseline used.

What changed in September

ICM 3.0 added the StageOfCompletion=C condition to mandatory requirements across a range of axle, dimension, power, marking and other data fields. ICM v3.1 retains this history in VersionInfo row 7. September Release Notes and ICM

Templates should determine requirements from the category and stage. A complete-vehicle template used for every chassis and final-stage manufacturer can demand facts outside that stage's responsibility.

A field becoming optional under one condition does not remove its other checks. Values, cross-field relationships and category prohibitions can still apply. Nor does the change remove all requirements to reference previous-stage information.

Keep previous-stage approval references consistent

The same release restored the check that a previous-stage approval number must differ from the current approval number. Current rule R99 also uses manufacturer stage, category and completion status to determine the required previous-approval references and related type, variant and version data. ICM R99

Check the stage manufacturer's identity, VIN, stage number, current approval and applicable previous approval against their source documents. Record which vehicle facts changed at the current stage and which retain earlier evidence. Passing XML validation does not establish the truth of those facts or discharge manufacturing responsibilities.

Other boundary checks

The September release also corrected the mass comparison and tyre-production indicator checks and prohibited zero values in a set of technical numbering fields. For the applicable categories, actual mass may equal the technically permissible maximum laden mass. Official Release Notes

Include cases with equal masses, a zero stage number and missing tyre indicators in template verification. Apply the exact category and stage conditions rather than treating these changes as universal requirements.

Manage each stage and version

Keep each stage as a record with its own approval evidence, vehicle facts, XML, validation version and receipt. EUCARIS' implementation guidance says retrieval for a multistage vehicle can return multiple IVIs, using the highest version of each stage. Implementation of IVI

Page 22 of the official setup manual explains correction versioning: correcting previously processed vehicle data increments IviVersionNumber and changes IviReferenceId and IviVersionDateTime. A technical delivery failure alone does not increment the version. An entrance-check rejection that never entered the network can generally retain its version. Establish the receiving status before retrying. Official manual

Check the UK route separately

VCA's current FAQ says incomplete vehicles also require eCoCs. Multistage manufacturers need to complete sections that are mandatory or applicable to their stage; they do not need to consolidate all unchanged or non-mandatory previous-stage sections. VCA guidance

The UK has its own IVI XSD and does not connect to EUCARIS. Vehicle facts and evidence management can be shared, while templates, submission and acceptance must be checked for each route.

Template review checklist

1. Confirm category, C/I/V status and manufacturer stage from approval evidence.
2. Apply mandatory, optional, forbidden and cross-field rules from the current ICM.
3. Verify previous-stage references and retain sources for changed facts.
4. Validate samples covering the relevant stages and boundary cases.
5. Confirm the NAP or VCA release and complete external testing and onboarding.

For the subsequent axle and parent-table changes, see the ICM 3.1 and XSD review guide.

Make standards tracking part of system maintenance

Assign responsibility for reviewing official releases and the selected NAP's notices after onboarding. Each change should lead to an impact review, an update where needed and verification before production submission. The following maintenance steps are recommendations based on the history above:

1. Track and retain official releases. Review current and archived EUCARIS documentation and NAP acceptance, testing and production-cutover notices. Keep the original files, dates, versions and hashes, with an owner for assessment and implementation.
2. Identify affected vehicles and stages. Review mandatory, forbidden, value and hierarchy changes by category, C/I/V, propulsion and submission route. Identify the affected templates and pending VINs. Also check whether older validators still reject data allowed by relaxed rules.
3. Update the affected systems together. Review field catalogues, vehicle templates, XML generation, XSD/ICM validation and error messages. Coordinate with PLM, MES or ERP owners when additional facts are required. A validator update cannot supply data missing from the template, and a UI change alone cannot repair backend generation.
4. Run targeted regression and receiving-system tests. Cover relevant stages and boundaries, such as two axles, omitted parent tables, missing mass context, equal masses and new values. Use the NAP test environment where needed and retain results and receipts.
5. Coordinate cutover and preserve history. Confirm accepted versions and activation dates separately for testing and production, then enable the configuration and recheck pending submissions. Do not overwrite processed historical XML when templates change; handle data errors through the receiving system's correction procedure.

Each submission should remain traceable to its template, rule package, validation result and external receipt. This supports new submissions under the applicable requirements and explains the basis used for historical records. Pre-submission validation does not replace onboarding, signing requirements or the receiving system's result.

Official sources

• EUCARIS eCoC Documentation: Archived versions, 20260905 - ReleaseNotes September 2026.pdf, Final.
• On the same page: ICM v3.1, VersionInfo rows 2 to 53, recording the history from February 27 to September 28, 2026; rules including R99 supply detailed conditions.
• On the same page: Messagebook V3.0, ChangeOverview rows 2 to 10 for the June and September changes cited here, and completion-stage enumerations. The history is limited to the records in these files and is not a NAP activation schedule.
• On the same page: eCoC IVI setup Manual v1.8.pdf, June 14, 2026, page 22.
• EUCARIS Implementation of IVI: multistage retrieval and correction notifications.
• VCA eCoC: incomplete-vehicle and multistage FAQs, with the relevant change-log entry dated August 28, 2026.