Comment by longrod | Hacker News Reader

Comment by longrod | Hacker News Reader

Parent Full thread

Not sure this actually solves a real problem. A lot of the questions/problems mentioned in the article are already things being addressed by any service worth using.

At the end of the day, you just need to generate a PDF from a template. The template is a solved problem. Invoices generally do not have that huge amount of variability in terms of layout.

I have been using microinvoice (https://github.com/baptistejamin/node-microinvoice) for the past couple of months and it's been a breeze. It uses PDFKit underneathe and has been working really well. I don't think PDF generation is a task that should require using Chromium. There's pandoc & other libraries that can easily do this at a much lower cost to both resources and finance.

The blog posts sounds like its solving a problem that doesn't exist. Generating invoices _at scale_? Is scalibility really a problem here? Generating a PDF takes a couple of milliseconds. Rent a $5 VPS and it can generate all sorts of PDFs for you without an issue for a long time before you'd start worrying about scalability. Heck this sort of thing doesn't even need to be a dedicated service.

Not to downplay anyone's hard work but Lago just doesn't sound like it's solving a real problem.

Lago founder here. FWIW we love what Baptiste did with Microinvoice!

I can only speak for what we've experienced first hand, in our prev. company (a $5B B2B fintech) we spent a lot of time around billing x invoicing in pdf :

- When billing is complex (lots of fees, different billing cycles, usage based consumption) - And you need to have a clear "invoice presentation" to avoid triggering questions (that is maintained while you iterate on pricing, launch new products or countries) the "template isn't really a solved problem", and our eng. team did rebuild the system in-house. We would have avoided it if it could have been possible and looked at every possible option, in-depth.

We've seen similar needs for marketplaces or vertical saas as well.

However thanks for the feedback, we could have done a better job at explaining why it can be a pain in specific use cases! And I was the 1st person to say, when I first discover the painpoint "there must be an existing solution for that, please don't build anything in-house".

> When billing is complex (lots of fees, different billing cycles, usage based consumption)

So does Lago have a template for all these use cases? What happens when a new unique case comes up? Is Lago flexible enough to handle all the cases? Current and future ones? How is that different than having a flexible template? What actually is the problem with that?

We make the whole fee calculation easy to do. If you have a paying feature, the charge related to it can be implemented in few minutes. We handle automatically the upgrades, downgrades, invoices, subscription dates and boundaries, and a lot of prebuilt charge model (graduated pricing, percentage pricing, package pricing…). We adapt to any pricing use case easily!

Invoices contain VAT and even more complex taxes and charges. How much of your calculations is tied to specific cases like a USA company billing another USA company? What's your story for international customers and/or international operations?

Subscription plans? Sure, you solve it with a single static template. The problem is reduced to producing PDFs (at scale).

But intricate pricing is unavoidable in some industries. Often to materialize physical or logistical constraints. Take cloud computing. There is elasticity, but some order of magnitudes are only reachable if you pay the price. Or you might get volume discounts. All of this requires segmented pricing.

How would you lay out an n-dimensions matrix on a 2D piece of paper? This is data design all over again.

With an invoice targeting the right audience, you can let your customer figure these complex schemes by themselves (and have them not feel cheated). It will make your support team happy to not have to answer the "where my money goes?" question ad nauseam.

And at the end we can't just send a JSON dump to the bookkeepers. The law still requires that document we call an invoice. So yes, I think invoice UX is a thing and is here to stay.

Is a PDF invoice typically expected to be generated every time you’re billed, or only when someone clicks “View PDF Invoice”?

It seems like the % of customers that care to have PDF over an HTML page would greatly affect the need for scalability.

What is this percentage, I don’t know. I wouldn’t have guessed high.

Anecdotally even when I’ve preferred a PDF invoice, it’s been on a case by case basis.

In France and in most countries in EU, it's mandatory to have a PDF that follows very pecific guidelines. Can't say for sure for every country though!

The information required on a EU invoice is detailed by Article 226, Section 4 (Content of invoices) of Council Directive 2006/112/EC on the common system of VAT: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:...

The PDF is triggered when it’s requested from the UI or from the API. The job is asynchrone, so it’s returned when it’s ready (generally in milliseconds). This prevents performance issues

Actually, this is only a feature Lago is providing. We have a full billing API to create usage based billing, subscription based billing and hybrid pricing. If you need to charge and invoice your clients, you don’t want to build this yourself. The invoice is generated automatically and can be downloaded from the UI or the API. Give it a closer look, happy to show you more!

Reply on news.ycombinator.com