IVI 2.0 XML is the structured, machine-readable model used to express electronic vehicle conformity data. Passing an XSD does not prove that the values are correct for the approved type or individual vehicle. A robust eCoC process combines structural validation, cross-field business rules and homologation-source validation.
For the wider timeline, see the 29 November readiness guide. This article concentrates on data creation and control.
What does IVI 2.0 standardise?
The model organises vehicle identity, manufacturer, approval, type–variant–version, dimensions, masses, powertrain and environmental data in a defined hierarchy. Applicability varies with category, powertrain, approval scheme, build stage and target authority. The VCA, for example, bases UK IVI on the EU structure while adding GB and UKNI values; the target authority's current XSD and release notes therefore remain decisive.
Where should the data come from?
| Data group | Likely source | Critical control |
|---|---|---|
| VIN and production | ERP / manufacturing system | Uniqueness, WMI and date consistency |
| Type–variant–version | Homologation record | Configuration within approval scope |
| Mass and dimensions | Approval and product configuration | Category and arithmetic relationships |
| Powertrain | Technical file | Units and conditional fields |
| Emissions / consumption | Approval, tests and relevant VECTO data | Applicable legislation and scope |
Three validation layers
1. XML and XSD
Checks element order, types, mandatory elements and permitted values against the correct schema version.
2. Business and cross-field rules
Checks relationships such as category versus body, fuel versus emissions fields, axle count versus axle values, mass calculations and build-stage applicability.
3. Homologation truth
Confirms that values match the current approval, extensions and vehicle configuration. This is where homologation expertise matters most.
Valid XML is necessary for a correct eCoC, but it is not sufficient.
Why type–variant–version and VIN are central
Technical values cannot be generated reliably until the VIN has been matched to its approved configuration. Option codes, effective approval extension, body and powertrain combinations must be resolved before the IVI record is created.
Manual, file import or API?
| Method | Best fit | Main risk |
|---|---|---|
| Controlled manual input | Low volume | Repetitive entry errors |
| Template import | Medium volume | Version or column drift |
| ERP/API | High volume | Scaling incorrect master data |
| Hybrid | Mixed brands or maturity | Unclear approval roles |
The safest route is usually to validate representative vehicles before increasing automation. The Electronic COC Platform supports a progression from controlled entry to file and API integration.
Corrections and version control
Record what changed, why, who approved it, which version was signed and what response came from the authority. A corrected submission should not erase the earlier audit trail.
Validate a representative file. Use our project form to define a pilot covering one vehicle family, data mapping, validation rules and the appropriate integration route.
Worked example: turning a VIN into trusted eCoC data
When production creates a VIN and as-built configuration, the first control is to match that record to the approved type–variant–version. If no reliable match exists, the record should enter an exception queue rather than inherit a default version. Once scope is established, fields are taken from their accountable sources and transformed into the units and code lists of the target IVI release.
Schema, cross-field and homologation checks then run in sequence. Axle count must agree with axle values; fuel and powertrain must activate the correct environmental fields; vehicle status must agree with build stage. Signing should occur only after these controls pass. The operational output is not merely XML: it also contains source versions, rules applied, approver and file digest.
Deliverables from a useful pilot
- A scope matrix covering representative families and exceptions.
- Source, transformation, owner and evidence for every IVI field.
- The target XSD and an applicable rule catalogue.
- Positive, negative and boundary test cases.
- A sample signed record and validation report.
- Error classification from authority response to root cause.
- An interface contract and change-management plan for ERP/API integration.
Without these outputs, an XML generator may reproduce one incorrect master-data assumption across hundreds of vehicles. Pilot success should be measured by proven lineage and approval scope, not file count.
IVI 2.0 XML and eCoC data validation — Explore Electronic COC for IVI data, validation rules and integration options.
Frequently asked questions
Is IVI 2.0 a PDF format?
No. It is an XML-based structured data model. A human-readable view is a separate presentation layer.
Can Excel be used?
A controlled template can be a source at lower volumes, but direct conversion without homologation validation is unsafe.
Does every authority accept exactly the same file?
The base model may be shared, but XSD versions, local values, signature and submission rules must be checked.
Where are the technical sources?
Use EUCARIS IVI information, applicable legislation, VCA UK IVI documents and current NAP or granting-authority guidance.
Summary
IVI 2.0 is the structured data model used to carry vehicle conformity information electronically. A reliable process does more than produce XML that passes an XSD: it proves that each field comes from an accountable source, is consistent with related fields, matches the valid type approval and remains traceable through corrections.
