Understand your delay results
A result is a screening suggestion built from your statement and available TfL data. This guide shows each step so you can decide whether the journey is genuinely worth claiming.
The core calculation
The dashboard first calculates the actual duration between the recorded entry and exit times. It then subtracts an expected gate-to-gate duration for the same route:
Calculated delay = actual journey duration - expected journey duration
A Waterloo to Wembley Park trip that took 59 minutes against a 31-minute expectation therefore has a calculated delay of 28 minutes. That is the number compared with the applicable service threshold.
Overnight journeys need special handling because the exit time can fall after midnight. The importer preserves the journey date and normalises the duration rather than treating the end time as earlier than the start.
Where the expected time comes from
The dashboard asks TfL's journey-planning service for routes matching the origin, destination, departure time and service. It excludes pure National Rail alternatives from TfL refund screening, selects a representative matching itinerary and adds a small station access and exit allowance.
The result is cached so the same route does not need to be calculated from scratch on every visit. The source and expected duration appear in journey details. If a station name is ambiguous, the route uses multiple services, or no safe match is available, the journey should be reviewed rather than forced through the lower threshold.
Expected time is an estimate, not a historical timetable certificate. Planned closures, interchange choices and walking speed can all affect it. Correct an obviously wrong journey or service before you claim.
What a known disruption match means
The service stores regular snapshots of TfL's public line status for the Tube, DLR, London Overground and Elizabeth line. A journey can be matched when a relevant line reported disruption around that date and time.
This restores useful context that is otherwise easy to lose after the day of travel. It can tell you that, for example, the Jubilee line was reporting severe delays while your Jubilee journey was under way. It cannot establish that the incident caused your exact gate-to-gate delay, and the absence of a match does not prove that the service ran normally.
The dashboard therefore treats disruption data as supporting context. Balanced and Conservative screening require stronger context before presenting the strongest suggestion. Lenient screening surfaces more near-threshold journeys for manual checking.
Conservative, Balanced and Lenient
Uses a more cautious expected-time choice and a larger station allowance. Best when you want fewer, stronger suggestions.
Uses the middle matching itinerary and a standard station allowance. This is the recommended default.
Uses a faster matching itinerary and surfaces more borderline or disruption-linked trips for manual review.
Sensitivity does not change TfL's 15- or 30-minute eligibility thresholds, exclusions or claim deadline.
For a Tube or DLR journey with a known service issue, the near-threshold “worth checking” cut-off varies by setting. Elizabeth line and Overground use higher near-threshold cut-offs because their published refund threshold is 30 minutes.
Reading the result labels
Likely eligible
The calculated delay reaches the relevant threshold and the route has enough information to merit checking against TfL's cause rules. It is not a guarantee.
Worth checking
The journey is close enough to the threshold, or has relevant disruption context, that a human check may be useful. The details should explain why it was surfaced.
Not eligible
The available calculation falls short of the threshold or the service is outside the supported TfL refund scope. You can still correct bad input data.
Checking expected time
The route is still being processed. This is temporary and should resolve when TfL data is available or a saved baseline can be reused.
Why a journey may need review
Review is reserved for missing or conflicting information that would make an automatic result unsafe: an unknown service, an unrecognised station, a PDF row without complete times, or a route for which no matching TfL itinerary was available.
Open the journey details and compare the fields with the original statement. You can edit the route, date, times, service and fare. Once those fields are usable, the dashboard recalculates the result. Submitted, approved or rejected claims are treated as pending or resolved and should not remain in the action-needed review queue.
If everything in the original statement is correct but no route can be calculated, leave the journey unclaimed until you can verify the expected duration from an official source. The emergency review state is preferable to inventing a confident result.
How filters affect travel insights
Journey table filters help you focus on specific cards, services, claim statuses or review states. They do not rewrite the travel snapshot. Snapshot totals and charts use the selected time period so that changing a workflow filter cannot make historical travel, spending or money-back totals appear to vanish.
Railcard savings are estimates. If you state that you hold a Railcard, the dashboard can estimate savings represented by eligible fares. If you provide an optional date of birth, it can also surface age-based Railcard potential. It cannot infer every Railcard or fare restriction reliably from a charge alone.
Inspect the calculation in context
The public demo includes strong, borderline, ineligible, pending and resolved examples, including a known-disruption match.
Explore the demo