Reviewing engine shop-visit records in a transaction data room

When this review is needed

• A letter of intent is signed and the data room's engine folders have been indexed but never read past their labels.
• The engine status summary cites shop visits whose full packages have not appeared in the uploads.
• LLP remaining life drives the price and the trace behind it sits inside shop-visit paperwork.
• Q&A responses keep pointing at documents that cannot be located in the posted folders.

The problem

An index folder labeled with a visit year says nothing about what is inside it. Sellers routinely upload the cover letter and release certificate while module build records, disk sheets, and test-cell acceptance data stay in the shop's archive. Meanwhile the diligence clock runs, and the team cannot tell whether the package is genuinely thin or the upload simply stopped halfway.

What gets reviewed

• Each shop visit named in the engine status summary matched to a folder in the room and to the package inside it
• Release certificates read against the workscope, the module builds, and the parts fitted during the visit
• LLP sheets inside each package compared with the current LLP status and its back-to-birth trace
• Test-cell acceptance results checked for presence, legibility, and agreement with the release
• Q&A responses on engine questions reconciled with what the uploaded files show
• Unsupported statements logged as exceptions with the folder path recorded

What gets validated

• The FAA Form 8130-3 or EASA Form 1 releasing each visit matches the engine serial number and the stated workscope
• Module serial numbers in the build records agree with the assembled configuration on the release
• Parts fitted during the visit carry release documents inside the package, or their absence is logged
• Cycle figures on the LLP sheets reconcile with utilization data posted elsewhere in the room
• Visit dates and removal reasons in the status summary agree with the shop reports themselves

Evidence normally required

• Access to the data room, including the index export and the Q&A log
• The engine status summary or specification the seller represents
• Current LLP status listing for each engine
• Utilization data covering the periods between visits
• Term-sheet clauses that define the records standard for the deal

Common discrepancies

• A release certificate posted without the build records or test-cell data behind it
• An LLP whose shop-visit sheet shows a cycle figure the status list quietly rounds
• A visit described as a performance restoration that the report reveals as a limited workscope
• Q&A answers asserting a document exists that never arrives in the folders

What is at stake

If the gap surfaces after signing, the buyer has already priced LLP life and time since visit on figures the sources cannot carry. Reopening the question at closing means escrow arguments and delayed delivery, and a module trace that stays broken can force a conservative life assumption that erases the value of the visit.

How the work runs

What the buyer receives

• An exception list keyed to data-room folder paths, ready for the diligence exception schedule
• A visit-by-visit support matrix showing which claims trace to uploaded source files
• Prioritized document requests worded so the seller can pull the exact missing pages

Who uses the output

• Transaction leads negotiating the exception schedule and closing conditions
• Due-diligence engineers deciding whether an on-site records visit is warranted
• Asset managers pricing engine value from supported LLP and time-since-visit figures

How the work fits into the transaction or program

The review sits between the first data-room walk and the drafting of closing conditions. It converts open engine questions into specific document requests while the seller is still answering Q&A, and its exception list merges with the findings from the logbook and program reviews so the deal team negotiates from one consolidated picture.

Jurisdiction-specific considerations

Engines released under 14 CFR Part 43 carry FAA Form 8130-3 tags, while EASA Part-145 shops issue EASA Form 1, and a mixed operating history often leaves both in one package. Dual-release language matters where the buyer plans to move the engine between FAA and EASA registries, so the review notes which releases carry it and which do not.

Regulatory limits

The review reports what the posted files can and cannot support. It does not certify engines as airworthy, approve data, issue or validate release documents, or make the return-to-service determinations that remain with certificated persons and organizations under FAA and EASA rules.

What this review does not cover

• Borescope inspections or any physical assessment of the engines
• Valuation of the engines or their workscopes
• Direct engagement with the overhaul shop to obtain missing paperwork

Specific to this review

• Shop-visit packages are the densest records in a data room; one heavy visit can run past a thousand pages, and sellers often upload a summary export instead.
• Back-to-birth LLP traces usually break at a module swap performed mid-visit, which shows up in the build records and never in the status list.
• Test-cell data goes missing more often than release certificates because shops treat it as internal quality evidence rather than a customer deliverable.
• A Q&A answer is a representation, and the exception stays open until the referenced page actually appears in the room.
• Dual FAA and EASA release blocks signed at the visit simplify later registry moves, so their absence is worth a question even when the deal does not immediately need them.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits