Billing shouldn’t just be PDF generation

I hate paying for tools that make me do all the work. This is one of my gripes with conventional billing vendors: Sure, it’s easy enough to bill for seat-based subscriptions and a bit of usage. The logic is simple: You tell your billing system how many seats a customer has and send over usage once a day.

‍

But as companies grow (especially infrastructure and API-based companies), billing gets more complex: Let’s say you run a cloud storage service with a monthly fee per user and a usage-based charge for GBs per second. Now a customer’s finance department wants more specific invoices that list exactly what they’re paying for. 

‍

Now you have to build: 

‍

• A script/CRON job that fetches usage data at your pre-defined intervals. 
• Logic that calculates GB per second with timestamps, differences and data consumed. 
• A way to aggregate these results and send them to your billing system so they actually show up on the invoices. 

‍

This means you’re diverting engineers from building product and create complexity that makes this an even bigger headache. Because what happens if you start an EU-based cloud with different prices and a customer uses both clouds for different user segments? Or if sales tells an enterprise prospect they get a 20% discount on the first 10,000 GB each month? 

‍

If you want to know how this ends, it’ll probably look something like this: 

‍

In the end, you’re building most of your own metering and your billing vendor becomes a glorified PDF generator. And then you still have a system where you don’t have a real-time overview of your revenue and your customers don’t have one for their spend.

‍

Sucks, doesn’t it? If you pay for a billing system, you should be able to send it raw data and know your billing system has taken care of it. This means Lago, not you, calculates, aggregates, deduplicates and ultimately turns it into an invoice. 

‍

‍

This is why we recently shipped custom SQL expressions in Lago, which is a step towards exactly this. Here’s how it works. 

Custom SQL expressions in Lago

Before the feature itself, let’s talk about billable metrics. A billable metric is anything you want to charge for. For Mistral AI that’s a million tokens, for cloud providers that might be gigabytes in data storage, but it can be anything you can measure events for. If you want, you can bill a customer for every time they type the letter “b”. 

‍

Billable metrics used to be a single field like a million tokens. Now you can use them as more complex logic. 

‍

Let’s say you’re a DevTool company and you want to charge customers per user per repo. If you simply billed for users, it wouldn’t capture your pricing model. If you billed for repos only, it wouldn’t work either.

‍

So you can now concatenate 2 properties on the event: user_id and app_id. You don’t want to pre-aggreate the calculation on your side, so you ship this: 

‍

Endpoint: /events

{
 "event": {
   "transaction_id": "{{$randomUUID}}",
   "external_subscription_id": "sub_expression_001",
   "code": "unique_seats",
   "properties": {
       "user_id": "user_01",
       "repo_id": "repo_02"
   }
 }
}

‍

You can now send the row event, and Lago applies the following SQL syntax to this metric to get the Unique Seat per Repo: CONCAT(event.properties.user_id', '-' , event.properties.repo_id)

The usage is entirely calculated by Lago. In that case, the unique seat per repo will be user_01-repo_02

‍

(Read our docs to find out more details about how to do this)

‍

Want to get started? 

You can start ingesting these events now, either by building custom expressions and advanced computation directly on Lago or by piping them in from your ingestion sources—AWS, GCP, MongoDB, etc. 

‍

You can see the full list here.

‍