The register EASA expects
The AMC to 145.A.40 describes the control register as the backbone of tooling control: a clear labelling system for next inspection, servicing, or calibration due and for unserviceable items, plus a control register for precision tooling with a record of calibrations and the standards used.
Crucially, the register is not a single flat list. It tracks tools per part number — description, control classification, reference instruction, and servicing and calibration intervals — and per serial number. The S/N layer is where the register earns its keep, because it records where the item lives and what its status is at any moment.
"A database should be expected"
EASA's own tooling-control guidance is explicit about the shape of the solution. For a major organisation with several workshops, line stations, and hangars, a database should be expected.
That sentence is not incidental. It reflects the reality of a control register that must stay coherent while the same tool types are spread across distant locations, moved between them, sent for calibration, and returned. A single shared spreadsheet is not a reasonable reading of what is expected of a multi-location operation.
Per-P/N and per-S/N are different layers
The P/N layer is about the type: what the tool is, what control classification it carries, what reference instruction governs it, and what servicing and calibration intervals apply. The S/N layer is about the individual physical item: is this specific serial number at the wheels workshop, a line station, or a hangar, and is it serviceable, unserviceable, scrapped, sent for calibration, or loaned?
A spreadsheet can hold both layers as rows, but it cannot keep them reconciled. The same P/N being valid does not tell you whether this particular S/N, at this particular station, is currently valid to use.
The failure modes of a spreadsheet
The incumbent is not an MRO platform — it is the collection of spreadsheets that grew one tab at a time. Its failure modes are well understood: entries are updated manually and go stale; there is no reliable per-S/N status across line stations and hangars; several people edit the same file and the truth depends on whoever saved last.
Worst of all, a spreadsheet has no enforcement. It can warn that a calibration is due, but it cannot stop an expired calibrated tool from being issued, and it cannot guarantee that a single tool has only one active custody record. The register becomes a reconstruction exercise the night before an audit.
What a database can enforce
A database is the difference between a record and a control. In Aviamatic the S/N status — serviceable, issued, unserviceable, sent for calibration, loaned — is updated across line stations, hangars, and vehicles as a single coherent state.
That lets the system enforce the controls a spreadsheet cannot: expired calibrated tools cannot be issued (including by supervisor override), and a tool cannot have more than one active custody record. Manual validation is protected from silent overwrite on import, and critical changes append an audit trail. The register EASA expects becomes something you operate, rather than something you maintain by hand.