Chapter 0.1 — Platform Overview

chapter: 00-introduction/01-platform-overview
version: 1.0.0
status: stable
last_reviewed: 2026-05-26
owners: [platform-engineering, product]

1. Purpose

This chapter explains what travoBooks is, who it is for, and what problem it solves. It is intentionally non-technical in the first two sections and progressively becomes more technical. Read this first if you are new to the platform.

2. The problem travoBooks solves

Travel businesses today operate against four disconnected systems:

1. A GDS or supplier aggregator (Amadeus, Sabre, Travelport, or a NDC/direct-connect mix) for shopping and booking.
2. A mid-office for queue management, fulfilment, and ticketing oversight.
3. An accounting system (Tally, QuickBooks, Xero, SAP, Sage) for ledgers, payables and receivables.
4. A partner / commission billing system, usually a spreadsheet.

These systems do not share a transactional definition. A booking exists in the GDS. A fare bucket exists in the mid-office. An invoice exists in the accounting system. A commission share exists in the spreadsheet. They are reconciled by humans, monthly, with predictable consequences:

• Revenue leaks. Commission on ancillaries and reissues is forgotten because nothing in the accounting system knew the reissue happened.
• Refund timing drift. A refund is processed in the GDS today but posted to the ledger weeks later, distorting the period.
• Currency restatement is manual. Multi-currency books are restated by exporting CSVs and re-keying them.
• ADM exposure. Airline debit memos arrive after settlement and nobody has the original booking context to dispute them.
• Audit cost. Auditors need to trace a payment back to an invoice back to a booking back to a ticket — across four systems with four different identifiers.

travoBooks collapses these four systems into one by treating every operational event as a financial event from the first moment. There is no nightly sync from operations to accounting because they share the same database and the same transaction.

3. Who travoBooks is for

4. The architectural pillars (and why they are non-negotiable)

4.1 Double-entry by default

Every operational event that has a financial consequence generates a balanced journal entry inside the same database transaction as the operational change. This is the single most important architectural decision in the system.

Consequence: You cannot create a booking that is not in the ledger. You cannot refund a ticket without a reversing entry. The "ops vs. finance" reconciliation that defines most travel back-offices does not exist as a job because it cannot drift.

4.2 Multi-tenant by partition

A single application instance serves many partner tenants. Isolation is enforced by partner_id on every domain row, with three reinforcing layers:

• Application layer: every query is built through a partner-scoped repository that injects the active partner_id.
• Database layer: every domain table has partner_id NOT NULL with an index and a foreign key to partners.
• Connection layer: session variables (@partner_id) gate row-level checks for sensitive tables.

See 01-foundations/01-multi-tenancy.md for the full mechanism.

4.3 Multi-currency at the line level

Every monetary value is stored as {amount, currency_code}. There is no "default currency" at the column level. The platform distinguishes three currencies on every transaction:

The exchange rate used to convert transaction → functional is captured at the moment of posting and stored on the ledger row. Historical restatement is therefore deterministic. See 05-accounting/06-multi-currency.md.

4.4 Auditable by construction

The system distinguishes mutable operational state (e.g. a booking's status moves from quoted → confirmed → ticketed) from immutable financial state (a journal entry once posted is never altered).

• Operational tables carry updated_at and a paired *_history table.
• Financial tables are append-only. Corrections happen via reversing journal entries.
• Every state-changing API call writes a row to audit_logs keyed by actor_id, partner_id, entity_type, entity_id, before, after.

4.5 API-first

The UI is the first consumer of the public API, not a privileged one. This guarantees that any capability available to a human is also available to a system integrator.

5. What the platform does, in modules

The platform is internally organised as fourteen functional modules grouped into five layers. The full module map:

Each module is documented in its own chapter; see the Table of Contents.

6. Operating model in one paragraph

A partner is provisioned (Module 1). Users are created and assigned roles (Module 2). Master data is populated — customers, suppliers, chart of accounts, currencies, tax profiles (Modules 3–7). A booking is created against a supplier (Module 8) and is ticketed (Module 9), at which point the platform writes balanced journal entries (Module 12), creates a customer invoice (Module 13), records a supplier payable (Module 14), and accrues commission (Module 17) — all inside one database transaction. The customer pays (Module 15), the supplier is settled via BSP (Module 14 → 15), revenue is recognised at service date (Module 16), tax is computed at appropriate trigger points (Module 18). Throughout, audit logs (Module 20) are written and notifications (Module 19) are fired. The partner is billed for platform usage (Module 23). At month-end, financial reports are produced (Module 22) and the period is closed.

7. What travoBooks is not

To set expectations:

• Not a GDS. travoBooks integrates with GDSs; it does not replace them.
• Not a CRM. Customer master data lives here, but lead management, marketing automation, and customer-success tracking are out of scope.
• Not a corporate expense tool. travoBooks books and accounts for travel; it does not handle out-of-trip expense reimbursement.
• Not a tax filing engine. travoBooks computes and records tax; statutory filing remains with the partner's tax adviser.

8. Glossary spotlight (terms used heavily in this overview)

Full glossary: 03-glossary.md.

Next: 02-system-architecture.md — how the moving parts physically fit together.