A travel agency does not sell a stock item. It assembles a file: two air segments from a consolidator, four hotel nights from a bed bank, a transfer, a visa, insurance — each with its own supplier, its own confirmation reference, its own payment terms and its own cancellation deadline. ERPNext handles the money side of that well once it exists as a Sales Invoice and a set of Purchase Invoices, but nothing in ERPNext core holds the file together. There is no DocType where a traveler list, a PNR, five supplier confirmations and a client quotation live as one record, so agencies run the operation in spreadsheets and only tell ERPNext what happened after the trip departed. The predictable result: nobody can answer "what did file TRV-2481 actually make?" until month-end, and supplier statements get reconciled by eye.

We build a proper Frappe app — travel_agency_operations, its own module, installed with bench get-app and bench --site install-app, never a pile of Custom Fields bolted onto Sales Order. The spine is a Booking File DocType with child tables for Traveler (name as per passport, document number, expiry, ticket or voucher number) and Booking Service (service type, supplier, confirmation reference, service dates, cost currency and amount, sell amount, cancellation deadline). Each Booking Service row links to the ERPNext Supplier and, once confirmed, to the Purchase Invoice that recognises the payable — so the file is never a parallel ledger, it is a controller over standard accounting documents. Package costing is computed in the Booking File server-side controller: cost lines convert at the exchange rate captured on the service date, markup applies per service or per file according to a Travel Settings single DocType, and gross margin, margin percent and unbilled cost are stored as read-only fields you can group and report on in the ERPNext query report builder.

Technically the app leans on Frappe rather than fighting it. Document events registered in hooks.py (validate, on_submit, on_update_after_submit) enforce the rules that actually cause losses — a file cannot be submitted with a service priced below cost unless a user holding the Travel Manager role overrides it, and a supplier confirmation reference is mandatory before a service moves to Confirmed. A scheduler_events daily job scans open files for cancellation deadlines falling inside a configurable window and raises ToDos plus an email digest to the file owner, which is the single control that stops silent no-show charges. Client Scripts on the Booking File form give the consultant an inline margin panel and a one-click Sales Invoice action that pulls only services flagged billable. Whitelisted methods (@frappe.whitelist()) expose file creation, service confirmation and status lookup over the Frappe REST API so a GDS bridge, a B2B portal or a messaging bot can push confirmations in without touching the desk; every endpoint runs under standard Frappe permission checks, and we ship Role Profiles for Travel Consultant, Travel Manager and Accounts with permlevel restrictions so a consultant can build files but never edit a submitted supplier cost.

Supplier and BSP reconciliation is its own DocType. A Supplier Statement Import accepts the BSP/ARC or bed-bank statement as CSV or XLSX, matches lines against Booking Service rows on confirmation reference and ticket number, and produces three buckets — matched, amount-variance and unmatched — with a Reconcile action that posts accepted lines against the corresponding Purchase Invoices and routes the variance to a configurable expense account. Nothing posts silently: every reconciliation run leaves an audit record naming the user, the source file and the resulting GL entries. Customer documentation uses Frappe Print Formats and Letter Heads — itinerary, service voucher and traveler-level ticket summary — generated from the same file, so what the client receives and what the accounts show cannot drift apart.

This is build-to-order, and we are explicit about what that means. There is no download button; there is a scoping call. We walk your current desk workflow, your supplier mix, your statement formats and your ERPNext version, agree a written scope, then build against that scope, test on a staging site restored from your data, and hand over with source. Typical delivery is two to four weeks from confirmed scope, depending on how many statement formats and integrations are in play. You receive the git repository, so the app is yours to keep, fork and extend whether or not you continue with us.