eCoC Without ERP Integration: Use Your Existing Vehicle Data

You can plan an eCoC process without first replacing or fully integrating your ERP. The essential question is whether approved vehicle information can be turned into a controlled electronic record, reviewed, signed and submitted through the required route. The best starting method depends on your source data, production volume and the receiving service's available interfaces.

For a manufacturer issuing a few vehicles each month, reviewed manual entry may be practical. A business with repeated configurations may benefit from a controlled import. A factory releasing vehicles continuously may need an API connection. None of these methods removes the manufacturer's responsibility for the technical information. The examples below are implementation recommendations; official source requirements were checked on 16 October 2026.

Separate the legal output from the integration method

The EU framework describes the structured electronic CoC and its exchange, not a requirement to buy a particular ERP product. Implementing Regulation 2021/133 sets the exchange framework. Regulation 2024/1061 addresses secure exchange and arrangements including manual input or upload for small series. Availability and access must still be confirmed for the actual authority route.

For the UK, VCA publishes both portal and API routes and does not mandate a particular commercial or open-source generation product. A portal can avoid a system-to-system connection project, but somebody must still prepare an acceptable UK IVI file. Generating XML and uploading XML are separate jobs.

Compare three workable starting points

These are operating choices rather than fixed volume thresholds. Ten complex bespoke vehicles can require more review than a larger batch of a stable configuration. Compare the time spent preparing, checking and correcting a certificate, together with the consequences of a delayed release. Do not decide from the annual count alone.

Inventory the data you already trust

List the current sources for approved type, variant and version, approval extensions, VIN, production date, masses, dimensions and applicable environmental information. Identify which source is authoritative for each value. An old paper CoC, an Excel workbook and an ERP screen may disagree because they represent different revisions or stages of manufacture.

Separate master data from the actual build. Master data may define approved limits and available variants; production data identifies the individual vehicle. Record the effective revision so a new approval extension does not silently change the meaning of an earlier vehicle record. Where a value is missing, show it as unresolved rather than substituting a plausible default.

Build a small, explicit mapping table

A mapping is more than a list of similar labels. It records the source field, business meaning, unit or code system, transformation and destination meaning. Use the current IVI message book and the recipient's applicable schema to select the actual target element. The following labels are illustrative business fields, not XML element names.

Protect spreadsheet identifiers from automatic conversion, reject unexpected column changes and keep original exports. A source value that cannot be interpreted safely should create an exception for review. Do not let a failed conversion quietly become zero, an empty field or the previous row's value. These controls matter before an API is considered and remain necessary after one is connected.

Run a pilot that includes a correction

Choose representative vehicle families and one deliberately incomplete record. Generate a candidate, review it against the approved source and run the applicable structural and vehicle checks. Then make an authorised source correction, regenerate and repeat the affected checks. This shows whether the team can control changes rather than produce only one good example.

Next test signing and the receiving environment with the required credentials. Retain the file, validation outcome and recipient response together. The EUCARIS IVI model explains the EU exchange route; UK delivery uses the separate VCA service. A successful local import is not evidence that either recipient accepted a record.

Know when an API project becomes useful

Integration becomes attractive when repeated entry, reconciliation or release delays are measurable. An API should have a clear trigger, such as an authorised production release, and a defined result written back to the originating vehicle record. Agree who owns the source, when changes are locked, how rejected records are handled and how uncertain delivery is reconciled.

Do not automate a disputed mapping. Stabilise the field meanings and review responsibilities first, then use the same documented data contract for the connector. This avoids building a faster route for information the team still cannot reconcile. The submission troubleshooting guide is useful when planning those failure paths.

Prepare a reviewable first implementation scope

Bring one sanitised export, the corresponding approval reference, a current CoC example and a list of source owners. Ask the supplier to show the resulting record, a failed import, a correction and the final receiving response. Agree the supported source format and any manufacturer-specific mapping before treating an import as available in production.

Electronic COC Platform manages creation, validation, signing, manufacturer-specific submission and response tracking. ERP, API and import work is scoped around the manufacturer's actual data and requirements. Start with the smallest reliable flow and expand it when the production evidence justifies the extra integration. Implementation scope and pricing should reflect that agreed work, not an assumed requirement to rebuild your ERP.