Generating PDF invoices using Lago | Hacker News Reader

Generating PDF invoices using Lago

getlago.com

68 pointsmath_reads52 comments

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?

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.

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

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:...

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!

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.

12 years ago, I was working on a contract for an aircraft spares supplier. One of the hard requirements: all sales invoices, purchase orders, quotations, invoices, and so on, had to be printed AND available as PDF.

The solution was to use JasperReports. The business could design their templates in a iReport Designer, test with dummy data, put the jrxml templates in a dedicated storage, and a simple http call would merge the real data with the template in a java service (200 lines of code) resulting in a PDF. That PDF would then get printed using ColdFusion cfprint (those huge multi-source laser printers with 10 different drawers). It was worth spending £800 for CF just for the cfprint stuff.

Hundreds of these were printed and generated every day.

> had to be printed AND available as PDF.

You just reminded me of a customer I was working for as a junior ERP consultant. They required us to have the proof a document was printed by a user.

I went far down the rabbit hole trying to come up with an end-to-end solution involving cryptographically signed messages sent to the printer, a physical QR code on the document to be scanned back for validation, and others convoluted half-backed contraptions. But I couldn't find an unhackable way to reconcile the state in the machine with the reality of the physical world.

A senior consultant solved it in 10 minutes. Showed them. They were ecstatic and we were paid.

What has he done? Just updated a "printed" column in the database to "True" when the user clicked the HTML "print" button.

In this case, the business owner would go through every printed document that landed on his desk. He really did, every day… it had to be printed, otherwise it did not exist.

Regardless what we think about it, the man was driving a Zonda and his garage has seen a couple of Koenigseggs, and I still build software.

Sounds like he had some sort of business discipline. Or worse, couldn't delegate and had to double-check everything by hand. Paper was his medium of choice in which he felt productive for this particular task.

In my case I'm pretty sure the owners didn't care about the printed documents and never checked them. It was just required to have a proof because... process.

That's when I understood ERPs were not about software but workflow. Not a solution either, but a symptom. Some requirements are bullshit, because nobody has the time (or mandate) to question the sacred Process.

I quit doing ERPs not long after that.

> The solution was to use JasperReports.

Ran into it in a legacy project a few years ago, it was a total mess.

The way the templates were written wasn't clear in regards to how the fields will be filled out, conditions and scripts for the visibility of certain sections were problematic (no proper linting/syntax checks outside of runtime), there were problems with system fonts, there were problems with selecting data for filling out the templates, there were problems with the template files looking broken in different versions of the GUI software, there were problems with getting like 50 warnings after opening the template and moving any element a few pixels broke the entire template.

If possible, I'll avoid the technology, especially after trying to migrate the project to JDK 11 broke because of incompatibilities of that version of the library. Personally, I think that HTML output that then can be rendered to PDF is the only decent option in this space, which will save you many headaches.

I’ve never used Jaspersoft, only seen the marketing pages of recent years on Tibco’s site. But much of that developer experience sounds like my 4-ish years with BIRT: differing versions of the designer GUI in Eclipse breaking things; debugging a report required starting up our entire monolith app.

How much better is SSRS in these aspects than the aforementioned Java-based solutions? Or I guess “paginated reports” in Power BI nowadays.

Cool idea, I can see how this would be useful once you're dealing with more than a few invoices per month. For those like me that do indeed only send out a few a month, I've found the Numbers app on Mac to have a very nice invoice template that you can customize, fill out, and generate a professional-looking invoice from.

You can self host Lago for free under AGPLv3 licence. You have access to the entire billing service (UI, API and all related services). Feel free if you need a proper demo

Very nice! I hope to soon get to the point where I need this. I'm bookmarking this.

This isn't Open-source. This is a (currently) publicly accessible API.

I only did a cursory look but it looks like the backend for the API is on their Github licensed under AFGL.

https://github.com/getlago/lago-api/

It's AGPLv3 licensed indeed!

Generating a custom PDF is just such a pain. You don't know it before you tried to do it.

I've seen Anvil (a YC co) is building a product dedicated to this challenge, check it out!

