eCoC becomes mandatory on 29 November 2026. Get set up before the deadline.Get started →
Back to the blogGuide

Why "Save as XML" in Word doesn't make an eCoC

4 September 2026 · CoC AutoDocs

The most common first attempt at an eCoC goes like this. The office opens the Word certificate of conformity they have always produced, chooses File, Save As, picks "XML Document", and uploads the result to the VCA portal. The portal answers:

Invalid xml. Unexpected root element 'package' in namespace 'schemas.microsoft.com/office/2006/xmlPackage'. Expected 'InitialVehicleInformation'.

It reads like a fault. It is actually a precise description of the problem, and it is worth understanding, because it explains what an eCoC is.

What Word saved

Word's "Save as XML" wraps the whole document, formatting and all, in a Word package. It is still your document, just in a different container. The portal is telling you it opened the file and found a Word package where it expected something called InitialVehicleInformation.

What the VCA expects

InitialVehicleInformation is the root of the IVI format, the EU's structure for electronic Certificates of Conformity, which the UK has adopted for its eCoC service. It is not the certificate as a document. It is the data from the certificate, with every fact in its own labelled slot: the VIN in one, each dimension in another, each axle mass in another, the approval number and date in theirs. Nothing about fonts, tables or page layout survives, because none of it matters to the registration system reading the file.

So an eCoC is not a converted document. It is your certificate's information, restructured into the VCA's schema.

The mistakes that get a correctly-shaped file rejected

The VCA publish the schema, the XSD, on their eCoC page, and checking a file against it before uploading saves a great deal of grief. The errors that turn up most often:

  • Wrong codes. The UK scheme is written GB, not UK. Left-and-right-hand traffic is BOTH, not B. The approval authority is g11. Every code list in the schema is exact.
  • Field names and order. The schema is strict about what each element is called and where it sits. A field that is right but misnamed is rejected.
  • Blank boxes. If the Word certificate has an empty box, a careless converter reads the next box's text as the value. An approval date filled with a stray sentence will pass a casual glance and fail the schema. Push a deliberately half-finished certificate through any tool you use and see what comes out.
  • Dates and numbers. ISO dates, whole millimetres and kilograms, and axle masses that add up to the mass in running order.

The signature

The schema makes a digital signature mandatory, as the last element of the file. Not a scan of a signature: a certificate-based XML signature in the XAdES form. A file without one fails validation at the upload stage, before the portal has read any of the vehicle data. The VCA currently check that a signature is present rather than verifying the certificate behind it, which means a test key gets you through the test portal today, but the requirement points at a proper company certificate for real submissions.

Test on vehicles that don't matter

The VCA run a test environment alongside the live portal. Use it, with vehicles built before the mandatory date or files made for the purpose, until every upload comes back Success. Only then put real vehicles through.

CoC AutoDocs exists so an office never has to learn any of this: the form asks for the facts, checks them against the schema, signs the file and hands you something the portal accepts.