TOEIC Link Reading — Conditional and Cancellation Clauses: Reading a Booking Confirmation for What Actually Binds You

A booking confirmation email presents itself as a receipt — here is your reservation, here is your reference number, thank you for your order. But the sentences that carry the exam's questions are not the friendly ones at the top. They are the conditional and cancellation clauses buried in the middle: cancel before this date and pay nothing, cancel after it and forfeit a night; changes are free unless the fare is non-refundable; the deposit is returned only if the room is vacated by noon. TOEIC Link reading writers build questions on exactly these conditions, because a reader who skims the confirmation as a receipt will answer with the default outcome and miss the branch the question is testing. Reading a confirmation is the discipline of finding the clause that changes what the customer owes, and reading it as a rule with an if attached rather than a flat statement of fact.

This guide maps the conditional and cancellation phrase families that confirmation emails run on, the traps they carry, and a reading protocol for extracting the operative condition. Because this genre encodes its real content inside if-clauses and cutoffs, pair it with the Part 5 conditionals and if-clauses grammar guide and the conditional and counterfactual logic parsing framework, which train the same skill of reading a sentence for the condition that governs its outcome rather than the outcome alone.

Why the condition, not the confirmation, is the question

A confirmation states a default: your booking is confirmed, the total is charged, the room is held. That default is rarely what the question asks about. The typical TOEIC Link stem asks Under what circumstances can the customer get a refund?, What must the customer do to avoid a fee?, or By when must the reservation be changed? Each of these points not at the default but at the exception — the branch that applies only if a condition is met or missed. The trap is that the confirmation's headline is reassuring and unconditional, while the answer lives in a subordinate clause that reverses it. A reader who answers from the headline reports what happens by default; the question rewards the reader who found the if and read what happens on the other side of it.

The four clause families of confirmation emails

Confirmation emails run on four recurring structures, each attaching a consequence to a condition.

• Deadline conditional: if you cancel before [date], cancellations received by [time] are, provided the change is made at least 48 hours in advance. The consequence turns on beating a cutoff.
• Status conditional: if the fare is non-refundable, unless the rate is marked flexible, for prepaid bookings. The consequence turns on which category the booking falls into.
• Action conditional: to avoid a charge, you must, the deposit is refunded only if the room is vacated by, failure to check in by [time] will result in. The consequence turns on whether the customer performs a required step.
• Penalty statement: a cancellation fee of one night applies, no-shows are charged the full amount, amendment fees may apply. The consequence itself, whose trigger the reader must trace back to a condition above.

The deadline and action families produce the sharpest traps, because a single date or step separates a full refund from a total forfeiture.

The default-versus-exception trap

The core trap offers the reassuring default as the answer instead of the conditional exception. The email reads Your reservation is fully refundable if cancelled at least 72 hours before check-in, and a distractor says the reservation is simply fully refundable. That reports the default and drops the condition. The refund exists only inside the 72-hour window; cancel at 48 hours and it evaporates. Read refundable if cancelled at least 72 hours before as a rule with a boundary, and carry the boundary into your answer. When a stem asks whether the customer can get their money back, the honest answer is yes, but only if — and the only if is the whole point of the question.

The cutoff-direction trap

Deadline conditionals hinge on before-versus-after, and questions test whether the reader tracked the direction of the cutoff. The email reads Changes made after August 20 incur a $50 fee, and a distractor charges the fee for changes made before the date, or treats every change as free. The fee attaches to the after side of August 20; the before side is free. Read after [date] ... fee and by [date] ... no charge as a pair pointing in opposite directions, and pin each outcome to its side of the line. Flipping which side of the cutoff triggers the penalty is the miss the distractor is built to catch, and it is the single most common error on confirmation questions.

The category-gate trap

Status conditionals gate the outcome on which type of booking the customer holds, and stems probe whether the reader checked the category first. The email reads Refunds apply to flexible rates only; saver rates are non-refundable, and a distractor grants a refund to a saver-rate booking. The refund is gated behind the flexible category; a saver-rate customer never reaches it. Read applies to X only and for Y, no as a gate that must be passed before the outcome applies, and confirm the customer's booking is on the right side of the gate. Answering as though the favorable branch applies to everyone, when it is reserved for one category, is the trap in status-conditional clauses.

The required-action trap

Action conditionals make the outcome depend on a step the customer must take, and questions test whether the reader found the step. The email reads To receive a full refund, you must cancel through the confirmation link, not by phone, and a distractor grants the refund for any cancellation. The refund is conditional on the method: cancel by phone and the condition is unmet. Read to [outcome], you must [action] as a requirement, not a suggestion, and treat the outcome as unavailable when the action is skipped or done the wrong way. Reporting the favorable outcome while ignoring the action that unlocks it is the routine slip in required-action clauses.

The stacked-condition trap

Longer confirmations stack more than one condition on a single outcome, and questions probe whether the reader satisfied all of them. The email reads The deposit is returned if the room is vacated by 11 a.m. and no damage is reported, and a distractor returns the deposit on the timing alone. Two conditions are joined by and: on-time checkout and no damage. Both must hold. Scan the sentence for every condition attached to the outcome — watch for and, provided that, as long as — and confirm each is met before you accept the outcome. Satisfying the first condition and assuming the outcome follows, when a second is coordinated onto it, is the error stacked conditionals are built to expose.

The reading protocol for booking confirmation emails

1. Find the if before the outcome: for every consequence — a refund, a fee, a hold — locate the condition that governs it, and read the outcome as available only when the condition holds.
2. Fix the direction of every cutoff: for date and time conditions, mark which side of the line triggers the penalty and which side is free, and pin each outcome to its side.
3. Check the category gate first: when an outcome applies to one booking type only, confirm the customer's booking is in that category before granting the outcome.
4. Confirm the required action was performed: when a favorable outcome depends on a specific step or method, treat it as unavailable unless that exact step was taken.
5. Satisfy every stacked condition: scan for coordinated conditions joined by and, provided that, or as long as, and accept the outcome only when all of them hold.

A booking confirmation is a contract wearing a receipt's clothes. The reader who answers from the cheerful headline reports the default and walks into the exception; the reader who hunts for the if, fixes the cutoff, checks the gate, and counts the conditions answers the question the confirmation was actually built around. Every fee, forfeiture, and refund in these emails lives on the far side of a condition — and that condition is where TOEIC Link points.