EUCARIS ICM 3.1: new mandatory eCoC fields, tighter checks, and why unmonitored submissions will be rejected
The IVI Checking Module (ICM) is the validation rule set that EUCARIS publishes and that the National Access Points apply to every incoming IVI 2.0 eCoC. If an XML file fails a single rule, the submission is rejected and the vehicle cannot be registered from that record. Version 3.1 was published on 28 September 2026, three weeks after version 3.0 of 5 September. This concerns submissions to EU National Access Points; the VCA's UK scheme runs its own rule set, so UK manufacturers are affected for the vehicles they export into the EU.
What changed in version 3.1
The September 28 release is small in size but every item in it can turn a previously accepted file into a rejected one:
- A new IVI XSD 2.0 with an extended enumeration for ExhaustEmissionLevel. Files generated against the previous schema can fail schema validation.
- PoweredAxle is now mandatory for the M, N, T and C vehicle categories.
- The LoadableAxleIndicator rule was corrected: the indicator must be N where NumberOfAxles is lower than 2 (previously lower than or equal to 2).
- InServiceMaximumPermissibleLadenMassAxle can no longer be given on its own. It now requires InServiceMaximumPermissibleLadenMassAxleCountry or InServiceMaximumPermissibleLadenMassAxleTrafficRegulation.
- The BodyWorkTable can no longer be omitted when rules make its underlying fields mandatory. The table itself must now be present under the same conditions.
And in version 3.0, three weeks earlier
Version 3.0 of 5 September was a larger release, driven by the multistage discussions in the EReg working group:
- More than 50 fields, covering axles, dimensions, markings, energy convertors and vehicle class, became mandatory only for complete vehicles (StageOfCompletion = C). This eases submissions for incomplete and completed vehicles, but it also changes which fields a complete vehicle must carry.
- The multistage type-approval check was set back to its original form: PreviousStageTypeApprovalNumber must differ from TypeApprovalNumber.
- ActualMass must be less than or equal to TechnicallyPermissibleMaximumLadenMass for the M, N, O and L categories. The missing or-equal-to was added.
- TyreFittedProductionIndicator must carry a value for every tyre.
- A VehicleIdentificationNumber for the T, C, R and S categories (Regulation 167/2013) may now contain I, O and Q.
- Zero is no longer accepted in the technical numbering fields: ManufacturerStageNumber, GearNumber, FinalDriveNumber, AxleNumber, TyreNumber and eight others.
- Corrections to the nesting paths of rules R214 and R215, the placement of CategoryHybridElectricVehicle, swapped levels for TypeINox and TypeINmhc, and a timezone bug in the production-date check.
Nine releases in seven months
This is not a one-off. Since the ICM gained version information in February 2026 it has moved from 2.3 to 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0 and now 3.1. Earlier releases also added mandatory content: AxleAirSuspensionOrEquivalentIndicator became mandatory for the O category, MechanicalCouplingCanBeFittedApprovalMark and ApprovalNumber were added, SignerName was added, TestFamilyIdentifierValue gained format checks, and a new IVI XSD 2.0 dated 10 June replaced the previous schema.
In practice the rule set changes roughly once a month, and what counts as a mandatory field is a moving target. An integration built once against a given ICM version is correct only until the next release.
Rejection, not a warning
The National Access Point does not accept a file that fails an ICM rule. An eCoC that passed in August can fail in October with no change on the manufacturer's side. For a manufacturer generating IVI XML from a template, a conversion tool or an in-house script written against an older ICM version, the first sign is usually a rejection at the NAP, and sometimes a vehicle held at the registration desk.
The cost of a mistake is also rising. As we described in our note onthe KBA timeline for IVI 2.0, from version 2.x submitted records can no longer be deleted; the only remedy is a correction record. Getting the file right the first time matters more than it used to.
How CoCDesk handles ICM releases
Keeping up with the ICM is part of what CoCDesk does, not something our customers have to do themselves:
- We track every ICM and XSD release from EUCARIS and roll the new rules into the platform's validation engine quickly after publication, so CoCDesk validates against the rule set the National Access Points are actually running.
- Every eCoC is checked against the current ICM rule set and XSD before it leaves your system. An incomplete or non-conforming file is never sent, so it is never rejected.
- New mandatory fields are surfaced in the interface: the field is highlighted and the rule explained, so your team knows exactly what to add and why.
- When a field becomes mandatory it is mapped once from your ERP, MES or type-approval data. Nobody edits XML by hand.
- The StageOfCompletion logic from version 3.0 is applied automatically, so incomplete, completed and complete vehicles are each validated against the right subset of rules.
- Every submission keeps a timestamped record of the rule version it was validated against, ready for Conformity of Production checks.
Is your eCoC pipeline ready for ICM 3.1?
If your eCoCs are produced from a template, a converter or a script, version 3.1 is a good moment to check them. Book a live demo and we will run your own vehicle data through the current rule set.
Book a live demoReady to meet the UK eCoC deadline?
Book a free demo and see how COCDESK can have your eCoC process production-ready before the VCA mandate takes effect.