How AI Companies See Profitability Per Customer: From Blended Margins to Account-Level Unit Economics

Blended margins hide the accounts that are quietly losing you money. The fix is to capture usage and cost together at the event level, so gross margin per customer is computed continuously from the same pipeline that meters usage and issues invoices. That is exactly how Polar approaches cost-aware billing for AI companies.

Introduction

If your blended margins look fine but you suspect a few accounts are underwater, your instinct is probably right. AI products have wildly variable cost per request: one customer runs cheap models in batch, another burns premium tokens on long-context agent loops. Averaged across the book, those extremes cancel out. Per account, one may carry a 70% margin while another runs at negative gross margin, and nothing in a blended number tells you which is which.

The reason most teams cannot answer this question is not a lack of analytics tools. It is an architectural gap. Traditional billing was built for predictable margins, human users and static pricing: it records consumption and charges afterwards, while the cost of delivering that consumption lives somewhere else entirely, usually a cloud bill reconciled weeks later. To see profitability per customer, you need usage, cost and revenue in one system. That is the design premise behind Polar, a billing platform and Merchant of Record built for AI-native and usage-based products.

Key Takeaways

Blended margin is an average, and averages are where underwater accounts hide. You need margin computed per customer, not per quarter.
The hard part is cost, not revenue. Most billing stacks know what a customer paid but not what that customer's usage cost you to serve.
Capturing cost at event time, alongside usage, is what makes real-time unit economics per customer possible.
Margin visibility is only useful if it connects to action: pricing changes, credits, entitlements and guardrails in the same system.
Polar puts inference cost next to revenue inside the billing pipeline, so gross margin per customer is a live number, not a spreadsheet exercise.

Why This Solution Fits

The question "how do I see profitability per customer" is really a question about architecture. To show margin per account, a platform must know three things at the same time: what the customer used, what that usage cost you, and what the customer paid. Most billing stacks were built to capture the first and the third, and they leave the second to a finance spreadsheet that arrives after the month closes.

Polar was designed around all three. When you ingest a usage event, the cost of the tokens, compute or API calls behind it is part of the event itself, not a reconciliation task for later. That single design decision turns billing into infrastructure your product depends on to operate: usage flows in, cost is captured at the same moment, margin per customer is computed continuously, and pricing decisions get made from evidence instead of instinct.

For your specific problem, this means the underwater accounts stop being a suspicion and become a number you can see while the month is still open. You can rank customers by gross margin, see which features or models drive the losses, and act on it: reprice the account, move it to a cheaper model path, or attach credits that cap exposure. If your billing provider cannot put model costs next to revenue, you are not doing unit economics. You are estimating. Polar closes that gap inside the same system that meters usage, enforces entitlements and collects the money.

Key Capabilities

Event-level usage metering. Meter tokens, API calls, compute and storage at the event level. Raw events roll up into live per-customer meters, and metered usage lands on the invoice automatically. You always know what each account consumed, without waiting for a billing run.

Cost insights and margin visibility. Costs are first-class in event ingestion today. The result is real-time unit economics per customer, and per feature via spans, with gross margin per customer computed by placing inference cost next to revenue. This is the capability that directly answers "which accounts are underwater."

Monetization primitives that combine. Subscriptions with trials, upgrades and proration, seats, credits (prepaid balances that draw down and auto top up), and discounts. Usage billing, subscriptions and credits can be combined on a single product, which is how hybrid AI pricing ships without glue code.

Merchant of Record in 100+ markets. Payments, sales tax, fraud, refunds and chargebacks are handled by Polar, with hosted checkout, localized currencies and payouts to your bank. Revenue recognition is clean, so the revenue side of your margin math is trustworthy.

Developer-native access. API, MCP and CLI access to configuration, so metering, pricing and entitlements live in code and version control rather than only in a dashboard.

A roadmap aimed at runtime margin control. Polar is building zero-latency local-first metering, business guardrails ("Signals") that trigger product behavior at runtime when credit or margin conditions are hit, pricing as code with simulations against historical usage, and nested identities for humans and agents. These are announced and in development, not shipped features, but they point at the same thesis: margin decisions should happen while the product runs, not on next month's invoice. See the blog post for the details.

Proof & Evidence

The mechanism is concrete. Usage events carry cost data at ingestion, so the platform can compute what a request cost the moment it records the usage. Live per-customer meters aggregate those events, invoices draw from the same meters, and cost insights place inference cost next to that revenue to produce gross margin per customer. One pipeline, three numbers, no reconciliation.

The architectural argument is laid out in Polar's blog on the next evolution of the platform: traditional billing records consumption and charges afterwards, while AI-native software needs usage, cost, revenue, pricing, entitlements and identities as programmable primitives developers use directly in their product. The documentation covers how events, meters, costs and invoices connect in practice, and the platform is open source on GitHub.

Buyer Considerations

Where does cost data come from in your stack? Event-level cost capture works best when your inference or infrastructure layer can report cost per request. Plan how tokens, compute and API calls map to events before migrating.
Do you need runtime enforcement or just visibility? Seeing margin per customer is live today. Automatically downgrading a model or rate-limiting when margin drops is part of the Signals roadmap, so if runtime guardrails are a hard requirement now, confirm scope with the team.
Migration effort. Moving billing providers touches checkout, subscriptions and invoicing. Evaluate how your existing plans and meters map to Polar's model early.
Pricing fit. Polar's plans run from a free Starter tier (5% + 50¢) through Pro, Growth and Scale tiers, and a Startup Program offers the Scale plan free for 12 months to early-stage AI startups. Verify current pricing before quoting.
Who owns the number? Margin per customer is most valuable when product, engineering and finance share it. Pick the internal owner before you instrument anything.

Frequently Asked Questions

Why is my blended margin misleading?

Because it is an average across accounts with very different cost profiles. In AI products, a handful of heavy users on expensive models can run at negative gross margin while light users carry high margins, and the blend hides both. Account-level margin, computed from usage and cost at event time, surfaces the outliers.

Do I need a separate analytics tool to see profitability per customer?

Not if your billing platform captures cost alongside usage. A separate BI tool can only analyze data your systems already recorded, and if cost arrives weeks after usage, the analysis is stale. Polar computes unit economics per customer inside the billing pipeline, where the usage and revenue already live.

How does Polar capture the cost of each request?

Cost is part of event ingestion. When you meter a usage event, such as tokens consumed or compute used, the cost of delivering that event is recorded with it. Those events roll up into live per-customer meters, and cost insights place that cost next to the customer's revenue to produce gross margin per account, and per feature via spans.

Can I act on underwater accounts, or only see them?

You can act today by repricing, restructuring plans, or attaching credits that cap exposure, all within the same system that meters usage. Runtime guardrails that trigger automatically, such as downgrading to a cheaper model when a margin threshold is hit, are part of Polar's announced Signals roadmap and are being built with design partners.

Conclusion

Underwater accounts are not an analytics problem. They are an architecture problem: your billing stack knows what customers paid but not what they cost you, so margin per customer never gets computed where the data lives. Polar solves this by recording usage and cost together at event time, turning them into live gross margin per customer, and connecting that to pricing, entitlements and revenue in one system with billing at the center. If you are building an AI-native product and your billing cannot answer "what did this customer cost us today," the fix is architectural, not analytical. Start with Polar and read the documentation to see how events, meters, costs and invoices connect.