What Is EUCARIS? Vehicle Data Exchange and eCoC

EUCARIS means European Car and Driving Licence Information System. It enables national authorities to exchange vehicle and driving licence information. It connects national systems rather than acting as a single European vehicle database. For an eCoC project, the distinction matters: preparing a manufacturer’s electronic certificate, receiving it at a National Access Point and exchanging it between authorities are different responsibilities.

Who uses EUCARIS?

The network serves governmental authorities. A manufacturer planning electronic Certificate of Conformity delivery should therefore start with its chosen receiving service and onboarding requirements. Asking for “an EUCARIS connection” without identifying that receiving service can leave the project team discussing the wrong interface. The immediate manufacturer task is to prepare a valid record and deliver it through an authorised route.

EUCARIS also supports activities beyond electronic certificates. A registration-data enquiry and an eCoC submission may both involve vehicle information, but they are not interchangeable services. Before defining an integration, write down who sends the message, who receives it and what result the sender expects. This simple description helps procurement, homologation and software teams agree on the actual requirement.

EUCARIS, IVI, eCoC and NAP: the difference

Within this workflow, eCoC is the electronic conformity record, IVI means Initial Vehicle Information, and NAP means National Access Point. The NAP is the receiving route used by a manufacturer; EUCARIS supports the exchange between authorities. See the official IVI implementation guidance for the terminology and responsibilities.

Keep those names separate in specifications and acceptance criteria. For example, “XML generated” describes a local output. “Submission received” describes a response from the receiving service. Neither statement, on its own, establishes that every later authority process has completed. A useful status model records the outcome that was actually returned, together with its reference and the file version involved.

How a manufacturer should prepare a submission

A practical preparation sequence begins with the approved vehicle information. Select a representative vehicle and confirm the VIN, approval reference and relevant technical values against the controlled source. Identify the IVI specification required by the chosen receiving service. Then map the source fields, generate the XML and check the resulting record before applying the required signature or seal.

Our eCoC NAP submission guide explains the manufacturer-facing preparation. For the file checks themselves, use the IVI 2.0 XML validation workflow. These are separate review steps because a well-formed file may still contain incorrect vehicle information, and a correct record may still be sent under the wrong account or to the wrong environment.

A practical example: a rejected vehicle record

Suppose a submission response identifies an inconsistent approval reference. First retain the submitted file and the complete response. Compare the reference with the approved source, then determine whether the problem came from source entry, field mapping or file generation. Correct the responsible step and create a new controlled output. This is a troubleshooting example, not a description of a universal authority error code.

Before resubmitting, check the receiving service’s correction and duplicate-handling rules. Repeatedly sending the same file without understanding the response makes diagnosis harder. The operator should be able to see which attempt is current, why the previous attempt failed and whether the later response actually resolves the problem. A transport acknowledgement should not silently become a final acceptance status.

What to agree before choosing software

Ask the supplier to demonstrate one representative record through preparation, validation, signing and response review. Establish which actions use the manufacturer’s account, what onboarding remains with the receiving authority and how an operator can inspect a rejected submission. Request a clear explanation of the supported scope rather than relying on a broad “EUCARIS compatible” label.

For a pilot, define evidence before defining success: the agreed sample record, validation output, exact submitted artifact and receiving response. Include a failed case as well as a successful one. That gives the team a realistic view of daily operations, including who corrects a record and who decides that a submission is ready to repeat.