Prepare and track a TfL refund claim
A good workflow separates journeys that still need action from claims waiting for TfL and outcomes that are already resolved.
Before submitting
- Confirm the route, card, date and gate times against the original TfL statement.
- Check that the calculated delay, not simply total travel time, reaches the relevant threshold.
- Confirm the service and whether a 15- or 30-minute threshold applies.
- Read any known-disruption context, but do not assume it proves the cause.
- Check TfL's current exclusions and make sure the journey is within 28 days.
Fix incorrect journey details first. A claim based on a guessed station or service is likely to be confusing and may be rejected.
Submit through TfL
The Claim with TfL action opens TfL's official refund service. Enter the journey exactly as shown in your travel history and describe the disruption honestly. TfL may compare the claim with its own timetable, service and ticketing records.
After submitting, change the dashboard status to Submitted. The journey then moves out of Action needed and into Pending, so it is clear that no further claim should be raised while TfL considers it.
Keep the confirmation email and claim reference. The dashboard is useful for organising the journey, but TfL's confirmation is the authoritative record that it received the claim.
What each claim status means
No submission is recorded. Eligible or worth-checking trips can appear in Action needed.
The claim has been sent to TfL and is waiting for an outcome. It belongs in Pending.
TfL has accepted the claim, but you may still be waiting for the refund to arrive.
The approved amount has been paid or credited. The claim is fully resolved.
TfL did not approve the claim. It is resolved and should not return to Action needed.
Use journey editing when the underlying route or time is wrong; do not represent that as a claim outcome.
Record the outcome once
When TfL replies, update the status on the same journey rather than importing or creating a second row. A paid plan can match supported forwarded outcome emails to an existing journey, but you should still verify the date, route and reference.
If a claim is rejected, read TfL's reason before changing the route calculation. A rejection may reflect an excluded cause or an official expected time, not bad imported data. The dashboard should preserve that journey as resolved so the same suggestion is not repeatedly surfaced.
If TfL asks for more information, leave the claim as Submitted while you respond. “Pending” is a workflow view derived from the Submitted status, not a separate claim decision.
Understand the money totals
Total claimed adds fares for submitted and resolved claims across the selected time period. Selected card claimed applies the card selection. Refunds received counts journeys marked as paid or credited.
The monthly money-back chart should follow only the insight time period. Journey-table filters such as claim status or review state are for managing the list and do not rewrite historical totals. This keeps a temporary table filter from making genuine past refunds disappear from the snapshot.
Fare values are useful estimates. TfL's approved amount and payment confirmation take precedence, especially for Travelcards, caps, concessions or partial fare calculations.
Keep useful records without oversharing
Keep the original statement, submission confirmation, claim reference and TfL outcome until the payment is settled. Avoid putting full card numbers or account credentials in free-text notes. The dashboard needs journey details, not a TfL password or complete payment-card data.
Export a JSON backup before clearing browser storage if you use the service signed out. Signed-in users can sync supported history, but an external copy is still sensible for important personal records.
Organise recent claims
Use Action needed for unclaimed candidates, Pending for submitted claims and the status filters for completed outcomes.
Open your journeys