JSON (Java Script Object Notation) is used for the syntax of the data schema in this specification, JSON schema is used for the validation of the data. The currently valid e-CoC schema can be found here https://schema.e-coc.org/e-coc.json

For a better understanding of the rather abstract data format and its application, some real examples of companies participating in the DIN SPEC 9012 workgroup can be found under the menu Use Cases.

Main Parts

Below is a brief description of the main components and most important parameters of the data structure that are necessary for a basic understanding. The complete and latest description can be found on the website at https://doc.e-coc.org

Main Parts of the e-CoC data schema


The e-CoC is identified by a creator-specific identification number (Id) and additionally by a UUID generated by the creator. The advantage of the UUID is that it is unique, which means that it can be uniquely identified at the recipient.


The EcocData block contains the metadata of the e-CoC according to the DataLevel used.


In order to keep the hurdle for starting to use the standard as low as possible and to use the standard as quickly as possible, various data levels have been defined, which can be transmitted using the e-CoC. For many applications, even a minimal amount of data with the embedded PDF certificate is completely sufficient (this corresponds to DataLevel A) and already represents a considerable process improvement. The figure below shows the differences in content and used attributes in color.

DataLevel of e-CoC
  • DataLevel : A
    contains the identification data and the declaration of conformity. The remaining data are contained in the embedded CoC or inspection certificate. The data must be extracted and processed manually.
  • DataLevel : B
    Extended metadata and embedded CoC or inspection certificate. Optional Sub CoC or imspection certificates can also be embedded. The data can be processed automatically.
  • DataLevel : C
    Inspection  certificates EN10204 3.1 with data of the specific test. Extended metadata and extended material and test data. The data can be processed automatically.


As mentioned in the scope, the aim of this specification is to cover the types of certificates of conformity listed there. Therefore, a clear distinction in the data structure is required for this. The predefined document categories can be selected from a list.

These are:

  • EcocType : Product
    Component, assembly or process CoC according to DIN EN ISO/IEC 17050-1, NF00-L015
  • EcocType : MaterialCertificate2.1
    Certificate of Conformity with DIN EN 10204 2.1
  • EcocType : MaterialCertificate2.2
    Factory Test Certificate according to DIN EN 10204 2.2
  • EcocType : MaterialCertificate3.1
    Inspection Certificate according to DIN EN 10204 3.1 including material and test data
  • EcocType : MaterialCertificate3.2
    Inspection Certificate according to DIN EN 10204 3.2 including material and test data
  • EcocType : LabTest
    Extended material data for the exchange with material testing laboratories
  • EcocType : StampingCertificate
    The stamping certificate (standard????) is usually used by material dealers, in which the correct transfer of data from the mother plate to smaller blanks is confirmed.


This section describes the parties involved (see Figure 1) and their role in the e-CoC.

These are:

  • PartyRole : Manufacturer
    Manufacturer of the component/assembly concerned
  • PartyRole : Dealer
    Material or standard parts dealer
  • PartyRole : Recipient
    usually the party who ordered the part/assembly/material, standard part concerned
  • PartyRole : Supplier 
    Supplier for material, processes
  • PartyRole : Consigner
    Party who dispatches the goods on behalf of the Manufacturer
  • PartyRole : Consignee
    Party who receives the goods on behalf of the Recipient
  • PartyRole : TestLab
    Test laboratory carrying out the required material tests
  • PartyRole : InspectionAgency
    The independant inspection agency (e.g. TUV) carrying out the required material test

The roles of a individual company is not fixed, this can change depending on the perspective of the e-CoC producer. The material supplier has the role of the manufacturer in his own DIN EN 10204 certificate, as well as in the Stamping Certificate. In the CoC of the component supplier, the material manufacturer has the role of the supplier. 

The address and contact details of the parties are described. The PartyIdentifier parameter plays an important role here. There are already a large number of company identification numbers in the business process, such as CAGE code, VAT-ID, DUNS or also OEM-specific supplier numbers, such as the Airbus supplier number. In addition, company-specific supplier and customer numbers can also be used. All this makes data processing easier and more secure, as there is no need to interpret and assign company names, which are often subject to different spellings. This also means that changes of company name no longer pose a problem.


CoC, inspection certificates, stamping certificates, etc. are always related to a business process with corresponding identification numbers and documents.

These are, among others:

  • Purchase Order Number
  • Manufacturing Order Number
  • Delivery Note Number
  • Article number, of recipient and creator

A list of predefined parameters is available and custom defined parameters are also possible.


Among them are the references to the used standards of the object of the declaration, i.e. the ObjectOfDeclaration.


The section describes the actual object concerned, i.e. the material, article or assembly, the materials and processes used, in the e-CoC. Since this can have multiple options, this section is correspondingly extensive and also variable.

The ObjectOfDeclaration is a list of single objects with different meanings. The parameter ObjectType is used for differentiation.

The following ObjectTypes can exist:

  • ObjectType : RelatedPart
    This is the actual component, assembly, material and that is concerned in the declaration
  • ObjectType : Material
    In the case of a components or assemblies CoC, the used material must be listed used for the “RelatedPart
  • ObjectType : Part
    used components in case of an assembly (RelatedPart)
  • ObjectType : Assembly
    used subassembly in case of an assembly (RelatedPart)
  • ObjectType : StandardPart
    standard parts or consumables used
  • ObjectType : ExternalProcess
    the applied special processes, not carried out by the e-CoC creator, according to OEM definition can be listed here. An additional CoC is required in opposite to an InternalProcess
  • ObjectType : InternalProcess
    the special processes used in-house according to OEM definition. No separate CoC is required here, as the processes are documented within the normal production records.
  • ObjectType : MaterialTest
    Material test
  • ObjectType : Other
    If this does not apply to any of the above possibilities


Under Results you will find the data of the specific material test for DIN EN 10204 Inspection certificates of type 3.1, 3.2 or extended, non-standardised material data determined in materials testing laboratories.

This section is only relevant for DataLevel C. For all others this section is empty.


The declaration section contains the actual declaration text, the status of the declaration and any approved concessions and the data of the creator of the document. This is usually a member of the quality assurance staff who has made the final checks and confirms conformity.


The Attachment section contains the actual document as a PDF, which has always been sent on paper up to now. This document is still the valid document for tracing and must therefore be archived by the recipient. This PDF document is base64 encoded for data transmission when it is created and must be converted back to PDF during import.

Attached documents can be several times in the data schema for the ObjectsOfDeclaration. Optionally, CoC or inspection certificates of materials or processes can be embedded in the data structure. They are then also base64 encoded for data transfer purposes.