Rafsark

Yep, totally right. Same at the previous company we worked for and built the billing logic. You start doing it in house because the first version is simple. It’s getting complicated when you keep adding paying features to a product. Often see product managers becoming experts in taxes and accounting :)

Yep you are right, indeed. We could have mentioned Reporting/Analytics for revenue, which is always a huge pain for companies!

Agreed! this triggers also complex behaviors because sales people want to handle this in their env (Salesforce, hubspot or whatever); You also have to build the logic to update subscriptions and pricing directly from it, in a two-way sync. Things getting crazier ;)

Job creation comes always because of hard-things to build; When getting easier, it cuts job!

Even if with blockchain and crypto you need to define a logic to bill your customer. This logic is pre-transactional and define how much you need to price the transaction.

Couldn't agree more! I do think the best way to do it is to log ingested events in a db, and decide which way you want to aggregate a billable feature at a defined billable period. This way lets you (i) keep track of everything, (ii) invoice complex behaviors and (iii) provide great granularity to your customers inside a final invoice.

Couldn't agree more on this. Even if finance, sales, marketing or other deps are involved, billing is an engineering thing! Back in 2016, while building the billing system for qonto.com (european fintech unicorn), we were surrounded by people willing to add complexity to a thing they don't understand. A team of 2 engineers building it ended up in a whole squad called "Pricing Cross Functional Team"... even the name of this team was complex :)

Ahah so sorry. Hope this is because of the substance, not about the form ;)

What are the top 3 things you learned that every company should be aware of? Could be interesting to have an experienced view on this :)

For sure; I do think an event based solution working as a source of truth for the billing is the right solution. However it still creates engineering difficulties (making sure you don't ingest the event twice for instance). The ledger-type architecture can definitely work. When we built the system for a fintech, it was actually an event-based architecture connected to a ledger (taking the money out of a wallet). I think the whole process would be: - Ingesting events for usage based feature - Store these events in a database and make sure you make the idempotency right - Aggregate the usage of these events based on most common aggregate functions - Price this usage inside plans or subscriptions - Assign a subscription to a customer - Trigger a webhook (used for invoice/payment) at the end or beginning of the billing period

I think it's easier for billing systems to have 1 subscription for 1 customer. The reason behind this is mainly because you can apply several prices to the same feature belonging to two different subscriptions. Stripe does not work on it because they might consider this as a edge case.

When you look at usage-based billing, even if a billed feature is linked to consumption, it needs to be related to a subscription given the fact that this feature can be priced differently for several plans. Every company has a singular pricing model in mind and it's hard to have an all-in-one model fitting all the needs. Even when we built internally the whole system for a fintech back in 2016, we had some edgecases creating conflict inside the company.

For simple subscription-based billing, it's somehow not this hard, you are right. It also depends on how much plans you provide to your customers, and you still need to scratch your head for upgrades and downgrades.

I truly believe in usage-based billing, so I do think pricing are getting more and more complex over time.

Taxes are a nightmare for everyone also (in Europe too...)

Yep, fortunately in Europe we can issue credit notes, making our job easier. I do think giving the possibility to send charges information to a webhook is a great way to start: this data can be plugged to any invoicing system (or any tax, payment providers) who are trying to solve those things. The hardest part for me, when working in that fintech, was to build the whole logic to trigger the invoice, not so much the invoice itself. But this company was a EU company, probably easier to work with invoices

Hi! We decided to aggregate all costs of a "billable period".

Imagine you bill your customers monthly (the billable period), all the charges (usage-based features + subscription) will appear as line items of a single invoice.

This enables you to gather all the fees of a period into a total invoice, but still be able to provide granularity to your customers (breakdown of all the fees to be paid).