---
title: "Travel Event Reconciliation Architecture"
description: "Design deterministic reconciliation across booking, payment, cancellation and supplier events with explicit authority and audit rules."
slug: "travel-event-reconciliation-architecture"
translationKey: "architecture-travel-event-reconciliation"
locale: "en"
type: "guide"
category: "architecture"
tags: ["reconciliation","booking","payment","event","travel"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

Booking, payment, webhook and supplier-report systems can describe the same transaction at different times and with different identifiers. Reconciliation exists to **prove which state is authoritative and resolve divergence in a traceable way**.

## Production scenario

A booking create call times out. The provider later sends CONFIRMED, payment is captured, the internal record remains UNKNOWN and the overnight supplier report contains the booking again.

## Architecture flow

```text
API Response / Webhook / Payment / Supplier Report
 -> Normalize Event
 -> Correlation Keys
 -> Deduplication
 -> Event Ordering
 -> State Comparison
 -> Reconciliation Rule
 -> Corrective Action
 -> Audit Record
```

## Correlation keys

Prefer internal booking ID, attempt ID, provider reference, idempotency key and payment transaction ID. Traveler/product/date composite keys are useful only as weaker fallback evidence.

## Source authority

Define which source is authoritative for each fact. Provider booking references may decide booking existence; PSP state may decide payment state; matured supplier reports may decide settlement.

## Trade-offs

Real-time reconciliation reduces inconsistency windows but increases complexity. Batch reconciliation is simpler but slower.

A hybrid model often works well: near-real-time for critical operational mismatches and scheduled reconciliation for finance.

## Failure modes

Expect duplicates, missing webhooks, delayed provider reports, out-of-order cancellations, payment/booking divergence and duplicate provider references.

## Idempotency and replay

Reconciliation must be rerunnable. The same evidence set should produce the same corrective outcome.

## Observability

Track unreconciled records, reconciliation latency, auto-fix rate, manual review, booking/payment divergence and duplicate-reference incidents.

## Alternatives

Daily SQL can be enough for low-volume systems. Multi-provider products with payment flows benefit from an explicit event/reconciliation service.

## Production checklist

Define source authority, stable correlation keys, idempotent rules, replay, audit trails, manual review and separate operational versus financial reconciliation.