Storing Generated PDFs and Designing Reissue

Introduction

Once you can generate documents automatically, it's tempting to think "making it is the finish line." But in practice, what comes after you make it is the longer stretch.

"Could you resend last month's invoice?" "I'd like a copy of that delivery note." Requests like these come up all the time. Rebuilding from the source data each time leaves a nagging doubt: will it really come out identical to before?

This article covers how we store generated document PDFs and make it possible to reissue the exact same one anytime. The tool we used is an object storage service called Vercel Blob.

Why We Don't Treat It as "Done Once Made"

Documents get requested again and again

Invoices and delivery notes aren't documents you send once and forget. Your customer's accounting, your own audits, handling inquiries — past documents become necessary again in all sorts of situations.

When that happens, it's a problem if the document isn't stored anywhere. "I'm sure I made it, but I can't find the file" is a story that plays out constantly on the local PCs of template-based workflows. Being able to produce a document reliably when it's asked for matters just as much as being able to make it.

Rebuilding doesn't guarantee "the same thing"

You might think, "if I have the source data, I can just generate it again." But there's a pitfall here.

Masters and formats change over time. That's exactly why there's meaning in saving the very PDF as it was at the moment of issue. The ideal is to retrieve the original from that time, not to rebuild it.

Persisting to Object Storage

Why Vercel Blob

The storage destination we chose for generated PDFs was Vercel Blob. It's object storage where you can simply drop files, and its advantage was that we could handle it on the same platform as the application.

Binary files like PDFs are more natural placed in object storage as files than crammed into a database. Retrieval is simple too — done via a URL.

The storage flow

Once a document is generated, you hand its byte stream straight to storage.

The key here is to record the PDF's storage location tied to the document's identifying info. Only once you know that "the invoice for this transaction is this file" can you retrieve it later.

Designing for Reissue Anytime

Just retrieve what's already stored

The behavior when a reissue is requested is simple. Rather than rebuilding from source data, you just retrieve the stored PDF from storage.

This way, even an invoice from six months ago can be handed over identical to the letter to what you sent then. There's no need to worry about "is it really the same," and the person handling it can rest easy too.

The value that accumulates as history

Keep storing, and the generated documents accumulate as history. This holds value beyond a mere backup.

When, to which customer, and what document you issued — the very fact that this record exists becomes the foundation for audits and inquiry handling. The mechanism for making documents doubles as the mechanism for keeping a history of them. That's the significance of building storage into the design.

Conclusion

A document isn't finished when it's made; it only becomes practical once you've designed all the way through to "reissuing the exact same one anytime."

• Documents get requested repeatedly even after issue, so they must be reliably stored
• Masters and formats change, so regeneration may not match the original from the time
• Save generated PDFs to Vercel Blob, tied to identifying info
• Reissue is just retrieving what's stored — you can produce a completely identical document any number of times
• Accumulated documents become history, a foundation for audits and inquiry handling

In this series, the big picture of making documents in code is covered in Automated Invoice & Delivery-Note PDFs, the technique for Japanese display in Japanese Font Embedding and File-Size Optimization, and managing company info in Managing Sender and Recipient Profile Masters.