European Railway Agency - ERA

Making the railway system work better for society.

Vehicle Authorisation

No matches found. Please try again.

In order to get a Type ID in ERATV you need to:

1. Submit to the wanted authorising entity (NSA or Agency) a request for a draft type in ERATV before applying for the authorisation. When the Agency is chosen as authorizing entity, please use this template.

2. When granted access to the draft type provide the technical details directly in ERATV. The draft type contains the TYPE ID to use in the authorisation application. More information about ERATV can be found here.

3. When your draft type is ready in ERATV print it into a PDF file (or export it to Excel) and upload that file into the documentation of your application in the OSS.

See also:

If you don't find the answer to your question, please contact us directly:link to contact us page

  1. The authorisation case once saved can hardly be changed. To select correctly the authorisation case please read carefully the application guide on vehicle authorisation (article 14). If you select a wrong authorisation case, you will probably need to recreate your application from scratch. Alternatively you can delete the uploaded documents from the documentation and empty the content of the mapping tables. The selection of the authorisation case triggers the creation of the folder structure for the documentation as well as the definition of the authorization details to provide.


  2. The documentation to provide depends on the real case. The implementing regulation (EU) 2018/545 details in annex 1 the content expected per authorisation case. The application guide details further this annex 1 (especially the technical file and the requirements capture). Depending on your real case some folder may be left empty. OSS does not constrain on providing file in each folder. It is the responsibility of the applicant to provide the appropriate documentation.


  3. OSS allows you to define the language of the user interface in your profile. The language in which you want the authorising entity to deliver the authorisation is a separate field in each application form. The two may be differentiated depending on your need. The language to use during the processing of the application is described in the implementing act and in the application guide (article 10).


  4. The type / variant(s) / vehicle(s) in the authorisation details shall be carefully created: once the application is submitted it is not possible to add type / variant(s) / vehicle(s).


  5. The definition of the area of use consists in selecting the Member State(s) where the vehicle will be authorized and the network(s) in these Member State(s). There is also the possibility to select the border stations in the neighbouring Member State(s). The allowed values for the networks and the border stations are defined by each Member State. Each concerned NSA shall provide the exact possible values. Please refer to the NSA website or contact the NSA to get the list of possible values for each information. The value “Whole EU” should be selected only for vehicles where no national technical rule are applicable.


  6. The selection of the authorising entity is essential for the processing of your application. If the area of use of your vehicle authorisation concerns more than one Member state, the authorising entity shall be the Agency; if the area of use is limited to one Member State you can choose between the NSA and the Agency. The OSS does not allow the choice of the NSA as authorizing entity in one application when the area of use covers more than one Member State. In case of wrong selection of the authorising entity, the application will be rejected and a new application will be required.


  7. The mapping tables provide guidance to the assessors about where the aspects to assess are documented. The references shall be detailed and precise enough to allow the assessor to be efficient in its assessment. Vague or insufficient mapping tables will trigger issues and may be a cause for incompleteness.

If you don't find the answer to your question, please contact us directly:link to contact us page

Templates and checklists can be used to support the work of the actors during the assessment. These templates and checklists are documents to fill in with usual office suite tools and to upload in the OSS as attachments to the various reports (mainly completeness check, detailed assessment, conclusion, decision and authorisation). The templates and checklists are made available to the users through the templates folder in the library.

If you don't find the answer to your question, please contact us directly:link to contact us page

Applicant are free to organize their documentation according to their needs. The folder structure proposed for the documentation is a guidance. However respecting it renders the elaboration of the mapping tables easier and it is therefore encouraged. If the structure is not followed it is highly probable that it will take more time to create the mapping table. In some cases the applicant may want to provide sub-folders; in such case a zip file (of the sub-folders) should be uploaded in the documentation and the reference(s) in the mapping table(s) shall contain the location and the filename in the zip file.

See also:

If you don't find the answer to your question, please contact us directly:link to contact us page

Various documents are required for the authorisation. Such documents shall be provided in the documentation supporting the application. In case of positive decision related to the application the issuing authority has the obligation to check that the concerned documents are present in ERADIS. In case they are not, the decision will be positive but the authorisation will not be delivered to the applicant (pending the documents are uploaded).

The list of documents to upload in ERADIS are listed in the ERADIS homepage.

See also:

If you don't find the answer to your question, please contact us directly:link to contact us page

It is not necessary to use the issues log for all the questions occurring during the assessment of an application.

The purpose of the issues log is:

  • to facilitate the tracking of the resolution of issues (ensuring that all issues are resolved before delivering the decision),
  • to alert the various actors on a specific problem that may affect their work,
  • to keep the traceability of the resolution of an issue (how it was resolved?), and
  • to facilitate the creation of the completeness check and the assessment report by attaching in these reports the main issues discovered.

In practice all communications do not have to go through the issues log and other communication channels can still be used (e.g. phone or email). However, a user is expected to create an issue in the issues log in the following cases:

  • the issue needs tracking,
  • evidence is to be added to the application file, or
  • there is an impact other parties (e.g. the applicant, another authority) or on the application file.

Note that nothing prevents the user to create an issue later on if this appears to be relevant.

Another aspect relates to the formulation of the issue. An issue may contain several questions but in that case, all questions need to be of the same type, have the same due date, etc. and the issue can only be closed when all questions are answered. It is left at the discretion of the user (and ultimately the project manager) to organise this in the most appropriate manner depending on the needs of the project.

Issues shall be created by users as soon as they evaluate that one of the purpose is met.

See also:

  • Explanations of Art. 41 (categorisation of issues) and 42 (justified doubt) of the Implementing Regulation (EU) 2018/545 in the Guidelines

If you don't find the answer to your question, please contact us directly:link to contact us page