Hey @tablespoon, I'm one of the cofounders of Lago here.
Products like SAP do seem complex because of (i) the complexity of the billing problem and all the edge cases, (ii) they were not built with an API-first or engineer-first mindset
We're only at the beginning of the journey, but that's one of the reasons why we thought of open-sourcing our billing API, so that the work could be forked and tweaked to address edge cases if needed (no need to wait for SAP to update the product: and they will never prioritize small edge cases).
Also, it seemed to be no middle ground between 'Stripe Billing' (it's great for B2C Subscriptions) and billing systems that could address the millions of nuances of pricing between 'subscription' and 'usage-based' (most companies are a mix of both).
In the SAP R/3 family of products, there is also a component Factory Calendar (IMG -> SAP NetWeaver -> General Settings -> Maintain Calendar, transaction /SCAL) - a component that knows about all the various calendar systems incl. public holidays of the world and the dreaded leap years. If I remember correctly, it's customizable for each customer premise with respect to whether each day of the year is salaried or not.
This is a component classified as "basis technology" relied upon by many modules for billing (e.g. should a daily salaray be calculated in a country for a particular person? Should an invoice be considered "overdue" yet, based on the number of business days passed since issue? etc.).
I am the last one to defend SAP, but they do have an API first approach since some time, check this out: https://api.sap.com/products/SAPS4HANACloud/apis/all Also edge cases are taken care of, sometimes before you even small updates, via notes, mostly tax regulation changes. So yeah, for these things SAP is really made for. If you have a SAP account, you can check out, just to see how many changes are coming in: https://launchpad.support.sap.com/#/solutions/notesv2/?q=pol...
Products like SAP do seem complex because of (i) the complexity of the billing problem and all the edge cases, (ii) they were not built with an API-first or engineer-first mindset
We're only at the beginning of the journey, but that's one of the reasons why we thought of open-sourcing our billing API, so that the work could be forked and tweaked to address edge cases if needed (no need to wait for SAP to update the product: and they will never prioritize small edge cases). Also, it seemed to be no middle ground between 'Stripe Billing' (it's great for B2C Subscriptions) and billing systems that could address the millions of nuances of pricing between 'subscription' and 'usage-based' (most companies are a mix of both).