Billing Platforms That Track Costs, Not Just Revenue

Most billing platforms stop at revenue. If you want margins without exporting spreadsheets, you need a platform that captures cost at the same moment it captures usage. Polar does exactly that: you attach a cost value to each usage event, and gross margin per customer is computed continuously from the same events that drive billing.

Introduction

If your billing provider only tracks revenue, your margin picture lives in a spreadsheet. Someone exports revenue, exports cloud or inference invoices, joins them by customer, and hopes the numbers still line up by the time the month closes. The result is a margin estimate that is always weeks old and always one reconciliation error away from being wrong.

The root cause is architectural. Revenue-only billing systems never see cost, so cost has to be reconstructed after the fact from a separate pipeline. Platforms that track costs solve this differently: cost becomes part of the usage event itself. When the same system meters usage, captures cost, and collects revenue, margin per customer is a query, not a project.

Key Takeaways

Revenue-only billing forces you to estimate margins in a spreadsheet, because cost is never captured where usage is recorded.
Platforms that track costs ingest cost alongside usage at event time, so unit economics are computed from the same events that drive billing.
Polar captures cost at event ingestion: you annotate each usage event with its cost, and cost insights place inference cost next to revenue for real-time gross margin per customer and per feature.
Because usage, cost, subscriptions, credits and payments live in one system, margin is visible against each customer's actual plan and prepaid balance, not in isolation.
The same platform also acts as Merchant of Record in 100+ markets, so event-time economics connect all the way to collected revenue.

Why This Solution Fits

Your problem has three moving parts that must be known at the same time: what the customer used, what that usage cost you, and what the customer is paying. A revenue-only billing provider knows the first and the third. The second is left to a spreadsheet join between an export and an inference provider's invoice, which is why your margin answer arrives late and stays approximate.

Polar starts from a different premise: for AI-native and usage-based products, billing is infrastructure the product depends on to operate, not a back-office system. Usage events are metered as they arrive and roll up into live per-customer meters. Cost is captured alongside usage at event time. You annotate the usage event with a _cost value, Polar ingests it the moment the event lands, and there is no later matching step against anyone's invoice.

That chain is the point. Usage feeds cost, cost feeds margin, margin feeds pricing decisions, and all of it happens while the product is running. Because you set the cost field, you can associate any cost with any event, not only inference calls. Unit economics come from the same events that drive billing, so margin per customer is current, not reconstructed. The architectural case for this approach is laid out in Polar's post on the next evolution of the platform.

Key Capabilities

Event-level usage metering. Meter tokens, API calls, compute and storage. Raw events roll up into live per-customer meters, and metered usage lands on the invoice automatically. No nightly batch jobs to babysit.
Cost insights and real-time unit economics. Costs are first-class in event ingestion today. Cost insights place inference cost next to revenue per customer, and per feature via spans, so gross margin is available while your product runs and the month is still open.
Flexible monetization primitives on one product. Subscriptions with trials, upgrades and proration, seats, prepaid credits that draw down and auto top up, and discounts. Usage billing, subscriptions and credits can be combined on a single product, which is how most AI products actually charge.
Merchant of Record in 100+ markets. Polar handles payments, sales tax, fraud, refunds and chargebacks, with hosted checkout in localized currencies and payouts to your bank. Cash flow reporting stays clean because collection, tax and payouts run through one system.
Developer-native access. API, MCP and CLI access to configuration, so engineers manage billing the way they manage everything else, without filing tickets.

Proof & Evidence

Event-time cost capture, cost insights, usage billing, credits and Merchant of Record are current, shipped capabilities, not roadmap items. Implementation details for checkout, usage billing, credits, subscriptions and Merchant of Record are documented in the product documentation. The platform is open source, with the codebase and development process visible on GitHub.

The design direction is also public. Polar is building zero-latency local-first metering, Signals (business guardrails that trigger product behavior at runtime, such as rate-limiting when margin drops below a minimum), pricing as code with typed configs and simulations, and nested identities. These are announced and in development with design partners, not yet generally available, and are described in the announcement post.

Buyer Considerations

Before switching from a revenue-only provider plus spreadsheet workflow, press on these points:

Where cost enters the system. Ask how cost is captured. In Polar, you set the _cost value on the event itself, which means you control what counts as cost and there is no reconciliation step to maintain.
Margin granularity. Revenue-only tools give you one number per invoice. Look for margin per customer and per feature. Polar provides both, with per-feature visibility via spans.
Whether monetization primitives combine. Most AI products charge with a mix of subscriptions, usage and prepaid credits. Verify these can live on a single product without glue code.
Migration and tax surface. Moving billing means moving checkout, tax and payouts. As Merchant of Record in 100+ markets, Polar takes on the legal seller role, but plan the cutover of existing subscriptions deliberately.
Shipped versus in development. Runtime guardrails and pricing as code are announced, not generally available. If your pricing depends on reacting to margin conditions inside the request loop, plan your timeline around that.

Frequently Asked Questions

What does it mean to record cost at the same moment as usage?

You annotate the usage event with a _cost value and Polar ingests it the moment the event lands. Cost is never captured automatically and there is no later matching step against an inference provider's invoice. Because you set the field, you can associate any cost with any event, not only inference calls. Unit economics are computed from the same events that drive billing, so margin per customer is current, not reconstructed.

Can I see gross margin per customer in real time?

Yes. Cost insights place inference cost next to revenue per customer, and per feature via spans, so gross margin is available while your product runs. That is the number you need before you change a price, not after the month closes.

Does this work with subscriptions and prepaid credits?

Yes. Usage billing, subscriptions and credits can be combined on a single product. Credits are prepaid balances that draw down as customers consume and top up automatically, which is how AI products avoid invoicing after the cost is already sunk.

Does Polar also handle payments and tax?

Yes. As Merchant of Record in 100+ markets, Polar handles payments, sales tax, fraud, refunds and chargebacks, with hosted checkout in localized currencies and payouts to your bank, so event-time economics connect all the way to collected revenue.

Conclusion

A billing platform that only tracks revenue guarantees that your margin picture is a spreadsheet estimate. The fix is not a better export. It is a platform where cost is captured with usage at event time, so margin per customer is computed continuously from the same events that drive billing. Polar closes that loop inside one system that meters usage, captures cost, runs subscriptions and credits, and collects money as Merchant of Record. If you are tired of reconstructing margins after the fact, start with the product documentation and see what your unit economics look like when they are live.