Media billing entities

Media billing is one of two money streams every organization has with Scope3 (the other is interchange fees — 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 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: “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 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

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