Self-billing (389)

In platform and merchant-of-record arrangements, the party that collects the money issues the invoice in the supplier's name. That's a self-billed invoice — document type 389 — and TaxLens issues it against its own fiscal counter, in the host's identity, while preserving who-owes-what.

What self-billing is

Normally a seller invoices its buyer. In self-billing, the buyer or an intermediary issues the invoice on behalf of the supplier — with the supplier's legal identity as the seller party. This is standard in marketplace and merchant-of-record setups: an OTA acts as merchant of record, collects from the guest, and self-bills in the host/property's name.

Who issues, in whose name

The platform issues the document, but the supplier (host) is the named seller.

How to issue a 389

Issue the same way as a normal invoice, but flag it self-billed. For the 389 to be issued in the host's name and on the host's fiscal sequence, set supplier_legal_issuer_id on the booking — the host whose name goes on the document — alongside the platform's own issuer. Without it, the 389 issues under the platform's own issuer and sequence, which defeats the point of self-billing.

curl -X POST https://api.taxlens.getdynamiq.ai/v1/bookings/4821/issue \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "self_billed": true }'

# → 200
# {
#   "id": 9203,
#   "document_type": "389",      // self-billed invoice
#   "series": "S",
#   "invoice_number": "S-2026-000012",
#   "status": "issued"
# }

Default it on the property

Set default_supplier_legal_issuer_id on a managed property and every booking for it inherits the host-as-supplier issuer automatically (default_legal_issuer_id fills the platform side). Property defaults only affect future bookings.

How it renders

Own fiscal counter. 389 documents draw from a separate gapless sequence (their own series), independent of the 380 commercial-invoice counter. See Fiscal numbering & immutability.
Rendered as a UBL Invoice — not a CreditNote. A 389 is still a positive invoice; only 381/396 reversals use the CreditNote root.
Routing is frozen. The merchant-of-record collection info (collection_info — who collects which tax component) is already captured in the calculation and frozen into the issued document.

A 389 freezes the booking too

Like a 380, a live 389 freezes the booking — adjust, void, refund, and invoice-details all return 409. Corrections go through a credit note.

When to use it

Reach for a 389 when:

You operate as a platform or OTA acting as merchant of record for a host's stay.
The host is the legal supplier of the accommodation, but you collect and invoice.

For the merchant-of-record routing that underpins this, see Channels & merchant of record and OTAs.