201–210 of 372 posts
Earlier quoted context omitted.
I fear if they did not they'd be accused of something else. I agree with your observation but I don't think there is an obvious solution as you imply.
They can disclose their interests without the repetitive intro. But for the above comment, just asking a question, even this is unnecessary.
Thanks for the constructive feedback!
Nit: there's a lot of noise being made in comments about it being an open source product, but I haven't found the source (maybe I have to speak to an expert to get it?). github.com/getlago has the docs, which is nice (and gives a lot more info than is available on the website about how the product works), but not quite the same. Also note: > Our open-core version is forever free. We will introduce paying add-ons in t…
Usage based billing is not only hard to implement but hard to consume. No one really knows what they are spending and how much particular customers or products cost. I did a writeup a week ago on CDNs and ended up spending several hours in spreadsheets. I had felt this pain vaguely before but actually seeing it everyday at my current job makes me realize there are engineers suffering on both sides of software billing…
Speaking of usage-based billing, if I intend to charge users a usage-based bill at the end of the month, as far as I have looked Stripe is the only provider that supports this (they call it "metered billing"), is there really no alternative?
Just wait until you meet billing's angry roommate: invoicing. In the US, an invoice is just a weird PDF that you might glance at before sending off to your accounts payable team. But in other countries, especially those that use VAT style taxing systems, an invoice can be a legal document that expresses costs and taxes in a legally prescribed way for accounting purposes. Many countries have prescriptive rules over ho…
And even worse - your biggest customers won't even smell your invoice unless you enter it line by line into some ancient SAP system developed 20 years ago, where everything cloud related is classified as telephony except storage space which must be classified as filing cabinets (movable) or your invoice will be (very slowly) rejected. And if it is rejected you have to enter it all again by hand; editing isn't a featu…
Problem is it still requires an API to integrate. Stripe has all these capabilities but API integrations are needed to use them. If you are looking to build a micro SaaS without needing to deal with billing API integrations check out our software: https://saasbox.net . Built for completely eliminating any billing related SW development. It doesn't handle all the corner cases mentioned in the article, but some of them…
Earlier quoted context omitted.
>. With business customers, leaning back in the legal framework encouraging tax fraud will not fly. Yes which is why in nations like Portugal, where any business invoice may be subject to accountability to government, there totally isn't a massive informal (read: tax-evading) economy to deal with the fact that the government makes it literally impossible (at least in above words) to accept an invoice legal in the jur…
It's not literally impossible - the simple solution to standard invoice being unacceptable is to issue a different invoice that matches the requirements, and almost every vendor is happy to do so in order to make the sale. Also, the informal tax-evading economy relies on personal contacts and 'mutual understanding' - it's not easily accessible to a foreign vendor, and when foreign vendors do want to access that econo…
Informal tax-evading (when the seller isn't evading, just the buyer) doesn't require personal contacts. This is just naïve thoughtless statement. It happens all the time. Example: business owner goes to Panama where they know no one. Buys a pallet of llama wool, seller gives a non-conforming receipt. Buyer goes back to France, imports the pallet as "cotton" and creates a fake invoice showing the Panamanian sold cotton. Seller then sells llama wool on the streets for cash, marking in the books that they sold "cotton" for significantly less. They then use the on-the-books "cotton" proceeds to buy a shit-wagon car or something, and fix it using the unrecorded cash on the side. They sell the now nice shit-wagon and record the proceeds as profit. Now all the money for the llama wool is accounted for.
Cross country tax-evading is only assured in this case to require personal contacts when the tax evading happens on _both_ sides. When it only happens on the EU side, there's no need for personal contacts on the US side.
The reason billing systems are hard is because they tend to just accumulate features/behaviours/requirements. Forever. Although billing is not my specialty I have had to involve myself in it as product owner and business unit manager. Try and imagine the amount of logic, complexity, rules, and exceptions involved in a system that has accumulated perhaps 30-40 years of customer sign-ups. Umpteen contracts, umpteen ite…
Earlier quoted context omitted.
Not the OP, but anybody who has built a deep integration with any billing provider (inclusive of Stripe) knows there are some bodies buried, although you typically don't discover them until you're late in the game. 90% of your use cases are covered, and with excellent UX and docs to boot. But that sweet 10%! --- For a concrete example, Stripe has a very nice "subscription" abstraction that makes it easier to operate…
> There's another, similar, story around creating draft invoices to give people quotes before checking out. The dashboard API has a function to modify the line items of a draft invoice, but it's not a public-facing API and there's no short-term intention to make it public-facing, so one has to build an ugly workaround. There is a similar "not a public-facing API" limitation with configuring multiple invoice email add…
But it does not make sense for PLG companies, who start with self-serve and layer sales afterwards: the investment is not worth it, and it creates 2 different systems: self-serve and sales-driven billings, not great for the user experience (and for the internal processes!)
Why XXXXXXX are a nightmare for engineers: PEOPLE On a more serious note though billing can be hugely complicated and I am really glad I do not have to deal with it
Always has been. Marketing and sales create complexity on the front end, devising all kinds of products, plans, discount schemes and related complexity; jurisdiction, taxes, and accounting rules add complexity on the backend. In the middle, measuring what you're billing for is the hook around which all that complexity chaotically orbits. Decades ago - the computer involved was an honest to goodness System 360 (which…