Chapter 4.3 — Refunds & Cancellations

1. Purpose

This chapter defines how travoBooks processes refunds, cancellations, and money-out events for previously issued bookings. It covers refund quoting (per fare rules), refund authorisation (supplier and customer sides), the financial reversal mechanics including commission recall, and the customer-payback paths (cash, gateway reversal, customer credit balance, bank transfer). Voids (same-day reversal) are touched in Chapter 4.2; this chapter focuses on post-void-window refunds.

2. Why it matters in modern travel accounting

Refunds are the most error-prone area in travel accounting. Common failure modes: - Customer refunded gross amount but commission never clawed back from supplier → margin loss - Refund posted in the wrong period after period close → restatement - ADM issued by airline for incorrect refund computation → cash leakage - Partial refund not aligned with fare-rule penalty → revenue overstated - Customer credit balance accumulates without expiry policy → silent liability

travoBooks' refund engine treats every refund as a structured, multi-party, multi-account financial event rather than a single negative line.

3. Industry relevance

The model accommodates: - Air refunds (full/partial, voluntary/involuntary, refundable/non-refundable with taxes-only refund) - Hotel cancellations (free-cancel window, partial penalty, full penalty) - Tour / package cancellations (tier-based penalty schedule) - Insurance (typically non-refundable after cooling-off) - Ancillary EMD refunds (often non-refundable)

4. Compliance considerations

• IFRS 15 — reversal of recognised revenue when contract obligation extinguished; if revenue not yet recognised (advance payment), liability adjusted.
• IFRS 9 — refund estimates form part of variable consideration in some package contracts; not material for Phase 1.
• GAAP — ASC 606 — equivalent treatment.
• Consumer protection laws — many jurisdictions mandate timeframes for refund issuance.
• PCI DSS — gateway refund flows must not log card data; only token references.

5. Business logic

5.1 Refund types

Each type drives different penalty / commission-recall logic.

5.2 Refund states

5.3 Refund record structure

5.4 Refund quote computation

For air, the quote calls supplier Refund_QuoteRefund / OrderReshopRQ (refund) which returns: - Penalty (cancellation fee retained by supplier) - Refundable amount per pax per ticket - Tax refundability - Original form-of-payment

