Technical resource for Austrian vehicle manufacturers preparing Electronic Certificate of Conformity workflows, IVI 2.0, IVI XML, EUCARIS data exchange, XMLDSig and eIDAS electronic seal processes.
Frequently asked questions
What is an eCoC?
An eCoC is an electronic Certificate of Conformity: a structured digital record that connects a specific vehicle to the approved type, variant, version and technical configuration declared by the manufacturer. It is not just a scanned CoC or a PDF. In a controlled manufacturer process, the eCoC record is created from governed vehicle data, checked against approval references, generated as structured XML where required, signed or sealed where the workflow requires digital trust, and retained with evidence for later review.
What is the purpose of a Certificate of Conformity in Austria?
In Austria, as in other EU markets, Certificate of Conformity information is relevant because registration and approval processes rely on reliable proof that a vehicle corresponds to an approved configuration. Austrian public registration guidance lists a valid Certificate of Conformity, type-approval certificate, single approval or an approval-database data extract among documents relevant for initial registration. For manufacturers, the practical point is that CoC data must be complete, consistent and traceable before it supports downstream registration or data exchange activity.
What is IVI 2.0?
IVI stands for Initial Vehicle Information. IVI 2.0 refers to a structured model for exchanging vehicle information linked to electronic Certificates of Conformity. It uses defined data elements rather than free text, so VIN information, manufacturer data, approval references, technical attributes, multi-stage data and release context can be processed in a machine-readable way. The hard part is not only creating a file. The hard part is governing the source data before the file is generated.
What is IVI XML?
IVI XML is the structured XML representation used to carry Initial Vehicle Information. In an eCoC workflow, IVI XML should be generated from validated manufacturer records, not assembled manually at the end of the process. The XML needs the correct field structure, but also the correct regulatory meaning: the VIN, approval reference, variant, version and technical values must match the vehicle configuration and the applicable approval data.
What is EUCARIS?
EUCARIS is a European information exchange mechanism used by vehicle and driving licence registration authorities. In the IVI context, EUCARIS describes services through which digital CoC information can be exchanged. It should not be confused with a manufacturer application or a central product database. For an Austrian manufacturer, EUCARIS is part of the wider exchange environment, while the manufacturer-side task is to prepare reliable, validated and signed data that can support the applicable external process.
Does ElectronicCoC replace an Austrian authority?
No. ElectronicCoC does not replace Austrian authorities, provincial approval bodies, registration offices, EUCARIS, National Access Points, technical services or trust service providers. It operates on the manufacturer side. Its role is to help teams organise approval references, vehicle data, IVI XML generation, validation, signing readiness, corrections and audit evidence before data is used in the relevant official process.
What is vehicle type approval?
Vehicle type approval is the regulatory framework that confirms a type of vehicle meets applicable technical requirements. For an eCoC, type approval is the foundation because the certificate must connect the individual vehicle to the approved type, variant and version. A manufacturer cannot treat an eCoC as a standalone document. It is an output of approval control, production data quality, technical consistency and release governance.
How does Austrian vehicle registration relate to eCoC data?
Austrian registration guidance shows why approval information and CoC records matter operationally. Initial registration can involve proof of approval or approval documents, including a valid Certificate of Conformity or an approval-database data extract for vehicles with EC type approval. The manufacturer-side eCoC process therefore needs to support reliable downstream data use. It should make the approval reference, VIN, version, technical values and correction history clear before any external registration-related activity depends on the data.
What is the Austrian approval database context?
Austrian public guidance for imported vehicles with EU type approval refers to approval data being entered in the Austrian approval database before registration. This does not mean that every manufacturer-side eCoC platform is integrated with that database. It means that Austria is a data-sensitive registration environment where approval data quality, correct references and reliable extracts matter. ElectronicCoC helps manufacturers govern the upstream data record; official data entry and acceptance remain governed by the applicable Austrian process.
What happens when a vehicle does not have EU type approval in Austria?
Austrian public guidance indicates that vehicles without EU type approval can require single approval from the competent provincial governor, with further information available through technical test centres of the relevant provincial government department. For manufacturer eCoC planning, this is a reminder not to generalise. EU whole vehicle type approval, single approval, import and special vehicle scenarios may need different documentation and review paths. The platform should keep the approval route visible rather than forcing all vehicles into one workflow.
What is XMLDSig?
XMLDSig is the XML Signature standard. It is used when an XML document needs embedded or associated evidence that helps prove integrity and signing identity. In an eCoC process, XMLDSig is relevant because structured vehicle data may need to be protected after release. If a signed XML file changes, the signature evidence can show that the signed content no longer matches. This is essential when a certificate record becomes part of a regulatory data exchange.
What is an electronic seal?
An electronic seal is a trust-service mechanism used by a legal person, such as a company, to support evidence of data origin and integrity. In an eCoC workflow, the seal can help show that a certificate package was issued by the expected organisation and that the data has not been changed after sealing. The operational design must define which legal entity seals the data, which certificate is used, who can approve release and how the sealed file is stored.
What is the difference between advanced and qualified electronic seals?
Advanced and qualified electronic seals provide different assurance levels under the eIDAS trust framework. A qualified electronic seal has a stronger legal presumption around origin and integrity because it is based on qualified trust services and qualified creation requirements. The appropriate level depends on the receiving process, legal context and trust-service setup. For eCoC projects, the key is to design the seal workflow early, not bolt it on after XML files are already being generated.
Is eIDAS relevant for Austrian eCoC workflows?
Yes, eIDAS is relevant because Austria is an EU Member State and electronic signatures, seals and trust services operate under the EU trust-services framework. That does not mean every eCoC use case requires the same seal type. It means manufacturers should treat authenticity, integrity, non-repudiation and auditability as part of the eCoC architecture. Signing roles, certificate ownership, provider management and archive rules should be defined before production rollout.
How are eCoC corrections managed?
Corrections should be treated as controlled changes, not informal edits. A correction workflow should show what changed, why it changed, who approved it, which source system was updated, whether IVI XML was regenerated, whether a previous signature or seal is superseded and which version remains archived. This is especially important when a vehicle record has already been used for registration support, delivery to a partner or internal audit evidence.
What data is required for an electronic Certificate of Conformity?
The exact dataset depends on vehicle category, approval route and implementation model. Common manufacturer-side data includes VIN, manufacturer identity, type approval number, extension, variant, version, vehicle category, masses, dimensions, axles, bodywork, propulsion or energy information, emissions data where relevant, completion data, multi-stage references and release metadata. The most important requirement is consistency: the data must match the applicable approval and the physical vehicle configuration.
How are multi-stage vehicles handled?
Multi-stage vehicles require a structured link between previous-stage approval data, inherited technical values and final-stage changes. A body builder or converter may receive an incomplete vehicle from a chassis manufacturer and then modify weight, dimensions, bodywork or equipment. The final eCoC workflow must show what was inherited, what was changed, which approval reference applies at each stage, who owns each value and which final record was released.
Why is XML used for eCoC data?
XML is used because it can represent structured, machine-readable information with defined elements and validation rules. That matters for vehicle compliance because free text and spreadsheets are hard to validate consistently across authorities, manufacturers and systems. XML makes it possible to check mandatory fields, formats, references and relationships. It does not guarantee correctness by itself, so it must be paired with source-data governance and regulatory validation.
What causes IVI validation failures?
Validation failures often come from missing mandatory fields, incorrect formats, inconsistent approval references, wrong variant or version values, mismatched technical attributes, unhandled multi-stage data, obsolete source records or manual edits made outside the controlled process. The best response is not only to fix the exported XML. Teams should trace the failed value back to the owning source and correct the process that produced it.
How should Austrian manufacturers start an eCoC project?
A practical starting point is a controlled pilot: one vehicle category, one approval family, one production route or one multi-stage scenario. The team should map approval data, source systems, VIN creation, technical values, validation rules, signing roles, correction paths and archive requirements before automation. This reduces the risk of building an XML generator before the organisation understands its data responsibilities.
Can ElectronicCoC connect to ERP or PLM systems?
ElectronicCoC is designed to support integration with internal manufacturer systems such as ERP, PLM or production data sources. The integration should follow a clear data-governance model: which system owns which value, which transformations are allowed, how exceptions are handled and which fields require homologation approval before release. Integration should make compliance stronger, not bypass review.
Who should own eCoC governance inside the manufacturer?
Ownership is usually shared. Homologation teams own approval interpretation, technical teams own data meaning, production or ERP teams own manufacturing records, quality teams own consistency controls, IT owns integration and security, and compliance teams own auditability and release discipline. A mature eCoC process makes those roles explicit so that errors are routed to the team that can actually correct the source.
Is this page for consumers requesting a private CoC?
No. This resource is written for Austrian vehicle manufacturers, body builders, multi-stage manufacturers, homologation teams and compliance departments. It explains manufacturer-side eCoC compliance, IVI 2.0, EUCARIS exchange concepts, XMLDSig, eIDAS electronic seals and multi-stage vehicle governance. It is not a consumer page for ordering an individual CoC document.