A travel agency does not sell items off a shelf; it assembles a file. One booking bundles an air segment from a consolidator, two hotel nights on a net rate, a transfer, an insurance policy and a visa fee — each from a different supplier, each with its own confirmation reference, cancellation deadline and payment terms, and some sold gross with commission while others are sold net with a markup. Dynamics 365 Business Central handles the accounting side of this perfectly well once the numbers exist, but out of the box there is no object that represents the file itself. Agencies end up running the operation in spreadsheets and the ERP in arrears: a sales invoice with free-text lines, a purchase invoice keyed when the supplier statement arrives, and no reliable way to answer "what did file 2026-0413 actually earn?" until someone reconciles it by hand. BSP and consolidator statements make it worse — hundreds of ticket lines settling in one weekly draft against payables that were never posted as separate documents.

What we build is an AL extension that adds the missing operational layer and then feeds Business Central's standard financial engine rather than working around it. A new Booking File table carries the traveler sub-table, the sell currency, the file status and the responsible agent; each Booking Component line holds a service type, the supplier vendor, the supplier confirmation or PNR reference, service dates, a cost side (net cost, tax, supplier commission) and a sell side (gross sell, markup or commission basis). Costing runs in a codeunit that computes per-component and per-file margin in both gross-commission and net-markup models, holds provisional cost until the supplier confirmation is matched, and posts through to standard documents: sell lines flow into a Sales Invoice, cost lines into Purchase Invoices per vendor, and file-level margin is carried on dimensions so Business Central's own Analysis Views, Account Schedules and Power BI reports slice profitability by destination, agent, product type or corporate client without any parallel reporting stack.

The supplier and BSP side is where most of the engineering sits. We add a reconciliation workspace that imports supplier and BSP statement files (CSV, fixed-width, or the format your consolidator actually sends), matches lines to booking components on ticket number, PNR or confirmation reference with a tolerance-based fallback on amount and date, and posts the matched batch as vendor payables and commission entries in one run. Unmatched and disputed lines stay in a queue with an audit trail rather than being force-posted, so the settlement draft always ties out. A Job Queue Entry runs statement pickup and deadline monitoring on a schedule — ticketing time limits, option deadlines and unconfirmed components surface as notifications and a Role Center cue instead of being remembered. Customer documentation is generated from the file itself: itinerary, voucher and travel invoice as Word/RDLC layouts you can rebrand, with optional dispatch through the standard Business Central email accounts. Everything is exposed on API pages (REST API v2.0 / OData v4) so a website booking engine, a mid-office tool or a Power Automate flow in Dataverse can create and read booking files programmatically, and dedicated permission sets separate agents, ticketing staff and finance.

Delivery is build-to-order, and we are explicit about what that means. This is not an existing Microsoft AppSource download you install today — it is source we write, install and support for your tenant. It starts with a short scoping call where we walk your actual booking flow, your supplier mix, a sample BSP or consolidator statement, and your current chart of accounts and dimensions. From confirmed scope, typical delivery is one working week. We build against your Business Central version — current release waves on SaaS, or on-premises where you run it — deploy first to a sandbox for UAT with your own data, then install to production with a rollback plan. You receive the AL source, a git repository handover, technical and user documentation, and a post-go-live support window. The extension ships as a per-tenant extension by default; if you want it published to AppSource under your own publisher account, we structure the app that way from the start.