travoBooks layers on top: - Partner-side fees — service fee retained per partner config - Commission recall — original commission must be reversed (supplier won't pay commission on refunded ticket) - Currency — refund in original transaction currency at original FX rate for the reversal portion; new FX rate for any commission-recall denominated differently

For hotel / non-air, the quote follows the captured cancellation policy (free until date X, penalty Y% between dates).

5.5 Approval thresholds

A refund requires approver when any of: - customer_refund_amount > partner.refund_approval_threshold - refund_type = WAIVER (any amount) - Booking period is closed (requires period reopen — controller-level approval) - Commission recall fails (supplier won't accept) and partner-config requires manual override

5.6 Financial mechanics (the JE)

Refund posting is the inverse of issuance, with overlays for penalty and commission. Continuing the Beta Corp Emirates DAC-DXB example (issued at USD 600 = BDT 65,400):

Voluntary refund with USD 100 penalty kept by EK, USD 25 partner service fee retained:

Customer net refund: USD 600 ticket − USD 100 EK penalty − USD 25 partner fee = USD 475 ≈ BDT 51,775 (illustrative FX at refund date).

Key invariants: - The refund JE reverses the original issuance JE for the refundable portion only. - Penalty (supplier-kept) stays in supplier-payable but is reclassified as 5099 — Supplier Cancellation Penalty expense flowing through pass-through; alternatively suppressed if it was never our cash. - Commission recall is always posted symmetric to original commission recognition. - Service fee retention (partner's own) is not reversed unless partner policy says so.

5.7 Customer payback paths

Payback is a separate event from the supplier-refund execution. The pattern is: 1. Supplier refund executed → debit booking-side accounts; AR / cash-out account debited. 2. Customer payback → AR or cash-out cleared.

If payback fails (gateway rejects, bank details wrong), the customer is left with a customer credit balance automatically, with notification to accountant.

5.8 Period considerations

If the original issuance is in a closed period, the refund cannot post into that period. travoBooks enforces: - Refund JE date = current open period. - The JE references the original JE for traceability but does not back-date. - Period-close reports include "refunds against prior-period revenue" disclosure.

If the original is in a locked period (auditor-locked), no refund JE is allowed without controller override.

5.9 Cancellation without refund

Some cancellations have zero refund (fully non-refundable, post-departure cancellation, no-show with no recoverable taxes). The booking still transitions to CANCELLED_AFTER_ISSUE, but no refund JE is needed (or only commission-recall is needed if applicable).

6. Inputs → processing → outputs

Process refund

Input: {booking_id, refund_type, reason_code, reason_text, override_supplier_quote?, payback_method}

Processing: 1. Permission check (bookings.refund.partner). 2. Validate booking state in (ISSUED, PARTIALLY_USED, PARTIALLY_REFUNDED). 3. Period check — current period open. 4. Quote refund from supplier (cached for 15 min). 5. Compute partner-side fees and commission recall. 6. Threshold check → maker-checker if required. 7. Begin DB transaction. 8. Execute supplier-side refund. 9. Persist refund record. 10. Post reversing JE. 11. Update booking state. 12. Update balances. 13. Commit. 14. Async: trigger payback path; send customer notification; webhook.

Output: refund_id, JE reference, estimated payback date, customer notification.

7. Module dependencies

8. Security & permissions

Above-threshold refunds always require checker different from maker.

9. Validation rules

10. Error handling

The most delicate failure is supplier accepted refund, payback failed — partner is out of pocket against an open AR. The workflow: 1. JE for supplier-side is committed (supplier did refund). 2. Payback fails → customer balance becomes a customer credit automatically. 3. Notification to accountant + customer. 4. Accountant can retry payback via different path (bank transfer instead of failed gateway).

Idempotency: refund operations carry Idempotency-Key; replays return original result, never double-refund.

11. Real-world examples

Example A — Full voluntary refund with penalty

(Beta Corp EK example above; see §5.6.)

Example B — Taxes-only refund on non-refundable

Customer no-show on a non-refundable Biman ticket (BDT 8,000 base, BDT 750 government taxes). Government taxes are recoverable; carrier-imposed are not.

JE:
  Debit 2011 BSP Payable BD                500
  Debit 4011 Air Base Commission             0  (none originally)
  Credit 1101 AR — Customer                500  (or Cash if walk-in)
Booking state: NO_SHOW_REFUNDED (partial state)

Example C — Hotel free-cancel

Hotelbeds booking, EUR 200, cancelled within free-cancel window.

Supplier confirms full refund.
JE: Debit 2003 AP — Hotelbeds          200 EUR (translated)
    Credit 1101 AR — Customer          200 EUR (translated at original FX)
    + FX gain/loss adjustment for translation difference
Booking state: CANCELLED_AFTER_ISSUE
Payback: gateway reversal (200 EUR back to card)

Example D — Cross-period refund

Ticket issued in April (closed period). Customer cancels in June.

Quote: BDT 60,000 refund.
JE dated 2026-06-15 (June, current open period):
  Debit BSP Payable, debit commission recall, credit AR/Cash, etc.
Booking links to original JE in April but does not modify it.
Period-close report for June shows BDT 60,000 in "refunds against prior periods".

12. Step-by-step workflow

13. Database tables touched

14. Future scalability

• Auto-refund engine — for high-volume OTAs, auto-refund within free-cancel window without human touch.
• ATPCO-aware quote engine — pre-compute refund quotes from fare rules without supplier round-trip.
• Refund-prediction model — flag bookings with elevated refund probability for staffing.
• Customer credit expiry policy — automatic expiry of stale customer credit (with statutory notice).

15. Common pitfalls

• ⚠️ Forgetting commission recall. The supplier will not pay commission on a refunded ticket — if you don't recall it, you double-count revenue.
• ⚠️ Refunding in original FX rate vs. current rate. Use the original rate for the reversal portion; FX gain/loss is a separate line.
• ⚠️ Posting back-dated refunds into closed periods. Always use current-period date; reference the original JE.
• ⚠️ Treating supplier-execution and customer-payback as one event. They are two — model them separately.
• 🔒 Gateway refund flow must not log card data. Token references only.
• ⚠️ Quoting refunds without re-fetching. Quotes age out; always re-fetch within 15 minutes of execution.