Design B2B travel platforms around the account, not the booking
In B2B travel, every agency, sub-agent and corporate client expects its own pricing, credit, permissions and reports. Putting the account at the centre of the data model keeps those rules manageable.
Consumer booking platforms revolve around a search box and a checkout. B2B travel platforms revolve around accounts: agencies, their branches, their sub-agents and the corporate clients they serve. Each one expects to see different prices, spend against different limits and access different features. If the booking is the centre of your data model, those rules end up scattered across the code. If the account is the centre, they have a home.
Model the hierarchy explicitly
Most B2B travel businesses are trees. A distributor serves agencies; agencies have branches and sub-agents; sub-agents serve end clients. Represent that tree directly, with each account knowing its parent. Pricing, permissions and reporting can then inherit down the tree with explicit overrides at any level.
Make pricing a pipeline
Markup in B2B travel is rarely one number. A typical price passes through several layers: the supplier’s net price, the platform’s margin, the parent agency’s markup and the sub-agent’s markup. Implement this as an ordered pipeline of rules, each scoped to an account, product type and optional conditions such as route or supplier. Record the result of each step on the booking. When someone asks why a fare cost what it did, you can show them.
Treat credit as a ledger
Credit limits, deposits and top-ups are financial records, not settings. Keep a ledger of every debit and credit against each account, and derive the available balance from it. Reserve funds when a booking is held and settle or release them when it is ticketed or cancelled. This makes reconciliation possible and prevents two simultaneous bookings from overspending the same limit.
Separate roles from accounts
Within one agency, a ticketing manager, a junior agent and an accountant need different access. Model users and roles separately from accounts, with permissions expressed as capabilities — can book, can issue, can view financials — rather than hard-coded role names. New roles then become configuration instead of code.
Report from the same model
Because pricing steps, ledger entries and bookings all reference accounts, reporting becomes a query rather than a project. Each level of the hierarchy can see its own sales, margins and outstanding balances, and the platform operator can see everything.
The takeaway
In B2B travel, the account is the product. Design the hierarchy, pricing pipeline and ledger first, and the booking flow becomes the simplest part of the system.