An auditor asks for a copy of an invoice you issued in March 2024. It is a routine request, the kind that arrives every year. You open the invoice, press Download PDF, and send it.
What you have just sent is a document that never existed.
It carries the logo you adopted after last year's rebrand. The address is the office you moved into in January. The bank details at the bottom belong to the account you opened when you changed banks, and the company seal is the new one. The numbers are right, because the numbers come from the invoice. Everything around them came from today.
If nobody looks closely, nothing happens. If someone does — an auditor comparing your copy with the one the customer kept, a customer disputing which account they were told to pay into, a tax authority matching what you filed against what you issued — you have two versions of the same legal document, and one of them was produced this morning.
Why business software does this
Almost every system stores the data of an invoice, not the invoice. The lines, the totals, the customer, the tax — those live in the database. The PDF is produced on demand: when you click the button, the software takes the invoice data, pours it into the document template as it is configured right now, and prints the result.
For a dashboard, that is exactly right. You want this morning's numbers in this morning's layout. For a document that has left the building, it is exactly wrong. An issued invoice is not a view of your data; it is a record of what you told someone, on a particular day, in a particular form.
And the things around the numbers change far more often than people expect:
- Branding — a new logo, a refreshed letterhead, a new seal or signature.
- Company facts — an office move, a new registration number, a change of legal name after a merger.
- Bank details — a new account, a new bank, a new IBAN for a new currency.
- Layout — someone improves the template: a new colour, a column added, the terms moved to the footer.
Every one of those is a normal event in the life of a business. Every one of them, in a view-based system, silently rewrites every document you have ever issued the next time anybody prints it.
What a copy of record has to guarantee
Fixing this properly takes three separate guarantees, and most systems that attempt it stop after the first.
- The same file, every time. The PDF handed out on the day of issue is the PDF handed out forever after — the same bytes, not a re-render that happens to look similar.
- A reproducible recipe. If the file ever has to be rendered again — lost, or deliberately reissued — the system still knows exactly which letterhead, which seal, which layout the document was issued with.
- Change only on purpose, with history. Replacing an issued copy should be a deliberate, permissioned act that leaves the previous copy in place, not something that happens as a side effect of editing a template.
The first guarantee is the one a few systems do take seriously. Odoo, for example, has a report setting called Reload from attachment, which, in its own documentation's words, saves the report "as an attachment on the record the first time it is generated and reload[s] the original version of the report any subsequent time. This is legally required for invoices and is mainly used in this case." That is the right instinct, and it is worth saying so.
A stored file on its own leaves the other two open. If the stored copy is missing, or has to be replaced, what should the new one look like — today's letterhead, or the one the document was issued under? And in any design where the way to correct a stored PDF is to delete it, the history of what was sent is one click from gone.
How BIZA does it — for the curious
This is the technical half. If you only want the outcome, skip to the last section.
Branding is versioned. Every change to the letterhead, seal, signatures or brand colours creates an immutable branding version — immutable in the database itself, not just in the interface: once a document points at a version, no one can rewrite it, administrators included. Versions are content-hashed, so saving the same thing twice does not mint a new one, and the burst of autosaves a slider produces within a few minutes is folded into a single version — with one exception that matters: a version any document already points at is never modified, only succeeded.
The pin happens at the moment of issue, in the database. When a document leaves draft — approved, sent, issued — it is stamped with the branding version that is current at that instant. This is not done by the button you pressed. It is done where the document's status changes, so an approval that arrives through a bulk action, an API call or the AI assistant is pinned exactly like one made on the page. A pin that depends on the user taking the usual route is a pin that will eventually be missed.
The layout is pinned alongside it. A document's look has two halves with different owners. Branding owns the assets — the letterhead, the seal, the signature images. The document template owns the look — colours, spacing, fonts, which sections appear. Our first version pinned only the branding half. That meant a colour chosen for invoices in the template had to be overruled by the brand palette, because colour was only reproducible on the branding side of the line. Pinning the layout too removed the conflict: the template now wins where it has an opinion, and nothing becomes unreproducible as a result.
One copy of record per document. Right after a document is issued, it is rendered once and stored. That file is what Download PDF, Send and Share hand out from then on; the database allows exactly one copy of record per document. If rendering at the moment of issue fails — or the approval happened somewhere a browser was not involved — the first download writes the copy instead, and marks it as written late so nobody mistakes it for an at-issue render.
Every file records how it was made. Each stored render keeps the exact layout settings that produced it. When someone asks, a year later, why a document looks the way it does, the answer is on the record rather than in someone's memory.
Replacing a copy is deliberate. Reissuing a document under the current branding is a separate permission, not a side effect of editing a template. The new file becomes the copy of record; the old one stays in the document's history, dated and attributed.
The printer never fetches a URL. PDFs are printed by a rendering engine that loads everything on the page itself. Handed a link to your letterhead, it will print a page without the letterhead if that request fails or runs slow — and report success. On a draft that is an annoyance. On the render that becomes a copy of record it is a permanently blank letterhead on a legal document. So every asset travels into the render as the image's actual bytes, fetched and checked beforehand. If an issued document's letterhead cannot be loaded, the render refuses and asks you to try again, rather than quietly producing a copy of record without it.
The files a version points at cannot be deleted. A branding version is only reproducible while its images exist. Letterheads, seals and signatures, like the stored copies themselves, cannot be deleted or overwritten by anyone using the product — and a version cannot be discarded while any document still points at it.
What it costs
None of this is free, and it is worth being plain about the trade-offs.
- Storage. Every issued document keeps a PDF. For most businesses that is a rounding error next to the attachments they already store; it is still a cost that grows with every invoice.
- A stricter failure mode. Occasionally, a user who presses Download PDF on an issued document is told to try again, where a view-based system would have handed them something. We think "try again" is the honest answer when the alternative is a document that is wrong in a way nobody will notice until it matters.
- More moving parts. Versions, pins, a copy-of-record ledger, locked assets. That is complexity a template-and-render system does not carry — and it is exactly the complexity that separates a record from a view.
How BIZA handles it
When a document is issued in BIZA — an invoice, a credit note, a quotation, a purchase order, a delivery note, an RFQ, a rental agreement or a rental quotation — it is pinned to the branding it was issued under, and, where the document type has its own template, to the layout as well. From then on Download PDF, Send and Share hand out the same stored file, every time.
You can rebrand, move offices, change banks or redesign your templates freely. New documents pick up the changes; issued ones do not. When you genuinely want an old document to carry the new branding, Reissue does it deliberately, with a permission of its own, and the earlier copy stays in the document's history.
In markets with e-invoicing mandates this is not a nicety. Under ZATCA Phase 2 in Saudi Arabia, for instance, an invoice is cryptographically signed when it is issued; the document you hand the customer has to be the one you issued, not a re-render of it.
An invoice from 2024 should still look like it did in 2024. That turns out to take more machinery than it sounds — and very little of it is visible, which is the point.
See sales and invoicing, ZATCA e-invoicing, the guide to quotes and invoices, or try BIZA.