Feature guide
Managing exceptions
Exceptions are the issues Tripwise surfaces after processing your data. Each one represents a specific gap between what your booking system, payment provider, and suppliers are saying about the same transaction.
The seven types of exception
Tripwise currently detects seven categories of problem. Understanding what each one means helps you prioritise and respond effectively.
Customer charged, booking not confirmed
A payment has been captured but there is no confirmed booking or supplier confirmation to go with it. The customer has paid for something that may not actually be reserved.
What this means in practice:
- The customer may turn up to a hotel, airport, or attraction with no reservation waiting for them.
- The full payment amount is at risk until this is confirmed or refunded.
- If the travel date is approaching, this needs to be resolved the same day.
Typical resolution:
Contact the supplier directly to confirm whether they hold the reservation. If they do not, either re-book or arrange a refund before the customer is affected.
Supplier confirmation doesn't match your records
A supplier has confirmed a booking, but your internal records show that booking in an unexpected state — cancelled, refunded, or never finalised. The supplier thinks the booking is active; your system disagrees.
What this means in practice:
- The supplier may be holding a room, seat, or service that your customer is no longer expecting — and charging you for it.
- A cancellation that was processed on your side may not have reached the supplier, meaning cancellation fees could be accumulating.
Typical resolution:
Check which side has the correct picture and reconcile. If the booking was genuinely cancelled, notify the supplier and confirm no charges apply.
Booking confirmed but no supplier reference on file
A booking is confirmed and a payment captured, but there is no supplier booking reference recorded anywhere. If anything changes — a customer amendment, a supplier query, or a complaint — your team has no reference number to work with.
What this means in practice:
- Amendments and cancellations with the supplier become much harder to process without a reference.
- If the customer has a problem on the day, your team cannot quickly escalate to the supplier.
Typical resolution:
Contact the supplier to retrieve the reference and update your records. Check whether the original booking process has a gap that is causing these to be missed consistently.
Travel approaching without confirmation
The booking's travel start date is within the next two weeks, but the booking is still not confirmed or ticketed. Severity rises as the travel date gets closer — bookings travelling within three days are flagged Critical, within seven days High, otherwise Medium.
What this means in practice:
- The customer may turn up to a service with no valid reservation and no way to proceed.
- Last-minute supplier contact is harder, slower, and more expensive than confirmation earlier in the cycle.
- The closer the travel date, the higher the chance of a refund, compensation, or complaint.
Typical resolution:
Contact the supplier urgently to confirm. If they cannot honour the booking in time, proactively arrange an alternative or refund before the customer is affected.
Supplier cancelled but booking still active
The supplier has marked the booking as cancelled on their side, but your internal record still shows it as confirmed or ticketed. The customer is expecting a service the supplier is no longer holding for them.
What this means in practice:
- The customer is likely to turn up to a hotel, flight, or activity that has been cancelled without them being told.
- A supplier-side cancellation often comes with a refund or credit you are owed — if your records still show the booking as active, that money will sit uncollected.
Typical resolution:
Confirm the cancellation with the supplier, update the internal booking status, notify the customer, and either re-book with an alternative supplier or process the refund.
Captured payments don't match the booking total
The sum of captured payments for a booking is different from the booking total. The gap could mean the customer has been under-charged, over-charged, or that a refund or adjustment was processed in one system but not reflected in the other.
What this means in practice:
- Undercharges erode margin and may go unnoticed until the monthly reconciliation.
- Overcharges are a customer-facing problem and a likely source of chargebacks if not refunded quickly.
- The mismatch often indicates an upstream process issue — a price change, partial refund, or amendment that didn't propagate everywhere it needed to.
Typical resolution:
Reconstruct what should have been charged from the booking timeline, identify whether the booking total or the payment total is correct, and either issue a balancing charge or a refund to bring the two into alignment.
Duplicate captured payments
The same booking has multiple captured payments where it should only have one. The customer has almost certainly been charged twice — either because a payment was retried after a perceived failure, or because a manual capture was processed alongside an automated one.
What this means in practice:
- This is the most common form of direct money leakage and the fastest route to a customer complaint or chargeback.
- Left unresolved, the duplicate sits on the customer's statement and erodes trust regardless of whether they eventually notice.
- Patterns of duplicates from the same source usually point to a retry or capture-handling bug worth fixing upstream.
Typical resolution:
Identify the genuine payment, refund the duplicate immediately, and notify the customer with a short explanation. If duplicates are recurring, investigate the upstream capture process before more customers are affected.
Urgency levels
Every exception is assigned a severity level. Think of this as an indication of how quickly it needs to be addressed:
| Level | What it means | Target response |
|---|---|---|
| Critical | Direct financial exposure or risk of immediate customer impact. | Same business day |
| High | Significant operational risk that will escalate without action. | Within 48 hours |
| Medium | A gap that creates operational difficulty if left unresolved. | Within the week |
| Low | A data quality issue worth cleaning up, but no immediate risk. | Next reconciliation cycle |
Moving an exception through resolution
Every exception has a status that reflects where it is in your team's workflow. When an exception is first raised, it is Open. Your team then moves it through the following stages:
Newly detected. No one has reviewed it yet. All exceptions start here.
Someone has looked at it and confirmed it is a real issue, but has not yet started investigating. Useful for flagging that it is on your radar.
Actively being worked on. Use this when you have contacted a supplier, raised a query, or initiated a refund but are waiting for a response.
The underlying issue has been fixed. The booking has been confirmed, the supplier has been notified, or the reference has been obtained.
The issue is real but your team has made a deliberate decision not to act on it — for example, because the booking value is below a threshold, or a business arrangement means it is expected. Always add a note explaining why.
Tripwise flagged something that turns out not to be a genuine problem — often caused by a timing delay in your data feeds, or a known quirk in how a supplier sends confirmations.
Every status change is recorded
Working an exception
Click any exception from the list to open its detail page. This is where you take action.
Changing the status
A row of action buttons at the top of the page lets you move the exception to the appropriate status with a single click. The options shown depend on where it currently is — for example, an Open exception shows options to acknowledge it, mark it in progress, resolve it, ignore it, or mark it as a false positive.
Adding notes
Use notes to document what you have found and what action you have taken. Notes are visible to everyone in your organisation who can see that exception, and they are attributed to you with a timestamp.
Good notes make it much easier for a colleague to pick up where you left off, and they create the evidence trail you need if a client or auditor asks about a specific case later. For example:
Activity log
The activity section at the bottom of the exception page shows a complete timeline — every status change and every note added, in chronological order, with the name of the person who made each entry.
Filtering the exception list
The Exceptions page lets you filter the list in three ways:
- Status — The most common filter is to show only Open exceptions, which are the ones that still need attention.
- Severity — Useful when you want to work through Critical issues as a batch before moving to High and then Medium.
- Type— Helpful when your team divides work by exception category — for example, one person handles all "charged, not confirmed" cases while another handles supplier mismatch cases.
Filters can be combined. Active filters appear as labels above the table. Click Clear filters to go back to the full list.
A real-world example
Here is what a typical reconciliation cycle might produce:
- Your team uploads bookings, payments, and supplier confirmations for last week.
- Tripwise processes the files and raises 23 exceptions.
- 15 are charged, not confirmed — payments captured for bookings that never received a supplier confirmation. Total value: £11,200. These are all rated Critical.
- 5 are supplier confirmation mismatches — confirmations arrived for bookings your system shows as cancelled. Rated High.
- 3 are missing supplier references — confirmed and paid bookings with no reference on file. Rated Medium.
- The Overview recommendation tells you to start with the Critical group. Your team contacts suppliers for the 15 unconfirmed cases, resolves 12, and escalates 3 for refund processing.
- By end of day, the Critical count is down to 3 and the amount at risk has dropped from £11,200 to £2,400.