ECCAIRS 2, ADREP and E5X,
in plain language.

See the highlighted block above the contents list for the short version: platform, taxonomy, format. The rest of this piece defines each of the three, follows a report from the first screen into ECCAIRS 2, and then gets to the part that actually affects your day, what all of this implies for the reporting system you run internally.

The three terms describe three different layers, and keeping them separate makes the whole subject click into place.

• ECCAIRS 2, the platform. It is the current European software generation for collecting, storing and analysing civil aviation occurrence data. When people say a report goes into ECCAIRS, this is the destination they mean. Earlier ECCAIRS generations came before it; ECCAIRS 2 is the one operators and authorities work with now.
• ADREP, the taxonomy. ADREP is a structured, coded vocabulary published by ICAO for describing occurrences. Rather than free prose, it provides controlled values for the attributes of an event, so the same thing is described the same way everywhere. It is the language, not the software.
• E5X, the transfer format. E5X is a zipped XML file that carries one or more ADREP-coded reports between systems. It is the standard envelope for moving occurrence data, machine-readable so the receiving side can ingest every field without re-typing.

This is where the regulation connects to the plumbing. EU 376/2014 requires occurrence databases to be ECCAIRS-compatible and classified using ADREP, and E5X is the format that makes the exchange work in practice. If you want the full picture of the reporting obligations those names serve, from the two reporting streams to the 72-hour deadline and the just-culture protections, the companion guide to EU 376/2014 occurrence reporting covers them end to end.

Follow a single occurrence from the moment someone notices it, and the role of each name becomes obvious.

• Someone reports. A person becomes aware of an occurrence and files it into their organisation, ideally through a confidential channel and as a structured record rather than an email.
• The organisation codes it.The report's key attributes are classified against the ADREP taxonomy, so it becomes a comparable, exchange-ready record instead of a one-off note.
• The organisation transfers it. The report is passed to the national competent authority. If the internal system supports it, this happens as an E5X package; if not, it happens by hand.
• It lands in the European system.The data moves into ECCAIRS 2, where authorities aggregate and analyse occurrences across the wider picture, well beyond any single operator's view.

The mechanics of that third step come in two flavours. Either a compatible system produces an E5X file that carries the coded reports in one structured package, or a person opens a web portal and types the reports in one at a time. Both satisfy the obligation to transfer. They differ enormously in cost, consistency and how well they hold up as reporting volume grows, which is the real subject of the next two sections.

Here is the part that actually lands on your desk. The names ECCAIRS 2, ADREP and E5X describe the exchange, but the work that makes the exchange easy or painful happens much earlier, in how your own system captures an occurrence in the first place. Three properties decide it.

• Taxonomy mapping quality. Your internal classification needs to map cleanly onto ADREP. When it does, coding a report is a single, consistent step and the data is exchange-ready. When it does not, someone has to translate every occurrence into ADREP later, and two people will translate the same event differently.
• Structured fields at intake. The key attributes of an occurrence should be captured as controlled, coded fields on the first screen, not reconstructed afterward from a paragraph of prose. Whatever structure you skip at intake, you pay for later, with interest.
• No re-keying.The same occurrence should be entered once and travel through investigation, action and transfer as one record. Every time a report is retyped, from email to spreadsheet to portal, is a chance to introduce an error and a tax on the team's time.

The through-line is simple: capture the structure once, at intake, and everything downstream, the analysis, the transfer file, the audit trail, reads from the same clean record. A reporting system that collects free text and hopes to code it later has inverted the effort, and it shows up as slow transfers, inconsistent data and reports nobody can aggregate. This is one of the practical reasons the shift from safety management to safety intelligence starts at intake, not at the dashboard.

There are two operating models for getting reports into the European system, and the gap between them widens with every report you file.

Native compatible export. The system already holds occurrences as structured, ADREP-aligned records, so producing a compatible transfer package is close to a button press. Coding is consistent because it was set at intake, transcription error is designed out because nobody retypes anything, and the approach scales: a busy month of reports costs the same handful of clicks as a quiet one.

Manual portal entry. A person opens a web portal and keys each report in by hand. For a handful of occasional reports this is perfectly workable. But it carries three costs that compound as volume rises: it takes real staff time per report, it invites transcription errors, and it produces coding drift because each person interprets the values slightly differently. Worst of all, when reporting becomes a chore, people quietly report less, which is the opposite of what the whole system is for.

The point is not that one model is always right. Low-volume operations can live on portal entry for a long time. The point is to choose with your eyes open, and to know that the moment reporting becomes routine, native export from a structured system stops being a nice-to-have and becomes the thing that keeps your data consistent and your reporters willing.

A reporting system built for this world does the hard part at the beginning: it captures each occurrence once, as a structured record, with classification drawn from a controlled taxonomy, so everything downstream is clean. eAviora is built that way.

Occurrences enter one operational graph as structured records and stay linked to their investigations, corrective actions, audits, findings, documents and the safety indicators they move. Captured once, the same record carries through every stage, so there is no spreadsheet-to-portal retyping and no lost structure between tools. Reporting starts confidential, with a closed just-culture loop, so protecting the reporter and producing clean data are not in tension.

Because the data is structured from intake, the parts EU 376/2014 cares about most become achievable rather than aspirational: occurrences can be aggregated and trended with real statistical process control instead of a coloured arrow, and enforced closure gates mean a record cannot close over open risk, so follow-up is a rule the workflow holds, not a promise the team has to keep. The taxonomy is the foundation the whole thing rests on: get the mapping right at intake, and analysis, transfer and audit all read from the same clean record. See the SMS module and the Compliance module for where that capture and analysis live.