Markup and commission rules engines for B2B travel platforms

A markup rules engine turns a supplier’s net price into the price a specific customer sees. On a B2B travel platform, one hotel night or airfare can be sold to many agencies, each with its own negotiated terms, and each agency may add its own markup for its customers. The engine that applies those layers is small in code and large in consequence: a wrong rule sells below cost or overprices a whole market, and nobody notices until margins or conversion move.

The layers of a B2B price

A typical selling price is built in layers:

1. Supplier net or gross. Net rates come without margin; gross or published fares may include a commission the supplier pays back.
2. Platform markup or discount. The platform’s own margin, which may vary by supplier, product, market or customer tier.
3. Account terms. Negotiated adjustments for a particular agency, consolidator or corporate client.
4. Agent markup. The agency’s own markup for its end customer, often configured by the agency itself in a white-label storefront.
5. Taxes and fees. Supplier taxes passed through, plus any service fees, which may or may not be subject to markup.

The engine must know which layer each adjustment belongs to, because different users are allowed to see different layers. An agent should see their net and their own markup; they should not see the platform’s margin. The account-centred design decides who can see and edit what.

Modelling a rule

A rule has three parts: conditions, an action and metadata.

• Conditions — product type, supplier, route or destination, star rating or cabin, travel and booking date ranges, account or account group, channel, point of sale.
• Action — a percentage, a fixed amount per booking, per passenger or per night, or a combination with a floor and a cap.
• Metadata — owner, priority, validity period, who created and approved it, and a reason.

Keep the rule language deliberately limited. A small set of well-understood condition types is easier to test, explain and index than a general expression language that lets anyone write anything. If you need more flexibility later, add a condition type rather than an escape hatch.

Resolving conflicts

The hardest design decision is what happens when several rules match the same item. Pick one strategy, make it explicit and apply it everywhere:

• Most specific wins. A rule for one account and one supplier beats a rule for all accounts and that supplier. Count matched condition dimensions, and break ties with an explicit priority.
• Explicit priority only. Every rule has a number; the highest wins. Simple, but people must manage the numbers.
• Stacking. Rules in different layers always apply in sequence; within a layer, only one wins.

Most B2B platforms end up with stacking across layers and most-specific-wins within a layer. Whatever you choose, the engine should be able to explain itself: for any price, list every rule considered, which matched, which won and why.

Rounding, currency and floors

Small details cause real losses:

• Order of operations. A percentage applied before or after a fixed fee gives different results. Define the order per layer.
• Currency. Apply markups in a defined currency — usually the supplier’s or the selling currency — and convert once. Converting back and forth introduces drift; multi-currency pricing and FX covers where conversion belongs.
• Rounding. Round once, at the end, using rules per currency.
• Floors. A negative markup or a large discount can push the selling price below net. Enforce a floor at the platform layer so no combination of rules sells at a loss unintentionally.

Commission-based products need the reverse calculation: the expected commission must be recorded at booking so it can be reconciled later against the supplier’s statement — part of back-office reconciliation.

Store the breakdown with the booking

Prices are recalculated constantly during search, but a booking must remember exactly how its price was built. Store, with each booking:

• the supplier price as received,
• each adjustment with the rule ID, rule version and amount,
• the currency rates used,
• the final selling price per party: what the platform charged the agency, and what the agency charged its customer.

This breakdown answers most finance and support questions without anyone reconstructing old rule configurations. It also makes margin reporting a query instead of a project.

Changing rules safely

Rule changes are price changes, so treat them like deployments:

• Version every rule. Edits create a new version; bookings reference the version they used.
• Preview before activation. Show a sample of recent searches priced with the old and new rules side by side, so the person changing a rule sees its effect before customers do.
• Schedule activation. Allow rules to start and end at defined instants, rather than requiring someone to change them at midnight.
• Approve large changes. Changes above a threshold or affecting many accounts should need a second person.
• Keep an audit log. Who changed what, when and why.

Performance

Search is where the engine works hardest: every result in every search goes through it, and a search can return many results from several suppliers. Keep evaluation fast:

• load active rules into memory and refresh them on change, rather than querying the database per result,
• pre-index rules by their most selective conditions, such as product type and account,
• evaluate per distinct supplier price rather than per displayed result where products share a price,
• cache rule resolution for repeated combinations within one search.

Pricing that slows search down increases cost directly; look-to-book ratios explain why search volume dominates the bill.

Summary

A markup rules engine applies layers — supplier price, platform margin, account terms, agent markup, fees — and must know which layer each adjustment belongs to and who may see it. Keep the rule language small, choose one deterministic conflict strategy, define the order of operations, currency and rounding, and enforce a floor. Store the full breakdown with each booking, version and preview rule changes, and keep evaluation in memory so search stays fast. Done well, pricing becomes explainable; done loosely, it becomes the place margin leaks without anyone seeing it.