> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Media billing entities
> The legal entities Scope3 invoices for media spend, and how they're routed to advertisers and accounts
Media billing is one of two money streams every organization has with Scope3
(the other is [interchange fees](/v2/buyer/billing/overview) — the platform
fees on your plan). Media billing entities are the legal entities Scope3
invoices for the media itself, and this page covers how they're defined and
how invoices are routed to them.
## Two streams, kept separate
* **Interchange fees** — platform fees, IU bundles/overage. Every
organization has this stream, sellers included. It's about your plan.
* **Media billing** — invoicing for media spend. This is what this page
covers.
A surface, invoice, or line item is always identifiably one stream or the
other — never a blended "billing." See
[Plan & Billing page](/v2/buyer/billing/plan-and-billing) for where each
stream renders.
## The routing hierarchy
Media billing entities are configured at up to three levels and resolved
**most-specific-first**. There's no "delegation" to configure — the presence
of an entity at a level is what routes that level's media invoices there:
| Level | Rule |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Advertiser** | If an advertiser has its own billing entity attached, its media is invoiced separately to that entity. |
| **Account** | Else, if the advertiser's account (a child account under your organization) has a billing entity attached, the advertiser's media rolls up there. |
| **Organization** | Else your organization's entity — **mandatory**: every organization that transacts media must have one. This backstop can never be absent. |
"Most specific wins": an advertiser's own entity beats its account's, which
beats the organization default.
## Country is metadata, not a routing key
A billing entity's country drives its tax treatment, currency, and address
format — it is identity metadata on the entity, exactly like on a payout
entity. **Country never routes an invoice.** Resolution is purely structural
(advertiser → account → organization); it never looks at where media
delivered or where an advertiser operates.
If you need to bill different markets to different legal entities — for
example, invoicing South African spend to your South Africa entity in ZAR —
model it with a **market-scoped advertiser** (e.g. an "Acme Beverages South
Africa" advertiser) and attach that advertiser to the South Africa entity. This
matches how agencies already structure market P\&Ls, and keeps "who gets this
invoice" answerable from your account structure alone, without a separate
geo-routing concept to reason about.
## Entities
A media billing entity carries:
* **Entity name** — the legal entity's name
* **Country** — ISO 3166-1 alpha-2 (metadata: tax and address format)
* **Currency** — ISO 4217 (media invoiced to this entity is denominated here)
* **Billing email(s)** — invoicing contact
* **Address** — street, city, state/region, postal code
* **Tax ID** — optional (e.g. VAT number, EIN)
Every organization that transacts media always has exactly one **primary**
entity — the organization backstop. Your first entity automatically becomes
primary; promoting a different entity demotes the previous one in the same
step. You cannot demote the primary without promoting a replacement in its
place.
## Attachments
An attachment routes one advertiser or one account to a specific entity —
exactly one of the two per attachment. You can't create an attachment until
your organization has at least one entity (the mandatory backstop must exist
first).
## In the product
The **Media billing** tab of the
[Plan & Billing page](/v2/buyer/billing/plan-and-billing) is where this model
renders. It appears for organizations with buyer capability (a pure seller
has interchange fees and payouts, never media billing) and shows:
* **Billing entities** — your entities as cards: name, country, currency,
billing email, and an "Org default" tag on the primary. An entity missing
its tax ID is flagged. When you have no entities yet, the tab explains that
the organization default is required first — attaching comes after.
* **Routing** — one row per attachment (advertiser or account → entity),
plus a final "Everything else" row showing the organization default that
catches everything without a more specific attachment.
* **Who gets this invoice?** — an inline inspector: pick any advertiser or
account and see the three resolution steps (advertiser attachment, account
attachment, organization default) with the matching step highlighted, then
the resolved entity with its country and currency.
The tab writes through the same admin-gated API documented below — nothing
on it is possible in the UI but not via the API, or vice versa.
## For agents
`GET /api/v2/billing/media-entities`
`POST /api/v2/billing/media-entities` (admin)
`PUT /api/v2/billing/media-entities/{entityId}` (admin)
`DELETE /api/v2/billing/media-entities/{entityId}` (admin)
`GET /api/v2/billing/media-entities/attachments`
`POST /api/v2/billing/media-entities/attachments` (admin)
`DELETE /api/v2/billing/media-entities/attachments/{attachmentId}` (admin)
`GET /api/v2/billing/media-entities/resolve?advertiserId=` or `?childCustomerId=`
The resolve endpoint answers "who gets this invoice" for any advertiser or
account: it returns the resolved entity plus `resolvedVia`
(`advertiser` | `account` | `org`), or `resolvedVia: "none"` when your
organization has no entity at all yet. Admin-gated writes are enforced
server-side, so any future client shares the same rule as the REST API.
## Related
Where interchange fees and media billing both render
How invoicing and remittance work