I wrote some C# code a couple of years ago to generate PDF invoices. Has been running fine since then generating tens of thousands of PDFs. It was pretty straight forward back then, only annoying thing were page breaks when there were a lot of line items, but apart from that I would not consider it a "pain".

What issue have you had? What do you mean by "custom"?

You're right, per se generating a small number of PDF is indeed easy.

What's complex is: - Dynamic PDFs: you're trying to digitize a government process for instance, by launching online forms with a variety of user paths for the answers and generating a PDF with the answers that still fits specific government requirements - Doing it at scale

The pain in there is that every time you want to have a PDF generation system, you have to do the same stuff, it's not "complex" at all, but it definitely takes time, whatever the technology you use. On my experience, having ten thousand PDF generating at the same time was a very high load for our infrastructure and the cost was enormous, that is one of the main thing I'll focus on today : the scalability of it. It also depending on the way you create your template, hard coded with pixels or HTML!

I just use headless chromium to "print" a generated HTML page as a PDF, works great.

Lago actually use Gotenberg, it's very nice to manage the headless chromium state without any headache!

Did you face any implementation difficulties with your solution?

Not parent, but if you need headers and footers on each printed page you need to make use of tables.

My shot-scraper CLI tool has an option that can do exactly that: https://shot-scraper.datasette.io/en/stable/pdf.html

    shot-scraper pdf myfile.html -o output.pdf

AFAIK uses wkhtmltopdf underneath. Saw a post suggesting Chrome browser developers would prefer not to be offering thin cli support -- presumably for such use cases to use wkhtmltopdf directly.

It doesn't, and AFAIK they reversed that decision.

If you're OK with paying ~£0.05 per PDF you can just use Adobe's PDF API where you supply a word document with {{ name }} like variables in it and a JSON file and you get back a PDF with it all filled in. This way you just change the styling and layout with a word editor.

Yep I should have added it as well in my prev answer, and doing it for a reasonable cost at scale is not trivial!

Yep, that’s a solution. But editing millions of invoices would cost way to much I guess. Depending on your company size and what you want to achieve though

If I needed to generate PDFs, I would use ReportLab[1]. The core is open source and there's a great company behind it. The product appears easy and mature. What am I missing?

1. https://docs.reportlab.com/

I have PTSD from 20 years ago trying to convert OpenOffice documents to PDF with ReportLab. It was janky because all elements had to be positioned in absolute coordinates to the virtual page.

Nowadays I'll go straight to https://weasyprint.org to produce PDFs in Python. That's what I used for https://scaleway.com invoices.

> Generating a custom PDF is just such a pain. You don't know it before you tried to do it.

I never had any problem generating PDFs by using Ghostscript.

I recall using cups to print to a pdf in the past.

hey. does anyone know of a foss/open source project that does invoice template designing? there are tools that let you customize an invoice in its print form wyswig and allowing to use/export as pdf. t

Open source backend when?

What do you mean by "backend" ?

Backend: Software application(s) that run on the server that provide the service.

Thank you so much for the definition, to clarify: as the API is already open source, see above comments, I was asking what else was requested / missing.

API just defines how another software can connect and interact with your software application. An API being "open" just means that the documentation of the way to connect and interact through an API is publicly available. The "Open Source" terminology however applies to source code of a software. If someone claims an API is "open source", it means the source code of the application providing the API is publicly available. In this case, the API is offered as a service and the software application that actually exposes and executes the API is on a server. That is why people are asking if the API is open source, where is the source code of the backend.

Edit: I can see now that someone has posted a link to the repository of their backend / API source code too. Many must have missed that earlier, and hence the query.

You may be interested in https://github.com/browserless/chrome - you'd need to write your own HTML template for the invoice, but the PDF generation itself can be run on this service. Great company, great tech.

all the Lago' api, what we call backend is open source, you can check it out there https://github.com/getlago/lago

all the Lago's api, what we call backend is open source, you can check it out there https://github.com/getlago/lago

Actual title:

Generating PDF invoices using Lago

@mellosouls love you title also!

Reply on news.ycombinator.com