Chapter 3.2 — Suppliers

1. Purpose

This chapter defines the Supplier entity — the parties from whom the partner sources travel inventory: airlines (via GDS or NDC), low-cost-carrier aggregators, hotel wholesalers, ground-transport providers, insurance underwriters, and the BSP itself as a settlement counterparty. Suppliers are the right side of the platform's accounts-payable picture; every operational booking creates a payable obligation that the supplier model must track precisely.

2. Why it matters in modern travel accounting

Supplier accounting in travel is fundamentally different from generic AP: - An airline ticket triggers a BSP weekly settlement, not a per-invoice payment. - A hotel booking on a "pay-at-property" model creates no AP at all (commission-only revenue). - A direct-connect (NDC) supplier may invoice per-booking with diverse payment terms. - Commission and override structures change supplier net amounts after the fact. - ADM (Agency Debit Memos) and ACM (credits) re-open closed periods.

A clean supplier master and well-modelled supplier-type behaviour is the foundation of accurate AP, BSP reconciliation, and commission accounting.

3. Industry relevance

The platform models supplier diversity through supplier types and settlement modes rather than per-supplier custom code, allowing partners to onboard new suppliers without engineering changes.

4. Compliance considerations

• IATA accreditation — airline suppliers transacted through BSP require IATA membership; agent code captured per partner.
• IFRS 15 — Principal vs Agent — supplier model holds the flag that determines whether the partner is principal (gross revenue) or agent (net commission revenue). This is the single most impactful classification in travel accounting.
• Withholding tax — for non-resident suppliers in certain jurisdictions, withholding may apply at payout.
• Sanctions screening — suppliers screened at onboarding and re-screened.

5. Business logic

5.1 Supplier types

5.2 Supplier record structure

5.3 Principal vs Agent

Under IFRS 15, the partner is the principal when it controls the service before transfer to the customer (it bears inventory risk, sets the price, takes credit risk). It is the agent when it merely arranges supply (commission seller).

The classification flag is per-supplier-relationship, not platform-wide, because the same partner may be principal on one supplier and agent on another:

The JE engine reads principal_or_agent at booking-issuance to choose revenue recognition pattern (Ch 5.8 commission vs Ch 5.1 main revenue).

5.4 Commission model

Suppliers may offer: - Base commission — flat % on ticket base fare - Tiered commission — based on volume thresholds - Override commission — quarterly/annual back-end paid as ACM - Net rates — supplier sells at net; partner marks up - Incentive schemes — segment-count, route-specific

Commission rules attached to a supplier are evaluated at issuance, accrued to a receivable account (1109 — Commission Receivable from Supplier), and cleared when BSP settles or an explicit commission invoice posts.

See Chapter 5.8 — Commission Accounting for full mechanics.

5.5 BSP settlement linkage

For supplier_type = AIR_BSP, the supplier record is not the direct counterparty for settlement — the BSP itself is. Operational ticket issuance creates a payable to "BSP Payable" (control account 2011) sub-coded by: - BSP country (bsp_country_code) - Billing period (BSP semi-monthly billing periods)

Per-airline AP-style detail is preserved via journal_entry_lines.supplier_id for reporting, but cash settlement is one wire to BSP, not per-airline.

See Chapter 4.6 — ADM/ACM and Chapter 11.3 — BSP/ARC Import for full treatment.

5.6 Supplier payout (non-BSP)

For non-BSP suppliers, payout workflow: 1. Open AP balance per supplier visible on supplier_balances. 2. Accountant initiates a payout run selecting one or many open supplier invoices. 3. System validates total, currency, bank details. 4. Maker submits payout; checker approves (above threshold). 5. Payment file generated (bank-format-specific) or gateway call made. 6. Once cleared, AP is relieved with a JE.

6. Inputs → processing → outputs

Create supplier

Input: form / API payload.

Processing: 1. Validate (partner_id, supplier_code) uniqueness. 2. If supplier_type = AIR_BSP, require iata_code and bsp_country_code. 3. If principal_or_agent = principal, mark requires-VAT-config. 4. Insert; queue sanctions screening. 5. Emit supplier.created event.

Output: supplier_id.

7. Module dependencies

8. Security & permissions

Bank details are particularly sensitive — every read of supplier_bank_details is audit-logged with the reading user/principal.

9. Validation rules

10. Error handling

Same envelope as customers. Bank-detail edits trigger mandatory MFA re-prompt and 30-minute payment hold to mitigate vendor-fraud attacks (a common attack vector).

11. Real-world examples

Example A — Emirates as BSP airline

• supplier_code = EK
• supplier_type = AIR_BSP
• iata_code = EK
• bsp_country_code = BD (Bangladesh BSP)
• principal_or_agent = agent
• default_commission_rate = 0.0000 (zero base for most LCCs nowadays; overrides handled separately)
• default_currency = USD (billing currency in BD BSP for international tickets)

Issuance of an EK ticket creates AP to "BSP Payable BD" not directly to Emirates. Per-supplier reporting still distinguishes the EK obligation.

Example B — Hotelbeds net-rate supplier

• supplier_code = HBD
• supplier_type = HOTEL_PREPAID
• principal_or_agent = principal (partner takes inventory risk and marks up)
• settlement_mode = per_invoice
• payment_terms_days = 21
• default_currency = EUR

A booking creates AP directly to Hotelbeds in EUR; FX translates to BDT functional at booking date; commission/markup recognised as gross revenue minus COGS.

Example C — Vendor-fraud attempt

Attacker compromises a procurement email account and emails the accountant requesting a bank-detail change for a major hotel supplier. Accountant edits the bank details in travoBooks. The system: 1. Prompts MFA re-confirmation. 2. Sends out-of-band notification to partner_admin. 3. Places 30-minute hold on all payouts to this supplier. 4. Logs the change in supplier_bank_history.

Partner_admin sees the alert, contacts the supplier through known-good channel, discovers the fraud, reverses the change before any payout occurs.

12. Step-by-step workflow

13. Database tables touched

14. Future scalability

• Supplier portal — suppliers log in to view their payouts, dispute discrepancies, upload invoices.
• Auto-reconciliation for direct-connect — match supplier-pushed invoice file against booking events.
• Commission-recovery engine — automatically open dispute when expected commission not received.
• Supplier scoring — quality metrics (issue rate, ADM rate, support responsiveness) feeding offer-ranking.

15. Common pitfalls

• ⚠️ Don't post AP directly to airline suppliers when settlement is via BSP. The right counterparty for the payable is the BSP control account. Per-airline detail lives in dimensions, not in the account code.
• ⚠️ Principal/agent flag is sticky. Once a booking is issued, changing the supplier's classification does not retroactively change recognised revenue.
• 🔒 Bank-detail edits are high-risk. Mandatory MFA + 30-minute payout hold is non-negotiable.
• ⚠️ Commission rates with no end date can outlive their negotiation. Always capture valid_from and valid_to.