Skip to content

Tracking vs. source

Maintenance-tracking reconciliation against source records

Maintenance-tracking reconciliation checks that the due list, AD and SB status, and component time and cycle figures a tracking system reports are supported by the source records behind them. It is run by or for a lessor, airline, operator, or management company that relies on tracking output for decisions but has not confirmed it against accomplishment and release evidence. It covers the maintenance program status, recurring inspection due dates, life-limited part counters, and the source entries each line is built from. You receive a line-by-line reconciliation, a register of every disagreement between tracker and source, and the evidence needed to align them.

When this review is needed

  • A tracking system was inherited at induction and its status has never been checked against the records it summarizes.
  • A due list drives planning and budget, and the planning team wants confidence the next-due dates are real.
  • A counter or interval was edited in the tracker and no one can point to the source entry that justifies the change.
  • A maintenance program revision was loaded and the recurring tasks need confirming against the revised requirements.
  • Two parties read the same status differently, and the disagreement traces to how the tracker was populated.

The problem

A tracking system reports a clean due list and a tidy AD status, and most decisions are made off that screen. The figures originate from manual entry, prior operators, and imported datasets, and the accomplishment and release documents that justify each line are rarely opened. A counter set wrong at induction, an interval typed against the wrong reference, or a closed AD that the system marks open all look identical to a correct entry until someone compares the tracker to the source.

What gets reviewed

  • The maintenance program loaded in the tracker against the applicable program revision
  • Recurring inspection and task intervals with their last-accomplished and next-due basis
  • Airworthiness Directive status with method of compliance and recurring terms
  • Service Bulletin and modification status and embodiment evidence
  • Component time, cycle, and calendar counters against installation and accomplishment entries
  • Life-limited part counters against the source release and accumulation history
  • Sample of due-list lines traced end to end from screen to source document

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

  • Each next-due date traces to a last-accomplished entry in the source records with the correct interval
  • Recurring AD terms in the tracker match the directive and the last accomplishment evidence
  • Component counters reconcile with the installation entry and the aircraft utilization since install
  • Life-limited part counts agree between the tracker, the release certificate, and the logbook history
  • The maintenance program loaded matches the revision the operator is approved against
  • Tasks shown complete carry a source work order or task card, and tasks shown open are genuinely open
  • Utilization feeding the tracker reconciles with the recorded flight and cycle log

Evidence normally required

  • Export of the maintenance-tracking status, due list, and component list
  • Applicable maintenance program revision and revision history
  • AD and SB status reports with accomplishment references
  • Task cards, work orders, and logbook entries for the sampled lines
  • Component installation records and life-limited part release certificates
  • Flight and cycle utilization log for the period in question

Common discrepancies

  • A next-due date computed from an interval that does not match the program revision
  • A recurring AD whose tracker term differs from the directive's stated repeat interval
  • A component counter that drifted from utilization because a flight-log feed was incomplete
  • An AD marked open in the tracker that the records show was closed at a prior shop visit
  • A task shown complete with no work order or task card behind it
  • Life-limited part counts that disagree between the tracker and the release paperwork
  • Duplicate or superseded tasks left active after a program revision was loaded

What is at stake

Planning built on an unverified due list either schedules work that is not due or misses work that is, and both carry cost. A counter that overstates remaining life leads to a part flown past its limit, and a status that disagrees with the records weakens every downstream decision, from budgets to a redelivery built on the same screen.

How the work runs

01

Export and frame the status

Pull the tracker due list, AD and SB status, and component list, and frame them against the applicable program revision.

02

Trace lines to source

For each sampled line, follow the next-due, counter, or compliance term back to the work order, task card, or release that justifies it.

03

Register disagreements

Record every tracker-to-source difference with its evidence and the corrected value the records support.

04

Deliver a supported basis

Hand back a reconciled status and the list of entries still needing a source document before they can be relied on.

What the buyer receives

  • A line-by-line reconciliation of due list and status against the source records
  • A discrepancy register listing each tracker-to-source disagreement with its evidence
  • A corrected status basis showing the supported next-due and counter values
  • A note of the entries that need a source document before the line can be trusted

Who uses the output

  • Planning teams building the maintenance forecast and budget
  • Continuing-airworthiness staff confirming the program is correctly tracked
  • Records teams correcting tracker entries against the source evidence

How the work fits into the transaction or program

Reconciliation sits between the tracking system and any decision made from it, so a due list, a transition, or a return is built on figures that the source records support. It feeds planning, the records baseline, and any later audit that will test the same numbers.

Start with a single asset

Start with a single tail and expand once the workflow is proven.

Aircraft-specific considerations

How a tracker should compute due dates varies by type, because interval bases, threshold and repeat structures, and life-limited part architecture differ. A reconciliation is set up against the specific type's program rather than assuming one tracker configuration fits a mixed fleet.

Regulatory limits

Reconciliation confirms that tracking output is consistent with the source records and identifies where it is not. It does not approve the maintenance program, make an airworthiness determination, or replace the operator's responsibility for the accuracy of its own records.

What this review does not cover

  • Configuration or correction of the tracking-system software itself
  • Re-issuing the maintenance program or any program approval
  • Physical inspection of the aircraft or its components

Specific to this review

  • The decisive disagreement is between the tracker screen and the source document, because the two are populated separately and are seldom compared after induction.
  • A wrong interval or a mis-set counter is invisible on a due list until a specific line is traced back to its last-accomplished entry.
  • Reconciliation samples lines end to end rather than trusting the status export, since a clean-looking due list and a correct due list are not the same thing.

Sources

Frequently asked questions

Why not trust the tracking system's due list?

The due list is computed from entries that people and prior operators put in. The figures are only as good as those entries, and a single wrong interval or counter is indistinguishable from a correct one until the line is traced to its source.

Do you fix the tracking system?

The reconciliation tells you which lines disagree with the records and what the supported value is. Correcting entries in the software is done by the records team that owns the system, using the discrepancy register.

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.

Walk through your situation with an engineer who has done this work.