Use Case: Marketplaces

Give every seller a compliant invoicing layer, without mixing tenants

The winning marketplace model is usually one seller per entity. Your platform keeps the control plane, while each seller gets their own invoicing identity, branding, and compliance setup. The expensive mistake is weakening seller isolation just to make the first integration feel faster.

Who This Is For
Each seller should issue invoices under their own business identity
You need unified marketplace control without shared seller data
You want seller-specific numbering, branding, and compliance setup
Not A Fit
The marketplace operator is always the sole invoice issuer
Sellers are not separate invoicing parties
You do not need seller-level isolation
Common Underestimation

Teams underestimate seller isolation and correction flows

A shared seller bucket looks simpler at first. It becomes expensive when you need seller-specific numbering, branding, disputes, credit notes, exports, and audit trails.

Recommended Path

Use your backend as the seller control plane

Manage seller onboarding and transaction routing with an account key in your platform backend. Issue invoices in the seller entity context and add seller access only if sellers need to manage documents directly. Keep cross-seller reporting in your platform layer, not by compromising isolation.

Platform backend

Creates seller entities and routes invoice creation.

Seller access

Optional later, via entity keys or user-based roles.

Entity Model

One seller = one entity

Each seller gets their own numbering, branding, compliance rules, and history. Your marketplace keeps cross-seller reporting and orchestration at the platform layer.

Seller isolation Strict
Branding Per seller
Reporting Platform aggregate
First Sandbox Milestone

Prove one seller end to end

Before scaling to hundreds of sellers, validate one seller entity in sandbox and make sure transaction mapping, branding, and reporting identifiers are clean.

01

Create an entity for one sandbox seller

02

Map one transaction to that seller and issue an invoice in the seller entity

03

Verify seller branding, numbering, and metadata links

04

Decide whether sellers need direct dashboard or team access

Operational Gotchas
Do not issue seller invoices in a shared entity unless the operator is the legal issuer
Store seller IDs and marketplace order IDs in metadata
Aggregation and reporting should happen in your platform layer, not by weakening seller isolation
Compliance Notes

The seller entity country drives most compliance behavior, but buyer location can still change tax treatment for cross-border sales.

Use sandbox to verify per-seller branding, numbering, and country logic before you expose seller-facing flows in production.

Start with one workflow, not a whole rewrite

Free sandbox with no time limit. Prove one entity and one invoice flow before deciding how much UI, compliance, and rollout surface you want to own.