If your operation still fills out a paper logbook, you know the routine: illegible handwriting, crossed-out pages, hour totals redone at the end of the month, and that knot in the stomach when an inspector asks for an aircraft's history. The good news is that migrating to the electronic logbook is no longer the exception, and the path is more straightforward than it looks.
This guide was written by someone who flies and by someone who built a digital logbook system used in real operation. Let's get straight to what matters.
Looking for the regulatory basis itself: Resolutions 773 and 458, Portaria 3.220, when it is an LOA and when it is an EO? It is gathered in Electronic Logbook (eDB): what the ANAC rule requires. This article covers the process: how to migrate, what goes wrong, and the checklist.
What the rule requires of the logbook
The logbook is the official record of the aircraft's operational life. In Brazil, ANAC Resolutions No. 773/2025 (which regulates the logbook and admits the digital medium) and No. 458/2017 (computerized systems) cover the record, and Portaria No. 3.220/SPO/SAR, of October 15, 2019, establishes the reference model for the electronic logbook (eDB). The mandatory minimum content, in practice, includes:
- Identification of the aircraft, crew and nature of the flight;
- Off-block, takeoff, landing and shutdown times, with the resulting flight times;
- Records of fuel, persons on board and occurrences;
- Maintenance records and aircraft release (approval for return to service);
- Signatures of those responsible, with traceability of who recorded what.
The central point: the rule defines what must be recorded and the guarantees the record must have (integrity, availability, traceability), not the physical medium. That is what opens the door to the electronic medium.
Paper vs. electronic: what really changes
| Aspect | Paper | Electronic |
|---|---|---|
| Filling out | Manual, subject to erasures and illegibility | Guided, with field validation and automatic calculation of times |
| Hour totals | Redone by hand, a classic source of error | Automatic, consistent with airframe and due dates |
| Availability | One physical copy, on the aircraft | Accessible to the crew, the manager and maintenance simultaneously |
| Audit | Depends on locating physical volumes | Searchable, exportable history |
| Integration | None | Feeds CTM, scheduling, expenses and indicators |
The gain is not just eliminating paper. It is that the flight data is born structured and feeds the rest of management without rework.
How the process with ANAC works
The process varies by type of operation (private under RBAC 91, air taxi under RBAC 135, training at a CIAC), but the backbone is the same:
- Choose a system that meets the rule's requirements. "An app that logs flights" is not enough: the system must ensure the mandatory fields, record integrity (a signed entry cannot be changed without a trail), unambiguous identification of who signs, and the ability to export for presentation to the authority.
- Formalize the use in your operation. The instrument is the LOA: this is the stage where it is requested, and the bottleneck is usually organizing the supporting documentation, not the system itself. In certified operations, the recording medium is part of the operation's documentation, and the change must be reflected in it before it takes effect day to day. It is worth confirming in advance what applies to your type of operation, since the requirements are not the same for everyone.
- Define the transition period. The recommended practice is to run paper and electronic in parallel for a short, defined period, with a formal cutover date, avoiding the worst of both worlds: two diverging official records for an indefinite time.
- Train the crew and record the training. The inspector looks less at the tool and more at consistency: does everyone record the same way? Are the signatures from those who should sign?
The 4 mistakes we see most in migrations
- Migrating without a cutover date. Paper and electronic coexisting for months create divergence, and divergence between official records is the kind of finding that turns a routine inspection into a problem.
- Not bringing the history. The electronic logbook starts today, but the airframe and component hours come from years. If the system does not import the prior totals correctly, all due-date control is born wrong.
- Choosing a system without an audit trail. A shared spreadsheet is not an electronic logbook. If anyone edits any entry with no record of who and when, the system does not meet the integrity requirement.
- Forgetting maintenance. The logbook is not only the crew's: discrepancy and release records need the same rigor. A system that only "logs flights" solves half the problem.
Checklist before migrating
- Does the system cover all the fields required by the rule in force?
- Are signed entries immutable, with a change trail?
- Does each user have individual identification (no shared logins)?
- Does it export the logbook in a format presentable to inspectors?
- Does it import the history of airframe and component hours?
- Is there a contingency plan for recording in case of unavailability?
- Is the change reflected in the operation's documentation (when applicable)?
- Is the cutover date defined and communicated to the crew?
How Alis handles this
Alis was born inside a real operation, and the digital logbook is the platform's central module: guided recording of off-block, takeoff, landing and shutdown times, automatic calculation of times (including day/night split from solar data), traceable signatures and structured export. And, unlike a standalone logbook, every flight entered automatically feeds the CTM, scheduling and expense control.
Want to see it with your aircraft's data? Every aircraft registered in Alis gets trial access: book a demo or sign up and enter your first flights today.
This article is informational and does not replace consulting the current ANAC regulations or the formal guidance applicable to your operation.