OTAs & marketplaces

The single idea that unlocks OTA tax is that a marketplace booking contains two distinct supplies, each taxed on its own terms:

• The room — a service connected to immovable property. Under EU VAT Directive Art. 47 it is always taxed where the property is, with local VAT. The room is never reverse-charged, regardless of who the guest is or where your platform is established.
• Your commission / intermediary service — a separate supply from your platform to the property. This is where cross-border B2B reverse charge (Art. 44/196) can apply, and where the merchant-of-record routing actually changes who collects the room taxes.

merchant_of_record is the field that tells the engine who is responsible for collecting the room taxes. It does not change how much tax there is — the stack is identical — it changes the collection_info routing in the response.

The scenario map, straight from the calculation surface:

The exhaustive scenario → field map lives in scenario fields, and the routing concept in channels & merchant of record.

Each maps to a specific combination of fields:

1. 1
   Agency model — property is MoR

   Set merchant_of_record: "property". collection_info surfaces who owes what; your commission goes through line_items with item_type: "commission". The room taxes remain the property's to collect.
2. 2
   Merchant model — platform is MoR

   Set merchant_of_record: "platform". The room tax is unchanged, but collection_info routes every room category to platform_collected_components — you collect and remit.
3. 3
   Marketplace facilitator (split collection)

   Some city laws make the platform collect the city tax while the state/VAT stays with the property. That's expressed per-rate via collection_model on the city-level rate — so a single calculation returns a split collection_info. No hand-authored mutual exemptions.
4. 4
   Channel-mutex rates

   Where a city has separate articles for direct vs platform bookings (e.g. distinct occupancy-tax articles), they are two channel-scoped rates, not two exemption rules. The booking's resolved channel selects the right one — set is_marketplace / platform_type accurately.

When your platform is established in a different country from the property and supplies an intermediary service B2B, the commission is reverse-charged: you charge 0% VAT and the property accounts for it. TaxLens models this precisely — and the precision matters, because getting the mechanism wrong corrupts the EN 16931 category mapping.

// POST /v1/tax/calculate
// US platform (MoR) intermediating a German hotel for a business guest.
// Room: German VAT, local (Art. 47), never reverse-charged.
// Commission: reverse-charged (AE) because supplier country != property country.
{
  "jurisdiction_code": "DE",
  "stay_date": "2026-09-01",
  "nights": 2,
  "nightly_rate": 180,
  "currency": "EUR",
  "property_type": "hotel",
  "merchant_of_record": "platform",
  "customer_type": "business",
  "business_tax_id": "DE123456789",
  "commission_supplier_country": "US",
  "line_items": [
    // amount is PER NIGHT: €36/night × 2 nights = €72 commission base
    { "description": "Platform commission", "item_type": "commission", "amount": 36 }
  ]
}

As merchant of record you often issue the invoice in the property's (supplier's) name — self-billing. TaxLens issues this as a 389 document on its own fiscal counter, rendered as a UBL Invoice (not a credit note), with the merchant-of-record routing already frozen into collection_info.

# The supplier_legal_issuer_id is the host/owner (the named seller on a 389).
# A managed property can supply this from default_supplier_legal_issuer_id.
curl -X POST https://api.taxlens.getdynamiq.ai/v1/bookings \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "external_reference": "OTA-RES-55120",
    "idempotency_key": "OTA-RES-55120",
    "supplier_legal_issuer_id": 77,
    "calculation": {
      "jurisdiction_code": "DE",
      "stay_date": "2026-09-01",
      "nights": 2,
      "nightly_rate": 180,
      "currency": "EUR",
      "merchant_of_record": "platform"
    }
  }'

A platform integration typically: calculates per channel with the right merchant_of_record, attaches its commission as a line item, sets commission_supplier_country so cross-border commission reverse-charges correctly, persists the booking, and issues self-billed (389) where it bills in the supplier's name. Inspect collection_info on every response to confirm the split before you rely on it.

{
  "jurisdiction_code": "DE",
  "stay_date": "2026-09-01",
  "nights": 2,
  "nightly_rate": 180,
  "currency": "EUR",
  "property_type": "hotel",
  "merchant_of_record": "platform",
  "is_marketplace": true
}

Selling direct or managing inventory too? See Hotels and Property managers.