Skip to content

Tracking reconciliation

How to reconcile maintenance tracking with source records

Reconciling maintenance tracking with source records means checking that the times, cycles, due dates, and task status held in the tracking system match the documents those entries were built from. It is read by airworthiness and records teams whose system output is about to feed a transaction or a return. The work covers airframe and component times and cycles, task and check due dates, AD and component status, and how program revisions were carried forward. You finish with a reconciliation showing where the system and the records agree, where they have drifted, and a correction list for the entries that need to change.

When this review is needed

  • A tracking system is feeding a transaction or return and its output has not been checked against source.
  • An aircraft was migrated between tracking systems and the carried-over values need confirming.
  • A maintenance program was revised or escalated and the system's due dates may have drifted from the records.
  • Several years of manual entry have passed since the system was last reconciled to source.

The problem

A tracking system is a model of the records, built and maintained by people entering data across years of revisions, escalations, and migrations. Every one of those events is a chance for the model to drift from the source it was meant to mirror, and the drift concentrates exactly where the data is hardest to maintain. Because the system is consulted far more often than the documents behind it, the drift goes unnoticed until someone relies on the output for a decision that the source would not support.

What gets reviewed

  • Airframe, engine, and component times and cycles held in the system
  • Task and check due dates against the last accomplishment evidence
  • AD and Service Bulletin status in the system versus the work records
  • Component part and serial numbers in the system against installation evidence
  • Program revisions and escalations and how the system carried them forward
  • The sampling rule that selects the high-value items checked to source

Scope this review

Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.

Send a representative, redacted record set and we will scope the review.

What gets validated

  • Sampled times and cycles in the system match the source documents exactly
  • Task due dates trace to the last documented accomplishment
  • Component records in the system match the installed part and serial numbers
  • Program changes are reflected in the system the way the records show them
  • The sampling covers the items where drift is most likely to concentrate

Evidence normally required

  • A current export of the maintenance-tracking system
  • The source documents behind the sampled high-value items
  • The maintenance program and any revision or escalation history
  • Component installation and removal evidence for sampled assemblies

Common discrepancies

  • Times or cycles in the system that do not match the source document
  • A task due date in the system with no accomplishment record to anchor it
  • A component in the system whose serial number disagrees with the installation record
  • A program escalation applied in the system but not reflected in the records
  • Values carried over from a prior system that never traced back to source

What is at stake

A due date in the system with no accomplishment record to anchor it can put a task in the wrong place on the calendar, early or late. A time or cycle figure that disagrees with the source undermines a status list a buyer is pricing against, and a component whose serial number in the system does not match the installation record breaks the trace for that assembly.

How the work runs

01

Export and sample

Take a current system export and select the high-value items where drift is most likely to concentrate.

02

Pull the source

For each sampled item, retrieve the source document that the system entry was built from.

03

Compare line by line

Check times, cycles, due dates, and serial numbers in the system against the source, recording each match and each drift.

04

List the corrections

Compile the entries that need to change in the system and the source each correction rests on.

What the buyer receives

  • A reconciliation showing where the system and the records agree and drift
  • A correction list for the entries that need to change in the system
  • A sampling record documenting which items were checked to source

Who uses the output

  • Airworthiness teams correcting the system to match source
  • Records leads certifying the status output before it is relied on
  • Asset teams who price against the system's status list

How the work fits into the transaction or program

Reconciliation sits between the tracking system and any decision built on its output. Its corrected status feeds AD validation, a return binder, or a data room, so those rest on numbers checked to source rather than carried forward on trust.

Regulatory limits

Reconciliation confirms that the system matches the records. It does not make the records compliant, does not make an airworthiness determination, and a corrected system still depends on the underlying source documents being complete and accurate.

What this review does not cover

  • Configuring, migrating, or licensing any tracking platform
  • Creating source records that do not exist
  • Any airworthiness determination or regulatory approval

Specific to this review

  • A tracking system is a model of the records, and that model drifts across years of data entry, migrations, and program changes, so its output is checked rather than trusted.
  • Reconciliation works by sampling the high-value items to source rather than re-keying everything, because the drift concentrates where the data is hardest to maintain.
  • A system migration is a high-risk drift event, because values carried from a prior platform can arrive without ever tracing back to a source document.

Sources

Frequently asked questions

Why sample instead of checking every entry?

Because re-keying an entire system to source rarely fits the time available, and drift is not evenly spread. It concentrates on the items that are hardest to maintain, so sampling those high-value entries finds most of the drift for a fraction of the effort.

Relevant glossary terms

Related pages

Where this fits

Talk to an engineer who has done this work

We will walk through your current state, the records or evidence involved, and a scoped first engagement.

Adapt the checklist to your asset, event, and jurisdiction.