Every Friday afternoon I send one client the same thing: a delivery packet. One file, three sources — a cover letter from my documents folder, the main report out of a reporting tool, and an appendix of signed pages the client sends back to me. Three producers, three PDF "dialects," and one merge standing between me and the weekend.
It ran fine for months. Then one Friday the appendix landed before the report. The client replied, politely confused, asking why the packet opened with signature pages and why every page reference in my cover letter was wrong. Nothing was corrupt. The merge had simply sorted the files alphabetically — appendix.pdf beats report.pdf every time — and I had clicked through without checking. That one cost me an apologetic re-send and a Monday-morning call to walk through which pages were actually final.
The parts don't help each other. The report comes out of the generator as clean A4 with a proper outline. The signed appendix is phone scans: image-only pages, mixed sizes, one of them reliably sideways. The cover letter is a single page with no bookmarks at all. None of that is a problem for a merger — but it means the merged file is the first moment all three are forced to behave like one document, and it's the last moment I can cheaply catch it if they don't.
Order is not cosmetic
When the parts come from one generator, merging is boring. When they come from three, order is load-bearing:
- Printed page numbers. The report's footer says "Page 12 of 34." That math only works if the cover letter is exactly one page in front of it and the appendix starts exactly where the report ends. Slip one part and every printed number in the packet is a lie.
- Bookmarks. Each source carries its own outline. Merge tools concatenate those outlines in file order, so a wrong order doesn't just move pages — it promotes the appendix's bookmarks above the report's chapters in the sidebar, and the packet looks misassembled even where the pages are fine.
- Cross-references. My cover letter says "sign-off sheet on the final page." Final means final. If the appendix isn't last, that sentence points at the wrong page and I look sloppy in the one document whose entire job is looking careful.
The checklist I now run on every merged packet
The fix wasn't a better merger. It was refusing to send anything I hadn't verified. Sixty seconds, three checks:
1. Page count equals the sum of the parts. Not "looks about right" — equals. I keep a tiny script next to the packet folder:
pdfinfo cover.pdf report.pdf appendix.pdf | grep Pages # 1, 26, 7
pdfinfo packet.pdf | grep Pages # must say 34
2. Click the bookmarks. First, middle, last. Each one should land on the page its label promises. This catches outline scrambling, off-by-one shifts, and the classic "appendix chapter points at report page 3" error that a page count can't see. While I'm in there I also glance at the first appendix page — a scan that merged in sideways or at postcard size announces itself immediately, and it's much cheaper to spot now than in a client's reply.
3. File size makes sense. A merged file should weigh roughly the sum of its parts, minus a little overhead. Five times bigger means something re-encoded the images. Half the size means something got dropped or downsampled. Either direction is a stop-and-look, not a send. I keep the three source files until the client confirms receipt, so a bad merge is a two-minute redo rather than a reconstruction project.
Why the merge itself is not in my pipeline
The obvious developer move is a merge step in code — pikepdf does it in six lines, and I already use it elsewhere. But this packet is assembled once a week, by a human, after eyeballing the parts. Automating the merge means my pipeline now owns the outline quirks of three different PDF producers, forever, across every library upgrade — for a step that was never the bottleneck.
So the split is deliberate: the merge happens in the browser, where I can drag the three files into order and see the page thumbnails before committing — I use the merge tool on PDFLean for exactly that drag-order-and-preview step — and the verification is what stays scripted, because verification is the part humans skip when they're in a hurry.
That's the general shape I've landed on for document chores: automate the checks, keep a human on the one irreversible click. The packet goes out in the right order now — cover, report, appendix — and Friday ends when it should.
Top comments (0)