Who this is: the provider in the middle
There is a fast-growing class of businesses that sit between an upstream cost and downstream customers: agencies running AI pipelines for brands, dev shops operating the APIs they built for clients, managed-service providers hosting one deployment per tenant, resellers wrapping a metered upstream in their own pricing. Their billing question is structurally different from a normal SaaS: not "what did my customers use of my product" but "what did each of my clients consume of the thing I pay for, and at what margin am I passing it on".
That question has two halves, and both need the same foundation: usage recorded per client, from day one, in a structure where the client is a first-class account rather than a label.
Why a tag is not a tenant
The tempting shortcut is one metering account with a client-name dimension on every event. It works until the first time it has to do anything account-like:
- Isolation. A client asks to see their usage. With tags you build a filtered view and pray the filter is everywhere; with child accounts, their account simply contains only their data.
- Entitlements. Clients on different plans, allowances, or prices need per-client subscriptions. Tags have no place to hang an entitlement; accounts do.
- Lifecycle. Clients churn. Offboarding a child account is closing an account: its history stays auditable and frozen. Offboarding a tag is a WHERE clause you will maintain forever.
- Trust boundaries. Sooner or later a client wants their own API key to send usage directly, or their own dashboard login. A tag cannot authenticate; a child account can.
UsageBox models this natively: an account of type service provider can create and manage child accounts, each child carries its own meters, subscriptions, and rollups, and the provider's view is scoped to exactly its own children - a service provider can list and inspect the accounts under it and nothing else.
The metering pattern, end to end
- One child account per client. Created when the client signs, not when billing questions first arise. Retro-attributing months of mixed usage to clients is archaeology; day-one attribution is free.
- Meters that mirror your costs and your prices. If you pay upstream per token and bill clients per task, meter both (a tokens meter and a tasks meter per child). Margin per client is then a subtraction between two rollups, not a spreadsheet. For meter shape decisions see designing billing meters.
- Events attributed at the moment of use. Your orchestration layer knows which client a job belongs to when it runs the job; that is when the usage event fires, into that client's account. Attribution added later is guesswork, the same lesson as per-customer, per-model cost dimensions.
- Monthly rollups per child as the invoice source. Each client's month is a rollup you can query, quote, and export. Aggregate across children for your own P&L view; drill into one child for their invoice and their disputes.
The margin view nobody builds until it is negative
Reselling usage means margin is a per-client property, not a company-wide constant. One client's workload profile (long prompts, heavy retries, expensive models) can quietly run at a loss inside a healthy-looking aggregate. With per-child metering of both cost-shaped and price-shaped meters, the loss-making client is visible in a month-one report. Without it, they are visible in your annual accounts. If your resale involves AI workloads, the cost side moves constantly - pricing drift is its own problem, covered in AI billing drift detection - which makes the standing per-client margin view more valuable, not less.
Growing into it
Most providers start with two or three clients and the shortcut model, and the migration to a real hierarchy gets more expensive every month. The practical advice is unromantic: adopt the parent-child structure while it feels like overkill. It is a few API calls to create child accounts and point each client's events at the right one. The payoff arrives on a schedule you do not control - the day a client asks for their numbers, disputes an invoice, or leaves.
The honest take
Multi-client usage billing is not a harder version of single-tenant billing; it is the same metering discipline plus one structural decision made early. Model clients as child accounts under your provider account, meter costs and prices per child, and invoice from rollups. UsageBox ships the account hierarchy, the per-child meters and subscriptions, and the scoped visibility, so the structural decision is a signup and a loop, not a build.